There's a Lot to Web Development

Use the right tool for the job...

Posted by lymestackblog on August 25, 2024

If the only tool you have is a hammer, you tend to see every problem as a nail”
- Abraham Maslow

Back in 1996, when I started learning about the web and HTML, it was a very different time from what it is today. There was really only HTML... CSS was only used for typography and Javascript was mostly only used for simple form validation. This afforded me the opportunity to watch the technology grow. While it was still very fast paced, the emerging tech allowed me to digest the new information in bite-size portions.

Today, things are much different. I can imagine how overwhelming it must be to enter this technology sector with little to no experience. There are countless languages and frameworks to choose from, all with their own advantages and disadvantages. Here at LymeStack, we have our own opinions as to the tech stack we use to build and maintain our projects for ourselves and our clients. This blog post will try to give an overview of those decisions as well as the reasoning behind them.

Disclaimer: I'm mostly a Microsoft guy in terms of development. While I do stray from the reservation on occasion, it's important to use the right tool for the job and I've found that Microsoft's development tools and large support ecosystem have been the right path for me.

Note: I'm not being paid by any of the following vendors to promote their products... though I should be!

Topics Covered

Here's a complete inventory of the tech-stack that makes LymeStack tick.

Back End Technology: .NET 8 WebAp

[Microsoft's .NET] technology supports a few languages, but by far the leading language in their ecosystem is C-sharp (C#), a language developed by Microsoft. C# has been around for quite a while, first appearing in the .NET Framwork that originated in the early 2000's. Microsoft has since replaced the .NET Framework with .NET Core and most recently branded. Hedging from the topic that Microsoft sucks at naming/renaming things, their most recent iteration of C# is the language we use to power our back-end API for our entire organization. It's a mature technology and works seamlessly with Entity Framework, the ORM technology also developed by Microsoft that is used to interact with database objects such as tables, views, and stored procedures. Unlike it's predecessor, .NET 8 now runs cross-platform, so you can develop the API on any operating system that you like. I still like to develop on Windows, but it's nice to have the choice.

Front End App: Angular

Angular is a Javascript based full-featured framework built and maintained as an open source project by Google first released in 2010. If Microsoft offered a Javascript framework, I'd probably use it, but my alignment with Angular is a natural progression from my first real start with Single Page Application (SPA) programming using it's predecessor AngularJS (aka Angular 1). AngularJS was a game changer and it really hit home and laid a solid foundation for what modern web application programming looks like today. Sure, credit should be given to a lesser known library called KnockoutJS, but I think AngularJS made a larger impact in the web app development world. Unfortunately, AngularJS showed its inability to scale as applications became larger and more complex causing performance issues for users and old hardware.

Then in 2016 came Angular 2. Angular 2 was a complete rewrite of Angular 1, which addressed many of the shortcomings of its predecessor and it's new structure still very much resembles modern versions of Angular (version 18 at the time of this writing). This rewrite created a couple problems though:

  • Need to Modernize AngularJS Apps - This introduction of Angular 2 left a bitter taste in the mouth of us legacy AngularJS developers. This complete abandonment of AngularJS felt like a slap in the face because we were so invested and comfortable with AngularJS aside from it's performance problems (albeit I still miss the conveniences of $broadcast and $emit). The added fact that it was a complete rewrite let a feeling like we were starting over from scratch again... and we were... I imagine the Angular community lost a lot of developers to other competing frameworks like React and Vue because of this drastic change. Anyway... Version 1 of any app usually always sucks, and they had a good run for a 1.0 version, so any bitterness or surprise is a moot point.

  • Increased Learning Curve - Angular by default is a pretty large and opinionated framework. It's not very well suited for small and simple applications, but it has it's place in larger and more complex applications or small applications that would potentially grow into something more complex. This high level of opinionation can provide a more unified approach to development as more developers enter the mix. We also pay attention and try to incorporate best practices to stay on the same page. This Pluralsight course is a great piece of work and we heavily followed this guide in building our LymeStack front end web app template.

Note: We are currently considering creating a "React Edition" of our web app template. If this is something that interests you, please contact us

Front End UI Libraries: Angular Material / Bootstrap

This is probably not considered the best practice, but f--- it. The LymeStack front end web app uses BOTH Angular Material and Bootstrap 5 in its UI implementation and design.

Why Angular Material? Angular Material was built by the Angular team, implementing the concepts of Material Design seamlessly into the an Angular based web app. It's documentation is pretty good and the code implementation is fairly terse and compact. (Less moving / working parts the better) It also offers a comprehensive UI component library for any common UI/UX design scenario. Angular Material does have some drawbacks though, which is causing us here at LymeStack to explor other alternatives. (We'd love to hear from anyone who has an opinion on this) The main drawback is that Angular Material did a major rewrite of its framework, breaking many of my CSS customizations that improved the look and feel of the sterile default implementation of Angular Material offered. This has us stuck on Angular 14 (now on 18) and is a current admitted shortcoming about our product that we are trying to solve. The other drawback, which might be considered to be a positive to others, is that being designed by Google, Angular Material naturally looks a lot like a native Android app. I'm an iPhone guy, so this isn't the best for my preferences. It's because of these drawbacks that have us looking into other frameworks like ngBootstrap, ngx-Bootstrap or PrimeNG.

