Choose Your Path
You now have a Vista — a runtime handle over your data that works the same no matter what’s behind it. Everything up to here was the foundation. Everything past here is the reactive stack: a local cache, an event bus, and watchable views that update as the data changes.
That stack is backend-agnostic, and the rest of the guide proves it by forking here into two paths. Both build the same layers — Dio, Lens, Augmentation, Scenery, and a watch-streaming HTTP server — and differ only in the backend underneath. Pick the one shaped like your problem; the code you write is nearly identical either way.
Which one is yours?
Your data lives behind something slow you cannot change — a cloud API, a legacy service, a third-party endpoint. It is read-only, hundreds of milliseconds away, and cannot sort, search, or paginate. You want a fast, queryable local view of it.
The example builds an inventory of a public S3 bucket (NOAA’s climate archive) — thousands of files served seamlessly and responsively. Diorama caches the listing, injects the capabilities S3 lacks, and enriches each row from its contents; the path ends with a terminal UI (ratatui) and an Axum API feeding a React frontend.
Take Path A → — steps 5–8.
Your data lives in a relational database you own — you read it, write it, and it already sorts, searches, and joins. What you want is a live, cached, watchable facade in front of it: instant reads, changes streaming to every viewer, writes routed on your terms.
The example builds a bar’s product inventory whose stock ticks down in real time as items sell. The same caching, reactive, watch-streaming stack — and the path ends by moving the app from SQLite to PostgreSQL with a single switch, proving the backend was never load-bearing.
Take Path B → — steps 5–7.
Why the guide leads with S3
If you own a SQL database, an S3 bucket may look like a strange place to start teaching caching and reactivity. That is deliberate. A slow, read-only, capability-poor backend makes the value of the layer above visible: every millisecond the cache saves, and every sort the backend cannot do but Diorama can, is obvious. A capable SQL database would hide the very problem the reactive stack solves — so Path A teaches it where it shows, and Path B proves it was never about S3.
| Path A — Custom API (S3) | Path B — Relational DB (SQL) | |
|---|---|---|
| Backend | slow, remote, read-only | fast, local, writable |
| Sort / search | no — Diorama injects it | yes — natively |
| Writes | routed elsewhere (the master can’t take them) | routed to the database |
| Reactivity source | periodic reconcile (S3 can’t push) | your own writes + reconcile |
| The payoff | a rich handle over a poor backend | a live facade, then a backend swap |
Both paths converge on the same idea: once a Dio wraps a Vista, nothing above it knows or cares what the backend is. Read whichever path is yours — or both, and watch the code stay the same while the backend changes underneath it.