how the dashboards work

Static pages. Browser SQL. Optional runtime.

I added a dashboards section.

The first real one is site analytics.

It is not user analytics. It is metadata about this website: content, tags, commits, search documents, and data refreshes.

Constraints: no backend, no hosted database, no tokens, no scheduled job, no heavy JS on normal pages.

part	current	next
data	checked-in `/data/site.ddb`	more declared local/public sources
SQL	DuckDB in the local generator, DuckDB-Wasm after click	Zorto-owned pipeline config
charts	Plotly JS after click	same, still opt-in
artifact	static shell + JS + `/data/site.ddb`	the same shape, generalized

Planned next version:

config.toml declares sources, SQL, outputs, and dashboard bindings
zorto build fetches sources and runs SQL
query output can be rendered into normal pages
build emits .ddb files
dashboards load .ddb files on click and run local SQL

Dashboard contract stays small:

template = "dashboard.html"

[extra]
dashboard_module = "/js/dashboards/site-analytics.js"
dashboard_database = "/data/site.ddb"

The template renders the shell, button, and tiny loader script. dashboard-runtime.js opens the site database and calls module.mount(ctx).

Dashboard modules should not import source data. They get a small ctx: query, exec, plot, setStatus. They ask for tables, run SQL, and draw charts.

Public data can introduce CORS restrictions, slow endpoints, schema drift, null handling, and API changes. Moving fetch/transform work to local build-time scripts keeps the site static and reduces runtime dependencies.

DuckDB handles tabular transforms: normalize timestamps, aggregate commits, index content, summarize tags, and later join richer personal/public activity data. Build-time DuckDB can handle source transforms; DuckDB-Wasm can remain available for local interaction.

The performance rule stays the same: the homepage, blog, dashboards index, and unopened dashboard pages do not download DuckDB. The dashboard runtime loads only after user action.

Architecture:

static shell first. build-time data pipeline. analytical runtime on demand.

This keeps normal pages fast and limits dashboard runtime cost to opt-in interactions.