It's nearly the end of 2024 and bringing my blog back is long overdue. This is the initial post I'm creating to kick things off. I'm actually kicking off a lot of new initiatives to bring my physical health back on track, so keeping up with this and making it a habit will be another good way to practice having routines in my life!
I am committed to designing this blog hosting system (on which you read this) from scratch for multiple reasons. This may come as a surprise, but I think it's a pretty interesting problem space, and by hand-rolling an integrated solution, I'll be able to create a flexible and cost effective web platform I can leverage to share content in creative ways. I'll share my design and reasoning here so that everyone, especially future me, can benefit from this information.
Today:
scripts/build.sh shell script converts source data (markdown files, HTML, scripts) into artifacts suitable for static servingIt must be exceedingly easy to create new posts, and edit existing posts. The blog content lives in a git repo, which as a long-time developer makes for a natural workflow for me. As a hard requirement, the only physical steps I must perform to create a new post then is to add a new markdown file into the repository in an easy-to-find place and push it. To further reduce friction, one of my plans for the future is to set up a tag or label in Notes.app (or whatever tool is most suitable at the time) which an automated process could sync from to insert new items into my webpage repo.
Metadata management will be automated. That means that the information about when I wrote a post, when it was edited, and, well, I'm struggling to come up with any more examples, but this type of data shall not be subject to manual data entry. Git tracking makes this effortless.
CI/CD will be used to automate the execution of the build script, which is the entry point for any arbitrary simple webapps I may want to deploy under this umbrella. That is to say, I could have a complex web application under a separate directory in my website's repo, and the main build script will call into any scripts defined inside after detecting them. The concept here is that the main build script will not be burdened by the specifics of any special behavior introduced in pages or posts.
Data source (S3) and CDN (CloudFlare) to be treated as modular appliances. As pricing and market conditions evolve, I will have designed this system to make my website and related platforms resilient and independent from the particulars of these where practical. I endeavor to keep the output of the build.sh script, which is a set of static files suitable for serving directly to browsers, in a format that can exist comfortably in a typical filesystem such as NTFS, exFAT, APFS, Ext3, ZFS, and others, as well as object stores such as S3 and its compatible alternatives.
With an eye to the future, once I exceed 5GB of usage in S3 in my personal AWS account, as that is the limit of its free tier, I will begin to incur S3 storage costs from S3. At this point, I would want to transition over to something more affordable such as Backblaze, which offers a compatible object storage product that is more aggressively priced. I would also want to explore at this juncture hosting the data primarily on my own hardware while employing Backblaze as a data backup. At that point I would point the CDN at Backblaze, and a choice I could make later based on economics and uptime could be to switch to self-hosting and do away with storage based costs depending on how much content I have.
With any application, end-to-end local testability is an important property for ensuring quick iteration during development. Although I do not expect development (at least on the core of this static resource management platform, on which I will implement my blog) to be an extensive development effort, it is important to me as with any other software project that I can take my laptop with a local reasonably-up-to-date clone of the repo, hop on a plane without Wi-Fi (or, equivalently, one that offers an exorbitantly priced Wi-Fi service) and get to hacking without issues. The biggest practical consequence of this is that I may want to bring any reasonably-sized and commonly used frontend software dependencies in-tree.
Well, that's a great long list of notes already so I will stop there for now. I will continue to describe interesting aspects of this system as I continue to build it out.