Introduction
It’s been 4 years since I was active on my own personal portfolio site. Why did it take me so long to revive it? Well, my personal portfolio site was a mess — not because it didn’t look good, but because it had become a maintenance nightmare. Below is a diagram of the previous state of architecture of my portfolio site.
Yes that’s right, I was using 2 different cloud hosting providers, a frontend application using Gatsby, a backend application using Strapi to act as a CMS (content management system), and a database.
Given that it is a portfolio site, I wanted a tool with great SEO optimisation and Gatsby was one of the top choices back then. I also thought that it would be a great idea to be able to edit the contents of my portfolio site with a UI, with the goal of making it easier for myself to keep the contents up to date and publish tech articles. Strapi was a prime candidate for this since it offers CMS capabilities and Gatsby already had plugins available to make it easy to integrate with a Strapi application. To fully utilise free plans, I ended up hosting services on two different providers — one for the frontend, one for the backend.
Was it really a great idea? Unfortunately, the benefits of those choices were not what I envisioned them to be in reality.
My Pain Points with Gatsby and Strapi Set Up
In 2022, less than a year after setting up my portfolio site, a series of unfortunate events unravelled.
Version Upgrades
The Gatsby application was running on v3 and it was due for an upgrade to v4. The upgrade took several hours to fix the breaking changes. However, when I ran Strapi locally to test and validate the changes before deploying, I realised:
The Strapi application was running on v3, which means this dependency required me to work on another version upgrade. This then took another 2 more weeks to get done.
A bulk of the LOC changes were due to package.json.lock. However, if you look at the amount of dependencies that had to be bumped also meant that the number of breaking changes is high.
Eventually, after much persistence, I got to merge the version upgrades on 4 August 2022.
Tough luck — Discontinuation of Heroku Free Plan
However a few weeks later, on 26 Aug 2022, I received an email from Heroku that they will no longer be supporting free plans. Heroku has always been the go-to option for hosting small projects back then given its extensive offerings like free database hosting and free dynos so this was definitely an unpleasant surprise.
At this point, I couldn’t really justify the need for upgrading to a paid plan nor the time to work on a migration task. What this means was that I no longer have the platform to store the content. Since then, I’ve stopped updating my portfolio entirely and started to publish more on Medium and company’s tech blog. However, the idea of hosting my own tech blog to add my own personality and touch to it has always lingered at the back of my mind.
Fast forward to 2025, I decided to take the learnings that I had and revisit the idea of owning my own tech blog.
Trim the Fats, Keep it Lean
The previous state of architecture was overly complex for a small project, reeked with too many dependencies too.
3 Lessons Learned
- Less is more
- Adding too many tools like Heroku, CMS server and a database caused the architecture to be unnecessarily complex. The classic case of overengineering becomes an overhead to getting actual work done
- Add dependencies judiciously
- Always evaluate the necessity of adding dependencies as this could easily succumb to additional risks of breaking changes whenever there are version upgrades. It was easy to integrate a CMS with Gatsby, but the ease of adding a new dependency doesn’t necessarily mean that you should.
- First Principles Thinking
- Always start by identifying the most important problems to solve and focus on the goal. This helps to avoid deviating too much from the actual problem at hand during solutioning.
Simplying Architecture
Going back to First Principles Thinking, all I needed was an application that could give high SEO ranking and publish tech articles on. To reduce dependencies and have better maintainability, I decided that CMS server was redundant and it’s simpler to just rely on writing articles using markdown files. This means we no longer need to host a database, and another cloud hosting provider.
Astro fits the 2 main requirements really well:
- Strong SEO optimisation
- Simple to write and publish tech articles in markdown files (Gatsby requires a number of plugins and writing graphQL queries was still necessary)
Overall, it took me just 2 days to migrate to Astro and consolidate the tech articles that I’ve written so far, in comparison to the ~2 weeks worth of effort just to upgrade the versions for Gatsby and Strapi.
Conclusion
It’s easy to succumb to building fancy features because its benefits sound enticing, especially if it is easy to integrate with them. But it is also important to recognise that sometimes, simple and bare can get the same job done, and if not get it done better. Now, adding a new article takes me minutes, not days of dependency wrangling 🎉