Launch Control

One of the app's highlights is its live telemetry. It runs at a high frame rate, continuously estimating where the rocket is right now — altitude, velocity, acceleration — and every two to four seconds it snaps back to the real numbers the API reports. Smooth on screen, honest underneath.

It takes two things, and both live in one view file. First, the presentation. The panel is a list of named widgets — separators, rows, stats, a countdown — each a few lines of YAML, no view code. The telemetry block is a separator and a row of three stats:

Second, the scripting. A raw altitude_km only changes when the API answers — every few seconds. To make it move every frame, each stat's value is a snippet of Rhai that projects forward from the last sample:

The projection is only ever as right as that last sample: if the API stalls mid-flight it keeps climbing and sails the rocket clean past MECO — main-engine cut-off — into open space, until the next reading reels it back.

The data behind a single launch is scattered: the launch row itself, the agency that flies it, its rocket and pad, the crew aboard, the payloads riding up — across a dozen tables and as many API endpoints. Vantage pulls all of it onto one Summary page. And because this API can only be asked, never pushed, it keeps that page current by polling — once every couple of seconds today, and that's configurable.

Each relation is a line or two of YAML — a foreign-key column with references: for a belongs-to, a references: entry with kind: has_many for a has-many — declared once on the table:

And rendering it takes no query. The Summary's right column — total payload, the crew, the payload manifest — is just a few more widgets, each one following a relation:

That ease is the point: a view traverses the relationships for you. The crew list follows crew into launch_crew, and each row reaches on through to its astronaut — row.astronaut.name — so the name comes straight from the astronauts table, no join to write. The payload list does the same through payloads for each name and mass.

The server is usually fine; the network between you and it often isn't — mobile data, hotel wifi, a train tunnel. Vantage is built so none of that reaches the screen: the app stays usable on an unreliable connection and recovers on its own. Two cases are worth walking through.

Two things can go wrong upstream: the API server can lag or answer with a 503, and the network in between can simply time out. Neither reaches your eyes. Inside Vantage a cache and the UI sit together and talk directly — in-process, no network — so the screen always renders from the last good data, instantly, while fetches happen quietly behind it.

Writes are eventually consistent. Vantage builds each change as an idempotent operation — applying it twice has the same effect as applying it once — so a write that fails or times out is simply retried until it lands, with no duplicates and no half-applied edits. You make the edit; Vantage makes sure it sticks.

A browser tab is essentially single-threaded — pile on concurrent requests, a large dataset and a stream of live updates and it stutters. Vantage is native and multi-threaded, async to the core: fetching, caching and rendering run in parallel on real threads. It's polished machinery that scales to large data and dozens of live views at once — without lagging, dropping frames, or falling over.

"New simulated launch" opens a dialog — and because the form is derived from the launches table, its foreign-key fields render as real dropdowns, with no options hand-listed. One is dependent: pick a provider and the rocket list narrows to that agency's configurations, from depends_on + filter_column alone.

The hosted demo is convenient, but you don't have to take our word for it — the whole backend is in the repo: a small Rust server (SQLite, served on the same Vantage framework the UI consumes). You can build and run it yourself in a couple of minutes. No Rust yet? Install the toolchain first:

Then point the example's datasource at your local server — one line of YAML:

Both halves are built from the patterns an AI coding agent is good at — typed Rust models and expressions on the server, declarative YAML on the front — and Vantage ships skills (task guides the agent loads on demand) for each one. So you describe what you want, and it makes the edits.

Ask for "a success rate on each agency," say, and it adds one computed expression on the server — query_launches() is just the with_many relation reused as a subquery, aggregated on read:

Then surface it — one line in the table, rendered with its unit, no UI code:

The same ask scales up: a new model and endpoint on the server, or a new table, page or view in the console. Each has a skill, so "add X" is usually a sentence — not an afternoon.

Everything you've seen — a generic app you download once, a console that's a folder of YAML, real-time data without plumbing, a UI that stays calm when the API doesn't, a field added in two lines — is the same shape you'd use to launch a campaign, ship a deploy, or run an overnight job. Less cinematic, identically built. And once it's a folder of YAML, you hand it around your organisation like any other file: check it in, diff it, distribute it.