My Own Personal (Development) Hell: Blogs

Wednesday, 2 April 2025 6:12:15 PM

For the past 8 years, I’ve had some sort of personal website up, split between two domains, a degree and my current job. Most of these have had a “blog”, but none of them have had an actual blog post. And that changes today, as you are now reading my first ever blog post.

This feels like a somewhat historic moment for me, as I’ve always wanted a place where I can share my thoughts with the web. Let’s take a look back at my attempts, what I’ve learnt, and what we have now.

Humble Beginnings - Blog V1

My first attempt at a blog goes back to University. My friend created their own static site generator which took in markdown files, and after seeing that I decided to try my hand at my own website. This site is here on Github, back when I had a .dev domain. There’s not a lot there, but here’s what it looked like:

It’s amusing looking back at the repository, I didn’t even have a .gitignore so there’s a Vim swap file that managed to sneak in there. Despite this I did start with some good practices, like semantic HTML elements. The fonts are a combination of Georgia and Garamond, both beautiful fonts. Bar that though, the pages didn’t have a lot of content, and there was no back-end. While a good start, I wanted to find an easier way to make content for my site that didn’t require making raw HTML pages. That brings me onto my next attempt.

Wordpress - Blog V2

My second attempt at making a blog was after graduating, and I decided to try Wordpress. I found it attractive as:

• I could use managed Wordpress, so I didn’t have to worry about configuring hosting.
• Wordpress handles the complicated parts of adding components and styling.
• The graphical editor makes it easy to add content.

Because of the ease of adding content, I did manage to write some for this website, though not for my blogs. I had some overviews of some of my previous projects, specifically Ri which was a small programming/interpreter I made at a game jam, and a program I helped author for my dissertation project RhythmTrain.

Despite this, I didn’t end up being a fan of Wordpress:

• The web interface felt slow, and felt like a bit of a slog to use it both UX wise and speed wise. This could have been Fasthosts’ Wordpress, but still, I didn’t enjoy using the web interface that much.
• Customising and theming was intimidating and difficult. I did like some of the existing themes but it never felt like my website because of this, especially once I was confident enough writing HTML/CSS/JS to make my own.

I was happy with that site for a bit, sadly I have backups but no images of it to share. After a while I was eager to try making my own blog from scratch. So that’s what I did

Third time’s (not) the charm - Blog V3

Now, the most interesting iteration: my previous blog. This is also on github, and was not intended just to be a blog, but also an exploration of making my first full-stack application by myself. By this time, I had been using React at work a while and had become comfortable with it, and I wanted to combine this with an integration with a server/database.

Design and Stack

When originally planning my blog, I wanted to balance the devops between managed services and self hosted. For my dissertation project I used a database provider called Supabase, which provides a free tier and great integration with a variety of application frameworks. This seemed perfect, along with Next.js which is a frontend framework utilizing React. So I setup a database and spun up a VM on Linode, and this is what initial my Stack looked like:

• Supabase - Database
• supabase.js - Database integration
• Next.js - Frontend framework utilising Typescript/React
• Chakra UI - Frontend UI components
• Nginx - Reverse proxy/HTTPs management
• Ubuntu - Server OS

I enjoyed the combination of Frontend tools here. Chakra UI is super easy to style the way you want it, as any style or layout information can be passed as props. Layouts were also simple to use. This looks like TailwindCSS, but I found Chakra much more organised:

...
      <VStack paddingTop="2rem" align="center">
        <Heading as="h1" size="2xl">
          {post && post?.title}
        </Heading>
      </VStack>
...

On the database side, I setup a table to store blog posts, with the content as Markdown and the metadata stored in other columns. IDs were based on CUIDs. Here’s what the Post table looked like

The frontend could process and API requests using server-side rendering, meaning API calls could be made by the server and render the HTML there. This meant that no client-side Javascript was needed, so the website was snappy and secure. Markdown was parsed using the react-markdown component which was then customised with some Chakra UI elements.

The website was served using Nextjs, which was then put through an Nginx reverse proxy to manage the SSL/HTTPs certificate and connections.

Here’s what it looked like:

Not so Supa(base)

While I was enjoying the ease of use of the frontend, using Supabase for such a small project was not sustainable. On the free tier, the database would shutdown after a week of inactivity and would have to be manually restarted. This meant my website was down if I or no one else visited regularly. If I wanted 100% uptime this would cost ~£20, which was way too much to spend on such a small database. I instead migrated my backend to the following setup:

• PostgresSQL - Database
• Prisma - Database management/integration

Using my own DB was easier and cheaper, so that was the right choice. Prisma as a tool was a bit overcomplicated but it got the job done.

Goodbye again

Despite how much I enjoyed developing this setup, another rewrite was inevitable:

• Writing a lot of the components and pages in React became time consuming. While I do enjoy using React, especially Chakra UI, it can feel like a lot of overhead and boiler-plate for sites that do not require constant interactions.
• Using database abstractions became annoying to maintain. Supabase, as state before, was not worth the constant restarting nor the price. Prisma was nice because it auto-generated types, but using their database migration was more of a chore than a help. For really complex schemas I can see Prisma being useful. But for a very simple table and type scheme like main, again, way too much overhead and hassle

I was contemplating moving to building my own backend in Rust or GOLang, but I opted against this after discovering Astro.

Here we are - Blog V4

After realising I wanted something more lightweight, I decided to look at static site generators, and Astro seemed like a versatile tool as:

• The layout for .astro files is great. Typescript code is included at the top of the file between --- and the HTML below it. This looks a lot cleaner and comes with a lot less boilerplate compared to React/Next.js.
• It can generate to a static site, or I can use an ‘adapter’ to run server side rendered pages in the future
• I can used frameworks like React in islands if needed in future

So here you are, reading my first blog post, enabled by:

• Astro - Frontend framework
• Tailwind CSS and Prose - Frontend component management
• Markdown - Blog files
• Nginx - Static server hosting
• Ubuntu- Server OS

You can find the source here on Codeberg.

What I learnt, and next steps

Despite the ups and downs of this whole process, I feel I have learnt a lot. The main things I can say are:

• When working on my own personal projects, I often feel a need to “reinvent the wheel”, going in with the desire to learn more about the framework/technology I’m working with. While it has been helpful, this, along with my perfectionism, sometimes prevents me from finishing projects and getting to a state where I’m truly happy with them. Keeping the frameworks and scope simple allow me to get more into it, so I will bare this in mind in future.
• Managed services are not always more convenient, and often much more expensive. When choosing technologies, evaluate the complexity of your task. Supabase was overkill for a blog, but could be useful for a personal project with more throughput. Remember to factor in the actual cost too!

Some things I might consider for the future on this site:

• Consider further pages, like a portfolio.
• Consider using a static site hosting provider over my own manage instance for ease of use

If you’re interested in what else I have to share, you can follow the RSS feed here, or check out my projects below!