I haven't posted here recently. That's largely because I did the classic "Time to rewrite the blog, I'll post when it's done" thing. Well it's not done, but I messed up by not sharing my thought process and reasoning for the re-write. So, I'm trying to rectify that now with some scant and scattered sentences.
The blog is currently built using a custom Node app that lives inside a few AWS lambda functions.
To begin with I created my own auth system (insert eyeroll emoji I know) which works like this:
Once the user is authenticated they can create posts which looks like this:
The benefits of my current setup are:
- Entirely static.
- No server to maintain.
- Provides ability to post from my phone using the /admin interface in the browser.
The things pushing me to consider a re-write, are:
- Local development is hard. The site generation is very tightly coupled to Lambda. There is no local server option for /admin.
- Because of its disorganized nature it's getting harder to maintain and add features (high microservices :wave:).
- Fully reliant on AWS stack (Lambda, DynamoDB, Cognito, S3, CloudFront, Certificates, Route53).
Where do I want to go?
I'm thinking of moving towards what I call "The Jekyll model": an engine to build the site. I could then combine that engine with the following functionality to fill in the gaps:
- Mobile publishing via SFTP of markdown files to a VPS/home server.
- Use a file system watcher to trigger new builds when a new post is uploaded/changed.
- Built site is uploaded to Netlify, S3, or Github pages. Keep it static.
Going this route addresses all the Drawbacks but introduces a server to maintain. I'm OK with that change if I can iterate on design changes quicker than I can now, did I mention how painful that is currently? The one aspect of this I don't have solved completely is post metadata (remember currently I'm using SQLite as my DB). I'm not a huge fan of the front-matter + markdown file approach because I'd rather have my data in a more standard data structure, e.g. a JSON file per post or something. If I go with a JSON file per post then I need to create something to generate that file upon post creation or modification. The other option is to keep using SQLite I guess.
The above should work. I just need something that consumes markdown and can match my existing URL scheme. I've ping-ponged back and forth between the following options:
I initially thought I would build out the engine myself in Common Lisp (to get more experience in CL). Part of the draw of Common Lisp was that I could create an executable and send that to the server and not have to install a bunch of dependencies just to get it to run. However the lack of a markdown library that supports code-fencing (which I use extensively) has killed the idea (and my spirit).
I toyed with just using Jekyll/Hugo but I would have to convert every post to MD + front matter. That sounded like a pain. I've also thought about using GatsbyJS but that introduces a ton of new tech that my site doesn't need.
I don't really want to do Node again because:
- I've done a lot of Node recently
- Requires installing dependencies and language runtime on server.
I'm currently considering upping my fledgling Rust game and writing my engine in Rust. I can then create a binary and ship that to a server. And yes, before anyone asks I already checked and there are several solid looking markdown crates (libraries).
I have no idea where this leaves me. This post has been a thinking/documentation exercise for me more than a post. I think I'll keep exploring the Rust option and see where that leads me.