Plan for the site

I'm currently authoring all these blog posts on a local git repo that isn't pushed anywhere. The goal for this month, as I might have mentioned previously, is to have my website live and displaying them, while doing everything as correctly as possible in the process. I'll be briefly enumerating the work so far as well as why I chose to do it that way in this post.

First, writing an Axum + Askama full stack web app to template instead of a static site generator. This allows me more flexibility in how I style the app, how I want my folder structure and file formats to look like, and a greater possibility of custom logic (e.g. games, random stuff) than if I were to go with the alternative. This was not a very hard decision - I've never used a static site generator before, but I have done static sites with no templating and I feel like this is probably the best (and my favourite) route to take. Also, I'm familiar with Axum routing and Jinja templating so it's more natural for me. Lastly, I like Rust and I want to do as many projects as I can with it for learning and, again, for fun.

Secondly, why I chose to package it as a container image with Nix instead of a binary or service. I chose containerisation here for two reasons - one for portability (a service would almost require me to run it on NixOS), and two to gain familiarity with how container images work. The second point ties into why I used Nix instead of a Dockerfile - using pkgs.dockerTools.buildLayeredImage required me to learn exactly what an image is and how it is built, rather than relying on a premade image as a base and layering in what I need. Also, I've done that probably ten times now and I'm sure I will be again in the future. I also wanted to learn more about Nix, which to be honest, didn't really bear fruit - I already knew what a derivation was and how to dig through source code to find out the exact effects of my own, which is all I really needed to know to understand it. Lastly, Nix-built images are smaller and easily cached because each dependency of the final derivation is included as its own separate layer. The portfolio prospects of going with containerisation instead of a self-hosted service was also a factor, but I'll talk more about it in the next point.

Third, why I chose AWS as the provider and an ECS service as the deployment target. This is the only decision that I don't feel good about, but not because I don't think it is the most correct option - I just don't like not self hosting. I already spoke on this yesterday, so I won't go into detail about it. I knew going into the project that I wanted everything to be declarative and chose a stack of Nix for configuration, OpenTofu for IaC not covered by Nix, Rust for application code, and Github Actions (maybe Forgejo in the future) for orchestration and automation. I could have chosen to continue self-hosting my sites as I have been doing for five years at this point, but decided to learn at least one cloud provider, and again to pad my portfolio more. I chose GCP Cloud Run as the deployment target at first, and you can see the results of that here. I used it for my previous project, but that was done manually with no IaC. I ran into so many issues with Cloud Run that I didn't even manage to get the container running after 8 hours of work, so I decided to drop it and go to AWS. I'm glad I did so - I would still choose self hosting in a heartbeat (for cost, control, and pride) but AWS was honestly a treat to work with especially with OpenTofu.

So, now I'll discuss what else I want to achieve before the end of the month. As mentioned, the target outcome is my writing displayed on the website. I author everything in Markdown in ~/publish. I did some thinking during work today about the coming tasks, and decided before I put significant work into routing, and parsing/rendering the Markdown, I needed to figure out how I was going to reference and index the posts. After some deliberation, I've decided to go with the folder structure for organising dates of writing, and everything else as YAML frontmatter tags. For example, this post will go in 2026/01/16/ and be named blog-plans.md with the frontmatter being:

slug: blog-plans
tags: [daily-blog]

I'm not sure yet on the formatting for the tags, or what else to include other than probably a title so I don't have to add a step to parse it from the top level header. Regardless, this should be extensible enough to never have to be amended, and easy enough to work with that I can set up Vim aliases to automate some of the more repetitive tasks or even add a CLI to add and modify articles. On the app side, its simple enough to use axum::extract::Path to extract the date and slug from the URL and use it to search the requested folder for the slug, extract the frontmatter and content, and pass it to an Askama template.

Once the above is completed, I think I'm done with the month. I'm giving myself until the 18th to finish this, because I have the first session of our new TTRPG campaign on the 22nd and I want to devote Sunday to Wednesday to working on fleshing out the setting and the session. With that, I'll see ya tomorrow :)