Why Bootstrap? As of the writing of this post, Bootstrap 5 is the latest and greatest version of the popular Bootstrap library originated at the formerly known Twitter (now X.com. I still think I prefer the look of the UI components offered by Bootstrap over Material Design and implement them on occasion such as alerts and badges. We still also prefer Bootstrap's grid system for building responsive column layouts.

Database: Microsoft SQL Server

I was introduced to Microsoft SQL Server back in 1999 at my first job out of college and I was an instant fan. Up until then, I had only one real database course in Microsoft Access in college. I liked SQL and it made sense to me, but everything else about Access was loathable. Around the same time, I also had some production experience with mySQL and Oracle. They were good database engines, but what really set SQL Server apart is the SQL Server Management Studio (SSMS) tools, which in my opinion, still gives Microsoft SQL Server the edge for me today. It has the expected tools you would use to design tables and query / manipulate data, but also has some cool diagraming tools that allow me to create ER (Entity-Relationship) diagrams as I am thinking about the overall schema. When I'm done diagramming the schema, there's a "Generate Change Script" option, which will allow for me to generate a T-SQL file with all my diagrammed changes for easy deployment to my test and production environments. Another added feature that SSMS / SQL Server has is a performance tuning wizard, which will capture queries run on a database (a trace), analyze the queries and recommend indexes that can increase performance significantly on slow running queries.

Microsoft SQL Server comes in a few editions. Microsoft SQL Server Express is the free version of the product. It's free to use for production purposes for databases up to 10 GB in size, which if you program efficiently and have strategies to keep your database lean, can go a long way. I once built a system that was doing up to a million dollars in business per month by the time it sold, had been running for about 5 years, and its uncompressed size was still less than 500 MB. SQL Server Express doesn't have the diagramming support or performance tuning tools, so I only use SQL Express in the test and production environments. If I need to debug a production issue with queries, I copy the production database to my local development environment where I have those tools to me via SQL Server Developer Edition, which I'll explain in a moment. SQL Express also has some limitations around CPU core usage and memory... again, all limits I've never encountered myself.

Once you exceed the 10GB limit or need more advanced features, that's when paid commercial versions of SQL Server come into play. Odds are that if you get to the point where you need that sort of horsepower, you likely have the budget to pay for these licenses. For a full list of differences between the editions, you can see this breakdown that ChatGPT summarized for me.

On my local computer, where I have all my development tools, I run SQL Developer Edition, which is a full featured instance of SQL Server with all the diagramming and performance tuning goodies, but is only intended for development purposes and not licensed to run in production environments. This is why when I need to do performance tuning, I bring down a full copy of the prod database and debug locally.

Lastly, SQL Server can now run natively on Linux or on macOS with the help of Docker. Use still need Windows to run SSMS, but other native tools such as Navicat are available as native GUI's for macOS. I'm not really sure what's out there for Linux, but there's probably something.

It's also worth mentioning that I've had my eye on PostgreSQL for quite some time, but the tooling I've seen that comes with it so far has not exceeded the level of functionality that I get from SSMS, at least in the form of free tools.

Authentication Service: Microsoft Azure Entra ID

In my blog post, Getting Started is the Hardest Part, I describe how authentication / authorization is the worst part about web application development for me. Unfortunately, it's one of the first things you have to implement when building a new app. This cumbersome, unavoidable and often painful step is a necessary evil. In the past, we used to create local user account tables using the ASP.NET membership provider and that was about as simple as it gets. Unfortunately, in today's security landscape and as cyber attacks become more sophisticated, using local accounts are becoming more of a liability.

To solve this issue, we need some outside help from a third parth OAuth 2 provider. These providers most notably add MultiFactor Authentication (MFA) support to your application by allowing your users to log in with their username/password and SMS message or authenticator app.

There are many options to chose from, but I reluctantly decided to chose Microsoft Azure's Entra ID after what seemed to be weeks of chipping away at it and navigating outdated tutorial after tutorial until I finally found one that got it right. I say reluctantly because of the level of effort it took to get working and it goes against my sentiment, F@#* the Cloud. It's on the roadmap to implement a few alternatives so as to not be dependent on any one auth provider. Of course there is always Auth0, which is the best in my opinion, but I made the decision to only implement free options into my product template so I'm not forcing my customers to pay a 3rd party in order to be able to use my product. Ultimately, someday I would like to include the ability to use local accounts in combination with any major third party provider, including Auth0. If my customers want to pay for Auth0, then great, but I don't want to force the issue.

Icon Library: FontAwesome

I have been using FontAwesome for a good many years, participating in their kickstarter campaign many years back, which bought me a good few years of free use of their icon library. FontAwesome provides a wide array of solid icons that can be use for free and offer paid options for special use cases and other variations of their product like multi-toned or light implementations. Some other free libraries I've discovered and use on our marketing website are Unicons and Material Design Icons.

Using these free icon libraries will save lots of time and money in hiring custom graphic designs (sorry designers), drastically reduce the amount of images one has to manage, and most importantly, they add a nice and professional touch to a web application.

Marketing Website: HTML / Razor (CSHTML) / jQuery / Vue

What?? All this self-promotion and selling the Kool Aid about LymeStack and I'm not using it for our marketing website? Well, yes and no...

Yes, in that LymeStack is used as the API for the marketing website. I use LymeStack to manage the data that is served from the API. It also handles form submissions and the downloadable assets for the developer tools. As I pointed out before, it's important to use the right tool for the job and here is where I practice what I preach.

No, in that the marketing website doesn't require the added overhead that's included with the full-blown back office application. Instead we have a lean, efficient and most importantly, SEO friendly maketing presense. We simply link to our LymeStack app to a subdirectory on our website. Currently the marketing site uses mostly static HTML and use of jQuery to handle any API interaction or functionality like form validation. The Video Library is also a small Vue app that grabs its data from the API. To consolidate technology, I will probably convert the marketing site to Blazor in the near-ish future.

Tip - If any part of your app is SEO sensitive, don't use Angular or React. Search engine robots have a near impossible time (unless technology has improved in some way that I'm not aware of) with crawling content served from a Javascript based framework. Instead, I would recommend Blazor for someone with a Microsoft background or Next.js for those with a React background.

