Launch Control

Launch Control mirrors Launch Library 2, the public dataset that tracks spaceflight across every agency on Earth — rockets, pads, payloads, crews and the missions that tie them together. Real domain, real shape, real mess: IDs that are sometimes integers and sometimes UUIDs, objects nested two levels deep, stats that have to be counted rather than stored.

On screen it's a single launch board. Each row is a flight; select one and the panel below fills with its payloads, its crew and its landings. From there you keep going — open a launch's provider to see every mission they've flown, follow a pad to its location, trace a booster's landing to the pad it touched down on. One screen, fifteen entities, drilling all the way down.

And it's not a static snapshot. Hit "New simulated launch" and the server schedules a mission at T-1min, then ticks it through a real sixty-second countdown — To Be Confirmed → Go for Launch → outcome — while the board updates underneath you. No reload, no refresh button. You watch a rocket fly.

Everything in the model orbits a single entity. A launch belongs to a provider, flies a rocket from a pad, carries payloads and crew, and ends in one or more landings. Model those relationships once and the entire navigation of the app falls out of them for free.

There is no frontend code in this example. The console is a handful of declarative files: one datasource, a table per entity, a page, and an action. Here's the path from "an API exists" to "a drillable board", file by file.

1 · Point at the server, once. The api-client datasource learns the LL2 envelope — the array lives under results, the total under count — and pushes filters server-side. Because this server honours every filter param, one datasource drives all fifteen tables.

2 · Declare a table — relations included. Fetch ?mode=detailed so belongs-to objects come back nested, then surface their leaves as dotted columns. A hidden foreign-key column carries references:, which turns its cell into a drill link — and the same references: generate the binder's detail tabs.

3 · Make it a live Binder. The page is a binder layout — grid on top, auto-derived detail tabs below. A toolbar action triggers a simulated launch; a cheap refresh_probe folds the cached rows for a change signal, so a full refresh only happens when the simulator actually moves something.

4 · An action that knows the model. The "new launch" dialog is a table-derived form, so its foreign-key fields render as real dropdowns. One of them is dependent: pick a provider and the rocket list narrows to that agency's configurations, driven entirely by depends_on + filter_column.

Here's the part most demos hand-wave. The API isn't a fixture server — it's a real Rust backend built on the same Vantage framework the UI consumes. SQLite tables become typed entities with relations and computed expressions, every entity collapses into one universal facade, and a single Axum handler serves the lot as a familiar REST API.

Computed stats, never stored. An agency has many launches; its tallies are with_expression aggregates — correlated subqueries the database evaluates on read. Note that query_launches() is just the with_many relation reused as a subquery: model the relation once, count over it everywhere.

One handler, every table. Each entity becomes a backend-blind Vista — the exact same read surface the UI's api-client speaks. A single route reads any table through it, mapping leftover query params to server-side filters. "Consume an API" and "serve an API" turn out to be the same shapes, mirrored.

The server is built to misbehave — that's the test. Every read is delayed by 150–1200ms and, about a tenth of the time, answered with a 503 instead of data. Meanwhile the simulator is mutating rows out from under the grid. The same data path that survives this demo is the one that survives a real network.

The flakiness is honest middleware — random latency, then a probabilistic failure. Crucially it wraps only the read API; the trigger endpoint that starts a mission is left reliable, because writes must land.

The countdown is a plan, then a playback. A simulator phase is a pure function: it returns a list of timed events; the engine sorts them and plays them in real time. Each event stamps last_updated — which the UI's refresh probe catches — so a sixty-second timeline in Rust becomes a live countdown on screen.

Both halves are open source and small enough to read in an afternoon — the YAML inventory and the Rust server sit side by side. Fork it as the starting point for your own backend-and-console, or just run it locally to poke at the live countdown.