{
  "$type": "site.standard.document",
  "canonicalUrl": "https://handyman5.github.io//posts/baked-data-architecture-pattern",
  "path": "/posts/baked-data-architecture-pattern",
  "publishedAt": "2021-01-15T19:00:00.000Z",
  "site": "at://did:plc:yxhvd47p53gmb5zfiktqq3og/site.standard.publication/3mohn6mqvab25",
  "tags": "patterns",
  "textContent": "I learned about this recently from this blog post, and it seems like a really robust tool to have in my tool belt:\n\n\n\n> [M]ost of the site content lives in a SQLite database, and I use custom Jinja templates to implement the site’s different pages.\n> This is effectively a variant of the static site generator pattern. The SQLite database is built by scripts as part of the deploy process, then deployed to Google Cloud Run as a binary asset bundled with the templates and Datasette itself.\n> I call this the Baked Data architectural pattern — with credit to Kevin Marks for helping me coin the right term. You bake the data into the application.\n> It’s comparable to static site generation because everything is immutable, which greatly reduces the amount of things that can go wrong — and any content changes require a fresh deploy. It’s extremely easy to scale — just run more copies of the application with the bundled copy of the database. Cloud Run and other serverless providers handle that kind of scaling automatically.\n> Unlike static site generation, if a site has a thousand pages you don’t need to build a thousand HTML pages in order to deploy. A single template and a SQL query that incorporates arguments from the URL can serve as many pages as there are records in the database.",
  "title": "The “Baked Data” architecture pattern"
}