I want to run you through two changes I have recently made to my personal site. Both accidentally intertwined. One change is user-facing, the other is back-end and architectural. These changes are:

1. Removing JavaScript from pages on the site.
2. Creating an event-driven page publishing pipeline in AWS and Terraform.

Some Background and Rationale

I built this site when I was still a university student in 2018. Initially it was just a bare-bones HTML page with links to my social media accounts, a list of my skills and some projects that I was proud of it. It was very basic stuff.

Then in 2020 I started blogging on the site, detailing some contributions I had made for hacktoberfest. I blogged again the year after, then took a year hiatus, before making some blog posts about prodcedurally generating some dungeons for a game and then in 2024 I wrote a blog about triangulating images. My blog writing frequency subsequently increased.

When I started blogging, I created an HTML page which loaded in some JavaScript to render a list of blogs. It wasn't perfect, but it did the job of adding a navigable page from which users could go. I didn't think I would be blogging much when I built it and so that option was good enough.

Recently, I have wanted to move away from unnecessary client-side JavaScript and - not that I write for clout - not having that list client-side rendered might improve my SEO. So I decided that I wanted to have that blog list statically rendered and served to the user purely as HTML.

I already had a serverless blog publishing pipeline built using CDK, Lambda Functions and S3; I thought it would be good to plug into that existing system. This turned into biting off a little bit more than expected.

Part of the issue is that I had not touched CDK for many years. I used CDK at the time of writing the publishing pipeline, but I hadn't used it since then; I frequently used Terraform at work and so I decided to move to using Terraform. I also took the opportunity to re-architect the whole pipeline and make it easier to plug into.

Moving to an Event-Driven Pipeline

Below you can see the new architecture.

It is a simple serverless event-driven architecture (EDA).

The general flow of the architecture is as follows:

1. Markdown files or JSON data are placed into respective S3 buckets, along with template files.
2. On the event of an object being inserted into one of these S3 buckets a respective lambda function is triggered which populates an HTML template with the inserted data.
3. These template populating lambda functions send a message to an SNS topic which in turn adds a message to an SQS queue.
4. The queue triggers a derived event, in the form of a lambda function, that publishes the templates to the site.

If you're reading this post directly on the site, the above pipeline published the post.

You may be wondering why I chose EDA for this. People often associate EDA and it's messaging queues with scalability, but that is not a concern here; I won't be publishing enough posts to need huge scalability.

There are three reasons I chose EDA, minus the fact I simply find EDAs cool.

Firstly, I wanted some level of fire-and-forget. I normally write on the weekends, and there are normally things in the real world to be doing on weekends. With this architecture, I can populate a bucket with a my blog post in markdown form and see it on my site moments later. The time spent publishing the post is time I can now spend playing with the dog, go for a walk or any other weekend activities. If there's an issue, I can debug it later and some of the process will be completed anyhow.

Secondly, there is quite a level of modularity of EDAs. I program on the site occasionally - sometimes months apart - and again on the weekends or in the evenings. Having each part of the pipeline be modular and self-contained means that it is much quicker for me to get back up to speed and do any bug-fixes or upgrades. And what of new features in the pipeline?

Evolvability and extensibility is the third reason for me choosing an EDA. With this decoupled architecture I can easily add further derived events to the pipeline. Perhaps in future I will develop an RSS feed that is updated after the publish to website lambda is ran. I may also want a site map built when the same lambda is triggered. With the current architecture, adding these will be trivial; the publish lambda can push to an SNS topic that triggers further derived events.

Conclusion

It felt meaningful to be architecting and building something that I will frequently use, a lesson I learnt when building my TTRPG Dungeon planner.

What started out as a simple activity to remove JavaScript from my blog list soon turned into a side quest of rearchitecting my publishing pipeline.

The site is better for it, I cleaned up tech debt and, frankly, it was fun to jump back into EDAs.