I've been exploring an architectural pattern for a few years now which I think gives you the best of both worlds: it lets you run dynamic server-side code, but in a way that's both extremely inexpensive to scale up and that is self-healing if anything breaks.

I call it the Baked Data pattern: https://simonwillison.net/2021/Jul/28/baked-data/

The key idea is that you deploy a full read-only copy of your site's data as an asset bundled into your application.

This only works for sites that don't constantly have updates, since you need to re-deploy the entire site when anything changes (just like a fully static site).

Benefits are you can deploy to inexpensive dynamic scale-to-zero hosting (like Vercel), you can handle any amount of traffic by running multiple copies of your app and if the app crashes your host can just restart the application automatically.

Tangentially, I've been exploring something kind of fascinating...

So, in compiled binary executables it was not uncommon to include encoded binary resources, like files or images. Not tons of them, because they would explode the size of the executable.

For example, for C or C++ https://github.com/graphitemaster/incbin

So here's the interesting part - we decided to build executables in a way that data in those executables could not be changed (makes sense since it's compiled and the compiled code runs on the machine, and for security reasons).

That said, think about what a container (e.g. docker) is. A running container is kind of like a packaged executable, except it also has a filesystem.

So if you pack data (which can be modified and runtime!) into a container, it's a similar concept to an embedded resource in an executable, except it can change.

Now, in a container, any changes made to data at runtime inside the container won't persist unless the container is given persistent storage.

What I've been wondering lately is why we didn't invent some kind of single "executable plus volatile data space embedded within the executable", so that programs and data (say, a database) could couple together into a single file.

Just a musing but tangentially related to your "baked data" - basically, embedded resources in executables just embeds the encoded data right into an executable.

For scripting languages, of course, we can just make a script file that contains a variable with the encoded data as base64 directly.

For the latter 2, it's only good for relatively small static data of course, but it would be interesting to build tech that somehow lifted that constraint of executables.