Cross Platform Desktop Application: Blazor

This is probably not the first use-case you would think of when thinking about building a desktop application, but in my case, I saw it as the right fit. My challenge was that I needed to build an application on a desktop computer that had direct access to all its resources, such as the file system or database connections. Building this sort of application using strictly a browser and web app wasn't going to cut it for what I needed to do. I then thought I could build a native application to serve as an interface for this, but I'm a full stack web developer by trade... I don't have the time or desire to learn how to build a Windows app... or Swift app... or whatever the hell it is you build a native Linux app in any one of the million distros that are available.

I chose Blazor because I could leverage my web dev experience in creating web UI along with being able to leverage the local resources I need to control the computer. I can access the file system, run executables such as Powershell or bash scripts, and be able to provide a working copy to all three Windows, macOS and Linux developers. I still use the LymeStack API to manage licenses to unlock protected functionality in my app.

As an aside, developing in Blazor has caused me to fall in love with Bootstrap again.

Blogging Software: OrchardCms

There are many options out there for blogging. I would say that the most popular and widely used software for this is probably WordPress. WordPress is built on PHP and mySQL is probably one of the best blogging packages round. However, this very blog you're reading in instead using a different package called OrchardCms, built on .NET 8. Here's why:

Why not WordPress?: WordPress is built on PHP and mySQL. Both of these technologies are tried and true, but as I mentioned before, I come from a mostly Microsoft background, so it's not something that's as easy to customize as a .NET based package might be. That and installing PHP, mySQL and the WordPress onto our production servers have a few other implications. 1) Our current production server is running on a fairly low powered VM (IaaS) in an Azure data center. Installing PHP and mySQL would likely increase the montly cost by me having to bump the resources in CPU and Memory to be able to accommodate for that change, which at my level, would double my montly hosting bill seeing as to how my next size tier doubles my RAM from 3.5GB to 7GB, resulting in approximately an additional $150 per month on my hosting bill. 2) Installing PHP, mySQL and WordPress increase the amount of things that I need to keep patched and up to date from a security perspective. Sure, I could consider hosted blogging services, which aren't too expensive, but add to the slow drip of subscription services that widdle away at the bottom line.

