Cloud Parts

Data apps built ahead of time

A static site generator for dashboards and reports: queries run once during the build, their results are saved as data files next to the pages, and the site is redeployed on a schedule.

How they work

Observable Framework calls these steps data loaders: a script in any language (SQL, Python, R, a shell command) that runs during the build and writes its output, such as a CSV, JSON or PNG file, which the page then loads as a static file with a content hash in its name. Its docs give the reasons plainly: data is precomputed, so pages load instantly; snapshots can be aggregated and anonymized before they leave; and viewers never need access to the warehouse. Freshness comes from rebuilding, for example a GitHub Actions workflow that builds and deploys once a day.

Evidence started the same way in 2021, as “Jekyll or Hugo for SQL analysts”: its build ran every query, pre-rendered all pages and kept serving the last good version if a query failed. Its limits show the trade-off. The legacy version topped out around 2 million rows, needed a build for every data or content change and pre-rendered every page permutation, so Evidence’s current version runs queries on page load instead.

Pick it for reports and dashboards that change hourly or daily and look the same for every viewer. Interactivity happens in the browser over the shipped snapshot, often with DuckDB-Wasm, so keep that snapshot small.

Technologies

What all static read models have in common →

Sources

Improve this page on GitHub