Time for some upgrades!
OK, I've been a little busy with my day job, but I think a year is long enough to leave my site untouched, and it's time to do some upgrades, so here's two that might be interesting to tackle.
Strapi
I'm not a big fan of Strapi anymore, if I'm being really honest. The reasons for that have a lot less to do with the technology and more to do with the ham-handed migration from v3 to v4 and response to the issues that early adopters brought up, particularly with respect to the changes to their handling of GraphQL. To paraphrase, "Suck it, this is what we're doing. Don't like it? Maybe you should just use REST."
Yeah, no. Thanks.
That said, Strapi is an open source project, and with that comes the acceptance that you get what you get and you don't throw a fit. They have their reasons for what they're doing, and I haven't paid them one red cent for the right to complain about it. Now, what I have done is used that product in consulting engagements and found myself in a bind. That, I do not like.
So, my plan in the short term is to get off it where I can and just deal where I can't (until I figure out a reasonable alternative.) I think, in this case, I'll attempt to do the V3-V4 upgrade, since there's not much here, and I'm the only one who ever looks at it.
Next.js and Remix
On a different note, I've recently discovered Remix. Now, I've used Next.js for several engagements and have had no particular problems with it. The static site generation aspect has been lovely for larger content sites-- particularly in how it enables better SEO than a straight-up client-side React app.
I have run into a couple of issues that are, let's say, sub-optimal. In one case, I have a site that's got circa 10K pages. If I make a change to that site, it is non-trivial to rebuild it. At one point, the Netlify build servers were running out of memory after about half of those pages were built. I did find a work-around for that, but it took me several hours to debug and fix.
Still, Next.js is great for what it does. Remix is just... different. And interesting. And accomplishing much of the same stuff. So, I'm gradually migrating to it for new projects.
Remix in a nutshell
Everything old is new again. Remix is really a way to do server-side apps. Again. After we all agreed not to do that.
So, why on earth would I want to get back into that mess? Well, it turns out that a lot of what I build into apps, like authentication, caching, API interactions, you name it, is just easier on the server.
If you do your API integrations on the server, you don't have to worry so much about hiding authentication secrets, for instance. You can worry less about passing tokens around, hitting the API for each client for the same stuff, and more about just giving the client the content they want.
I find I can do dead simple graphql-request GraphQL queries and accomplish what I need without the complexity of Apollo's client, which can be pretty over-wrought for a simple content query or CRUD mutation.
You can also enhance your security by configuring firewalls so "this server can talk to this other server" instead of "anyone in the world can talk to this server" and everything bad that that implies.
And it's fast. Like, really, really fast. The server can render the HTML and serve it up much faster than you can package up everything, ship it to the client, and have the client render it. Remix handles that by rendering the HTML, sending that display-ready to the client, and then re-hydrating (i.e., wiring up interactivity) after the client is already displaying the content.
The net effect is that the user experiences a very quick page display that's probably re-hydrated before they even have a chance to decide what they want to do next.
More Not Free Lunch
It's not all rainbows and unicorns. Wiring up something like Material UI to work with Remix is a bit of a trick because of some Emotion styles caching shenanigans. There are some libraries that just don't work on the server, and so there's a bit of care to be taken around anything that expects a window or a document, for example.
Still, short of integrating with custom libraries for existing projects that just weren't built for server-side rendering, I've yet to run into anything I just can't do on the new projects on which I've used it. The benefits have definitely out-weighed the costs.
What's Coming
I hope to document these upgrades to some degree for anyone who might be interested in doing such a thing. If I can save anyone a few minutes navigating the not-always-developer-friendly or stable documentation of these projects, I'll have paid some small debt back to the Saint of StackOverflow.