Why OrchardCore CMS?: Because Orchard CMS is built on .NET 8 and supports MS SQL Server, it doesn't require any additional technologies that differ from what we already have in place now and requires very little in added resources to running on our existing infrastructure. The project is feature rich, well maintained, well documented, and there is an active community. It's also free and open source and easily customizable.

There are some other .NET alternatives out there, but after doing a few hours of research, OrchardCore seemed like it was the best fit for me.

Documentation: Markdown

All of our documentation in the LymeStack Product Manual is authored using standard text-based Markdown files using Visual Studio Code and the Markdown Preview Enhanced VS Code plug-in, which offers a preview of the Markdown output to the side while editing. We used this documentation to submit as part of our provisional patent application that we filed with the US Patent and Trademark Office (USPTO). In order to submit the document to the USPTO, we first had to convert it to a combined PDF. For more information about this process, have a look at our Python Script to Assemble a Combined Markdown File from Multiple Markdown Files blog post.

We also created another c# script, which we'll probably post later, to assemble the same markdown files as HTML documentation that is the online version of the LymeStack Product Manual.

Installer / Setup Builder: Inno Setup

In order to make LymeTools easier to get up and running on Windows, I use Inno Setup. Inno is a free installer for Windows programs and has been around since 1997. It is highly customizable. Unfortunately custom workflows use the old Pascal language, but AI platforms like ChatGPT did a good job in helping me implement my workflow customizations. An example of custom workflows in the LymeTools installer configuration is that it checks to see if a user has the .NET 8 SDK installed and if not, direct them to the installer page first.

Production Cloud Platform: Azure

Being that I'm a Microsoft guy, I naturally choose Azure to host my production virtual machines. Currently, I only use an Infrastructure as a Service (IaaS) approach as a opposed to a Platform as a Service (PaaS) because I don't want anything cloud proprietary in my code. If I become dissatisfied with my cloud provider, I want to be able to freely switch my cloud provider or go on-premesis. IaaS does have some limitations when it comes to scaling out, but I've nowhere nearly reached that limit, so I have a while to tackle that issue. I'm not an expert in this, but I'm thinking that containerizing a LymeStack instance and using Kubernetes is going to be my cloud-platform-agnostic approach that I will take when I get to that point.

