I started hosting a set of web apps at fly.io about a year ago, and for the most part loved their developer experience. Publishing an application was a quick command-line operation, similar to heroku.
But after months of running several small-scale apps on fly, I've found that their platform just isn't as reliable as I need, so unfortunately I've had to migrate to something else.
The most frequent issues were just random downtime, usually caused by network flakiness somewhere in their infrastructure. I'd get alerts from a monitoring service, and at least one or two apps would be unavailable for a while. The down time was usually brief, maybe 10 - 30 minutes, but once or twice was at least an hour. I need more reliability than that.
So for now, I've migrated everything back to a Digital Ocean VM that I'm managing myself. I've had really good luck with D.O. over the years; I've run multiple apps there, too, and had rock-solid reliability.
The downside of running a VM is that I have to manage the VM myself, and deal with deploying apps there, or at least configuring github build actions to deploy there.
I'd like to get out of the business of managing VMs myself, so I'll be experimenting with some other platforms as well. First up is Cloudflare. Their Pages platform looks interesting, and remix supports it as a target platform out of the box. If that works, it should give me reliable deployments with all the ease of fly but with much more solid reliability.
I'll still keep an eye on fly; I really liked them in a lot of other ways, and hopefully they'll get their infrastructure to stabilize more over time.
I liked a lot about nextjs, but its fundamental page building & publishing model seemed awkward to me.
Specifically, the publishing workflow for non-developers just didn’t seem to be a good fit. That’s an important use case for me as I was hoping to use nextjs for some CMS-based sites for “normal” people (not developers).
I loved the great performance I got from a nextjs static site, but that depended on static builds. I knew it wouldn’t fly if I told normal users to wait for new builds after publishing. As leaky abstractions go, that’s a significant one.
I thought incremental static rendering (ISR) might be a good solution after that, but next's ISR caching model just wasn’t right for me, either. I want options like invalidating the whole cache at once when pages are published. Instead, ISR’s happy path is to use time-based invalidation. Not a good fit. I could write lower-level code to invalidate individual pages, but that’s also not quite what I need.
That left me with just a plain SSR solution and no built-in caching. That could have been ok, but it didn’t excite me that much -- and it meant accepting some of the awkwardness of next's page model without really getting more than its most basic benefits.
That awkwardness of not really fitting my needs was one of the weak spots I found in nextjs. It left me open to finding another solution that was a better fit.
I've switched the framework for this site to remix. I was using nextjs before, but I was frustrated by a couple of things and I think remix offers a better solution for my use case. I'll write more about those issues soon. So far I'm really liking remix, though.
I'm moving the backend of this site to the sanity.io headless CMS. The old backend used markdown files in a git repository, and I wanted something I could easily use on my phone. (This site's frontend is still using next.js, which has been great.)
More importantly, I wanted to explore using sanity as the backend for some other sites I've been building and hosting for other people. I've been looking at a few candidates for replacing Perch, and so far sanity seems to be a great alternative. I also (mostly) love the idea of using a SaaS so I don't have to host it myself.
So far I've been really impressed with sanity. It's definitely a developer-focused CMS, so it requires coding to get up & running, but it's been incredibly easy to get started with. And querying for data from my nextjs frontend has been refreshingly straightforward.
Finally switched this site to Tailwind CSS. I've been using tailwind at work for about 2 years now, and it has been great. Have been wanting to switch this site, too. Finally did it.
If you take average risks you will, by definition, get average results.
Instead of minimizing risk, I instead like Jeff Bezos’ pursuance of regret minimization. Of the paths that you can take, which path will most likely result in the least regret later in life?
-- Steph Smith
"Small b blogging" from Tom Critchlow:
As Venkatesh says in the calculus of grit - release work often, reference your own thinking & rework the same ideas again and again. That’s the small b blogging model.