2021-07-29 baked-data pattern + Hypertext On Whatever (server side tech) you’d Like: HOWL ¶
The Baked Data architectural pattern ¶
I’ve been exploring an architectural pattern for publishing websites over the past few years that I call the Baked Data pattern.
It provides many of the advantages of static site generators while avoiding most of their limitations.
I think it deserves to be used more widely.
I define the Baked Data architectural pattern as the following:
Baked Data: bundling a read-only copy of your data alongside the code for your application, as part of the same deployment
Most dynamic websites keep their code and data separate: the code runs on an application server, the data lives independently in some kind of external data store—something like PostgreSQL, MySQL or MongoDB.
With Baked Data, the data is deployed as part of the application bundle .
Any time the content changes, a fresh copy of the site is deployed that includes those updates. I mostly use SQLite database files for this, but plenty of other formats can work here too.
This works particularly well with so-called “serverless” deployment platforms—platforms that support stateless deployments and only charge for resources spent servicing incoming requests (“scale to zero”).
Since every change to the data results in a fresh deployment this pattern doesn’t work for sites that change often—but in my experience many content-oriented sites update their content at most a few times a day. Consider blogs, documentation sites , project websites—anything where content is edited by a small group of authors.
Benefits of Baked Data ¶
Why would you want to apply this pattern ?
A few reasons:
Inexpensive to host ¶
Anywhere that can run application code can host a Baked Data application there’s no need to pay extra for a managed database system. Scale to zero serverless hosts such as Cloud Run, Vercel or AWS Lambda will charge only cents per month for low-traffic deployments.
Easy to scale ¶
Need to handle more traffic ? Run more copies of your application and its bundled data. Horizontally scaling Baked Data applications is trivial.
They’re also a great fit to run behind a caching proxy CDN such as Cloudflare or Fastly—when you deploy a new version you can purge that entire cache.
Difficult to break ¶
Hosting server-side applications on a VPS is always disquieting because there’s so much that might go wrong—the server could be compromised, or a rogue log file could cause it to run out of disk space.
With Baked Data the worst that can happen is that you need to re-deploy the application—there’s no risk at all of data loss, and providers that can auto-restart code can recover from errors automatically.
Server-side functionality is supported ¶
Static site generators provide many of the above benefits, but with the limitation that any dynamic functionality needs to happen in client-side JavaScript. With a Baked Data application you can execute server-side code too.
Templated pages ¶
Another improvement over static site generators : if you have 10,000 pages, a static site generator will need to generate 10,000 HTML files.
With Baked Data those 10,000 pages can exist as rows in a single SQLite database file, and the pages can be generated at run-time using a server-side template .
Easy to support multiple formats ¶
Since your content is in a dynamic data store, outputting that same content in alternative formats is easy.
I use Datasette plugins for this: datasette-atom can produce an Atom feed from a SQL query, and datasette-ics does the same thing for iCalendar feeds .
Integrates well with version control ¶
I like to keep my site content under version control.
The Baked Data pattern works well with build scripts that read content from a git repository and use it to build assets that are bundled with the deployment.
It’s either static files generated at build time or HTML created exclusively by JavaScript on the client ¶
Getting the impression that the very idea of generating HTML server-side at runtime is alien to a sizable portion of web developers these days
It’s either static files generated at build time or HTML created exclusively by JavaScript on the client
Maybe we need a catchy acronym
https://twitter.com/htmx_org/status/1420793147882315776?s=20 ¶
Hypertext On Whatever (server side tech) you’d Like: HOWL
HATEOAS has proven a loser
Hypermedia Exchange As The Main Application Pattern - HEATMAP
alternatively Ha, U R Dumb, Use hypeRmedia - HURDUR