Local Virtualization Platform: HyperV on Windows or VirtualBox

For all of my development, I host those resources locally. I built a really nice gaming rig a few months ago, which I don't really use for gaming at all, but instead use it mainly a HyperV host. HyperV is built into the professional editions of Windows 10/11 and this HyperV host contains a separate virtual machine (VM) for each of my clients and one for LymeStack. I power them on and off as needed so as to not use all my RAM up at one time and since I'm not working on every client's backlog every day. I usually only need to fire one up if there's a bug report or feature request from a client as most of them are up and running and stable already. This HyperV host also hosts my DevOps Server running Windows Server, which hosts a TeamCity Build Server, Octopus Deployment Server, and the test environment for LymeStack.

If you run macOS or Linux, I recommend Virtualbox, but admittedly I've had some weird performance issues with system interrupts on my VM's using VirtualBox hosted on my 2017 Intel i7 iMac.

Credit Card Processing: Stripe

Stripe is a popular online payment processing platform that allows businesses to accept and manage payments over the internet. Their pricing is on par with industry standards, typically charging $0.30 + 2.9% per transaction for online payments.

Stripe makes it easy for developers to implement payment processing into their applications, offering extensive documentation and code samples to assist with integration. The platform provides various developer tools, including a command-line interface (CLI) for testing and managing integrations, and sample code designed to help developers get started quickly with Stripe implementations. PayPal is another well-known option for online payment processing.

Domain Names: GoDaddy & SquareSpace (formerly Google Domains)

There are probably cheaper options out there, but I've been with these providers for years. I've never had to use SquareSpace support, but have to use GoDaddy's support multiple times in the past and most every interaction with them, I've encountered a knowledgeable and well spoken representative. Granted, the last time I contacted them has probably been a few years now, so things could or could not be different from my experience.

SSL Certificates: PositiveSSL

SSL certificates are expensive. We found GoDaddy and SquareSpace to be a little more expensive than PositiveSSL. Here I was able to get a wildcard SSL certificate for $269 per year wheras other providers were closer to $400 per year. You can save on certificates by only securing 1 site and getting a single domain certificate, but every time I decide to do that, I find a need to secure a subdomain causing me to get another single certificate or upgrade to a wildcard certificate.

FavIcon Generator: Real Favicon Generator

The little icon that shows in the browser tab was generated by the Real Favicon Generator online app. I simply uploaded my logo.png file to the site and it generated me a favicon.ico file as well as a few other iOS / Android specific files.

SMTP Delivery Service: Postmark

LymeStack uses Postmark for delivering messages sent out by our web applications. I have used SendGrid in the past, but we had a few incidents which required some degree of support, which seemed to be non-existent for us when we needed it the most, which led us into the arms of Postmark. Postmark's free tier only allows for 100 emails per month to be sent out via their servers, whereas SendGrid allows for $100 per month, but the bad experience we had me opening my wallet a little sooner. As of the writing of this article, the first paid tier for Postmark is $15 per month for 10,000 emails send quota per month.

Conclusion

Navigating the ever-evolving landscape of web development can be daunting, especially for newcomers. However, by leveraging a well-defined tech stack like the one at LymeStack, developers can streamline their processes and enhance their productivity. The choices made—from the robust capabilities of .NET 8 and Angular to the reliability of Microsoft SQL Server—demonstrate a commitment to using the right tools for the job. As technology continues to advance, staying informed and adaptable will be crucial for success in this dynamic field. Embracing these tools not only simplifies development but also fosters innovation, allowing businesses to thrive in an increasingly competitive environment. I hope you found this blog post useful in helping to make some key decisions in choosing your tech-stack.

Thanks for reading!