A look at my 2024 tech stack

One thing that is certain in software development is that there is always something to learn. It is really tempting to try out every new thing, but at the end of the day, the effort put into learning should translate to being able to create better solutions more efficiently. Or in the best case, to being able to create something that was out of your reach before.

With this in mind, here’s an honest look at my current competence stack and some reflections on it. In the next post I will write about what I am focusing on learning and improving this spring.

My current web development stack

For the past three years, my daily driver for web frontends has been React, and last year I hopped onto Next.js bandwagon with the release of the new App router. I’ve really enjoyed using Next.js, and I think the new server component paradigm is very powerful for creating highly dynamic web applications. The biggest issue I have with it it that it’s very tempting to create overly complex Javascript solutions for things that could be done with mainly HTML and CSS.

That was my main motivation for using Astro for this blog, and trying to keep Javascript to a minimum here. Astro seems really powerful for content driven sites that require less interactivity, and there’s always the option of dropping in a React component if needed. I really don’t see a need for another framework in addition to these two, preferring Astro for websites and Next.js for web apps. Next.js seems like a safe bet for professional projects right now, especially if you are fine using Vercel for hosting.

For backend services, I’ve been using NestJs for three years, and for my use cases it has been perfectly fine. I’ve written a lot of Javascript and Typescript, and for basic REST Apis nodeJS is pretty great.

In terms of infrastructure, I have associate level certificates with AWS and Google Cloud, and have used Google Cloud the most. I really like Google’s Cloud Run service, although having to use serverless connectors to services within private networks is a bit annoying. For deployments, terraform has been solid, although the licensing mess has been somewhat worrysome. Terraform working across all major cloud providers is such a big benefit that it’s difficult to justify switching away, especially if there is no requirement to do so. For the blog however, I’ve tried to keep it pretty easy, and use a Linux server with nginx for serving the site.

Within CI/CD pipelines I’m using Jest and Cypress for testing, combined with testing-library for some more convenient testing methods. My projects are all currently on GitHub, and GitHub actions works well for orchestrating ci/cd workflows with integrations to events in the code repository.

Overall, my stack relies heavily on Node.js, maybe a bit more than I would like to admit. However, the stack works well for the things I need to accomplish, so I don’t see any big shifts that would need to be made in terms of frameworks or tooling. I feel like I’m in a good spot where I can deliver with the stack that I have. Thus, my focus this spring will not be in going wider with new tech, but going deeper and getting better at doing stuff with what tech I have right now. But more on that in the next post.

Small update on the blog

The blog is very barebones, but I will at least add listings for recent and all articles soon. We got a new baby in the house since February, and there isn’t that much time for developing this site and writing new posts. I’m aiming for monthly posts, but let’s see.