Server-Driven UI: The UI Is Data

Server-Driven UI (SDUI) built one piece at a time: what it is and why, the section contract, actions as hyperlinks (HATEOAS-lite), forward compatibility and unknown-type handling, behavior as data, and building sections in isolation. Grounded in two real implementations — SpatialX Orca’s React/OpenLayers pathology canvas and Alphazed’s Flutter workflow/screen/section/content-bit renderer.

1. 01What Is Server-Driven UIServer-Driven UI taught through two production systems: SpatialX Orca (a gigapixel medical-imaging and cancer-AI web app) and Alphazed (a kids' learning app). • Day 1 sets the whole idea in one sentence: the UI is data. The server sends an ordered list of typed UI descriptions, and the client is one generic renderer that looks each type up and draws it.9 sections
2. 02The Section ContractCase study 1: SpatialX Orca. A page is `{ page, sections: [...] }`, and every section on every screen is the same tiny shape — a DynamicSection. • Day 2 zooms into that shape: an `id`, an `options` bag, and an `actions` map. The id is looked up in a mapper to find the component; an unknown id falls back safely instead of crashing.9 sections
3. 03Actions Are Hyperlinks (HATEOAS-Lite)Each section arrives carrying the exact URLs it may call as `{ url, method }` links; the frontend follows them and never builds a route by hand.8 sections
4. 04Build a PageGrow a screen by appending section objects to a list — then watch one contract flex from full CRUD down to read-only without changing the renderer.8 sections
5. 05The Canvas Is SDUI TooEven the hardest surface in the product — a gigapixel whole-slide annotation canvas — is just four sections in a list. No bespoke canvas screen; SDUI all the way down.10 sections
6. 06SDUI in AlphazedA completely different product — a kids' learning app — reaches for the same idea, and pushes it further: three server-driven surfaces running at once, from onboarding flows to learning games to home-screen tabs.10 sections
7. 07The Client Renderer & RegistriesCase study #2, Alphazed: the client side of the same idea. • The React Native renderer mirrors the backend JSON into models and dispatches every screen through three nested registries — workflow to widget, screen to sections, section to content-bits.9 sections
8. 08Forward Compatibility & VersioningThe crux of server-driven UI: what happens when the server sends a type the client has never heard of. • Two answers run at once — the client degrades gracefully, and the server gates by app version — because Alphazed ships one backend to many app versions.11 sections
9. 09Behavior as DataServer-Driven UI, grounded in two production systems: SpatialX Orca (a gigapixel medical canvas) and Alphazed (a kids' learning app). • Day 9 pushes the idea one level deeper: not just the screen, but the *flow* and the *rules* become data too. A workflow graph, a job blueprint, and small per-widget config blobs replace hand-written controllers — while stopping deliberately short of a scripting language.10 sections
10. 10Build in Isolation, Reuse EverywhereServer-Driven UI, grounded in two production systems: SpatialX Orca (a gigapixel medical canvas) and Alphazed (a kids' learning app). • Day 10 is the capstone. It shows the payoff of everything so far — a section built off to the side, proven with tests, registered once, and dropped into any page — and then asks the honest question: when is all this machinery worth it, and when is it not?9 sections