My 2022 Stack

I am always building new apps, most are silly and never see the light of day, but some do. I have a strange obsession with going from zero to MVP in the shortest time possible so I’m always looking for ways to build, automate and launch fast. I also want them to be nearly zero maintenance.

So here’s my current go-to stack for 2022.

Backend

I always have a backend API where the core logic of my app lives. My front-end only accesses data through the API and I can easily integrate with other apps or build other front-ends (eg: native mobile apps) in isolation.

• Language: Go (golang)
• Infrastructure:
• — Compute: Google Cloud Run
• — Database: Firestore
• — Storage: Google Cloud Storage
• Optional, but used often:
• — Google Cloud Scheduler
• — KMS for encrypting data
• — Secrets manager
• — Algolia Search

Go is great for API development and at this point I can write Go APIs with my eyes closed. I also have several personal libraries that let me fast track my development using the services above.

My infrastructure choices have changed over the past 10 years, but the code hasn’t.

Frontend

After using many of the modern frameworks like Next.js (React), Angular, SvelteKit, etc, without fail, I always wish I didn’t use them.

And once you go down a framework path, there’s no turning back. You are locked in for a long time and the cost of switching is extremely high. So I’ve recently decided to go back to some basics to keep it very simple and future proof. I like the idea of Islands Architecture and I think that’s the path forward. It is also what Deno’s new Fresh framework is all about.

Here’s my requirements for frontend:

• Server side rendering (SSR)
• — This may seem so obvious, but with React for instance, that’s not the default. You end up having to use Next.js (or Nuxt or Nest) just so you can get some server side rendering which adds a whole new level of complexity on top of the already super complex react ecosystem.
• — The fact there are 3 competing frameworks that exist mostly just for server side rendering is a pretty big red flag.
• — SSR benefits are clear and well known so should be high on your priority list.
• Simple
• — If I can’t come back in a year or two and easily understand what’s going on, I don’t want to use it. Most modern frameworks are beyond complex.
• — Fast build or no build process.
• — A Next.js app I work on takes 10 minutes to build the production version. That’s 9.5 minutes too long.
• No lock-in
• — If I want to try some new JavaScript thing, I just want to be able to use it as is, how it’s meant to be used. Just import it from a URL and it “just works”.
• — The more standards based you can stay, the better and more future proof your app will be. If you use a framework, there’s a high chance you’re locked in.
• — Minimal switching costs and iterative migrations. Meaning if something new comes along, I can just use it along with my existing code. If you stick to standard JavaScript, you’ll have no issues when new things come along.

So this is what I’m using now that satisfies all of those

• Fastify with simple template engine
• — I use pug or eta
• — This renders the the initial view really fast so the user sees something useul right away (First Contentful Paint)
• — Ability to fill in other details like OpenGraph tags, etc
• — Also lets you do something securely on the server side if needed.
• Web Components using Lit
• — All modern browsers support it, no build process required
• — Lit is truly awesome. It’s a small wrapper around standard Web Components and writing components with it is just really nice and simple. None of the complicated React way of building components.
• Infrastructure:
• — Compute: Google Cloud Run

My templates are usually just a few lines of code like this:

So the server fills in the SEO tidbits and loads the high level page data quickly, then the client side web components hydrate and fill in the rest.

Going Forward

I’ll continue using this stack for the foreseeable future. Things will obviously change, but this is the best for me as of now.

I would recommend not jumping on the shiny new toy (JS framework) as there’s a good chance you’ll regret it down the road. Go back to the basics, you’ll probably find it quite liberating.