Short posts

I've achieved the goal of having something I control, but there's a weakness here: I haven't found an easy workflow that lets me get short thoughts out quickly and painlessly. Yesterday I wanted to write about a half dozen topics that didn't merit a full journal entry, but didn't have an easy way to do it. I ended up just opening a new note on my phone and brain dumping, which isn't the worst thing ever.

I'm trying to avoid using a database, but a lot of the stuff I want to do is most easily solved with access to a database. A forum of this scale doesn't merit a backend, or at least strongly benefits from being statically generated. On my feature list, however, are a lot of things that become easier if I'm running a real server, or at least building the site off something that has a database available.

… Hmm, now that I think of it, that's not a bad solution. The ideal admin tooling suggests the need for a first class backend, but I can easily use that to generate a static site that gets the benefits of both worlds.

Spitballing here, there are a couple decent ways to get a simple, high speed personal website running in the hosting environment I have available.

• Run a tiny app for one user that has reasonable login protections. When I hit a button, dump some form of the content into a format that a static site generator understands, and have that generator deploy the content to my preferred host (could be S3, could be similar to the current configuration).
• Wire up a tiny blog app that caches aggressively when not signed in. I've seen some of this magic in a previous life; the nginx config used would serve assets directly from nginx instead of routing through rails, boosting app speed. If there's a clean way to have rails do that automatically, I might go that route.
• Use normal app-level caching and hope for the best. I don't much like this one because I would have to do a lot of testing ahead of time to ensure that I could serve hundreds or thousands of requests for the same page without hitting server bottlenecks.

Taking a step in any of these directions will change the calculus I've been using so far. Notably, it's been easy (or, relatively easy) to bulk import/edit preexisting posts to work with this tech stack, but having a database at a distance will make it harder. Since I should be doing more original writing and less migrations as time goes on, the balance of burden will shift.

Looking back at my decisions up to this point, the following facts are true:

• I'm happy that I've kept data, configuration, and code separate so far; it will make any migration to a different platform easy. Many existing frameworks for producing static sites encourage too much commingling of these things.
• The mere existence of this blog has been a great boon, in the sense that I'm writing at all.
• The current form of this site is essentially an MVP: I've got posts on a screen that can be viewed on the internet. In that sense, it's a win so far. It looks like any path forward will demand more backend work and server orchestration, which was half the purpose of this exercise in the first place. I can't say, then, that I'm upset with this state of affairs.

I can't overstate how much having this bootstrapped site up and running has been for my mental well being. I feel lately like I'm overflowing with ideas.