What Is Server-Driven UI

Server-Driven UI (SDUI) is a way of building apps where the server decides what a screen contains and the client only draws it. Instead of shipping a hand-written screen for every page, the server sends the UI as data — an ordered list of small, typed descriptions in JSON — and the client reads that list and renders each entry. Two words to fix now, because the rest of the course leans on them: a section is one self-contained region of a screen described by a small JSON object, and a registry is a lookup table that maps each section's type name to the component that knows how to draw it.

The whole idea is one flow: the server builds a JSON description, the client walks it, looks up each type in the registry, and stacks the matching components in the listed order.

A generic renderer is the key phrase: one program that draws whatever the server describes, rather than one program per screen. The client never decides what a page contains — it only knows how to turn each description into pixels.

The payload really is just JSON — no code crosses the wire, only a description. Here is a whole screen expressed as data: a page name plus an ordered list of sections.

{
  "page": "projects",
  "sections": [
    { "type": "header",     "title": "Projects" },
    { "type": "image_list", "title": "My slides", "data": "project_slides" }
  ]
}

The server chose these two sections, in this order. The client looks up "header" and "image_list" in its registry, mounts the matching component for each, hands it the section's data, and stacks them. Because the layout is the list, rearranging, adding, or dropping a section changes the screen — with no new client code written.

To see why SDUI matters, picture the classic approach it replaces: the client owns the screens. Every screen is a code file compiled into the app the user installed, so the app itself knows what "Home", "Profile", and "Settings" look like. Changing any of them means editing that code and shipping a whole new build.

That last box is the pain. A native mobile app must be rebuilt and resubmitted for store review for even a small change, and every user has to update. A web app skips the store but still needs a redeploy, and old tabs keep running the old code. The screens are frozen into whatever build each user happens to have.

SDUI flips that. Because a screen is a JSON description looked up in a registry, a new screen is a JSON edit plus, at most, one new component registered once — not a new architecture. This discipline has a name: config over code. A new screen, a new region, or a new flow should be a change to configuration (the JSON), not a new hand-built code path.

The payoff is one renderer serving unlimited screens. The same generic renderer, fed different payloads, produces completely different pages — and none of them is its own screen file.

The only time you touch client code is when a genuinely new kind of section appears — a chart type the app has never drawn before. Even then it is one component, registered once, and every page can then use it.

SDUI works because of a single, strict boundary about who owns what. The server owns what to render and the data behind it — which sections appear, in what order, filled with which values. The client owns only how each section type LOOKS — the pixels, spacing, and interactions of one component. Nothing crosses that line.

This is what keeps the client "dumb" in a good way: if it never invents a layout or a URL of its own, the server stays in full control of both the UI and the data, and there is only one render path to get right. Keep this boundary in mind for the rest of the course — almost every design choice in both case studies falls out of it.

The reason teams adopt SDUI is speed and leverage. Because screens live in server data, you can change them without a client redeploy or an app-store review, and every client picks up the change on its next request.

Three concrete wins follow, and they compound:

• Ship without a rebuild. A screen change is a data change on the server. No store review, no forced app update, and all client platforms move at once.
• A tiny team stays small. One renderer and one section contract mean new work is filling in a known shape, not inventing new plumbing. A small team can carry a broad product.
• Review becomes a JSON diff. Adding a screen shows up as a few lines of changed configuration, so it can be read and approved in minutes instead of audited as a new code path.

The cost side is real and is the subject of later days: you must build the renderer and registry up front, and you must handle the hard case where the server sends a type an older client does not know. But when a product has many screens, many clients, or a small team, those costs buy a lot.

The rest of the course learns SDUI by taking apart two real systems that use it very differently, which is the fastest way to see what is essential versus incidental. Both obey the same one-sentence idea — the UI is data — but they name their pieces differently and make different trade-offs.

Days 2–5 follow SpatialX and its page → sections → actions contract, right down to the gigapixel annotation canvas. Days 6–10 pick up Alphazed, whose three nested SDUI layers push the same idea further — and whose need to serve many app versions at once forces the forward-compatibility discipline that is the real crux of SDUI. Where the two systems disagree, we will say so precisely; the disagreements are where the lessons live.

• Server-Driven UI means the server decides what a screen contains and sends it as data (a JSON list of typed sections); the client is a generic renderer that draws whatever it is handed.
• A section is one self-contained region described by a small JSON object; a registry maps each section's type name to the component that draws it.
• The classic alternative bakes each screen into the client build, so any change needs a rebuild — and, on mobile, a store review and a forced update.
• Config over code: a new screen is a JSON edit plus at most one component registered once, not a new architecture; one renderer then serves unlimited screens.
• The one hard boundary: the server owns what to render and the data; the client owns only how each type looks. Nothing crosses that line.
• The payoff is shipping without a client redeploy, a small team carrying a broad product, and review that is a JSON diff — paid for with up-front renderer work and forward-compatibility discipline.
• The course learns SDUI from two real systems: SpatialX Orca (page → sections → actions) and Alphazed (workflow → step → widget → sections → content_bits).

• [ ] I can define Server-Driven UI in one sentence and explain "the UI is data".
• [ ] I can explain what a section and a registry are, and how a type name becomes a rendered component.
• [ ] I can describe the classic client-owns-screens approach and why changing a screen is expensive there.
• [ ] I can explain "config over code" and why one renderer can serve many screens.
• [ ] I can state the one hard boundary: the server owns what and the data; the client owns how it looks.
• [ ] I can list the payoffs (ship without redeploy, small team, JSON-diff review) and the up-front costs.
• [ ] I can name the two case studies and one way their SDUI vocabularies differ.