CONCEPT Cited by 1 source

Server-driven UI¶

Definition¶

Server-driven UI (SDUI) is the architectural choice to have the server describe, per request, the UI the client should render — the structure (views, layouts, sections), the content (components with their parameters), and the behaviour (actions tied to events like onClick / onView). The client is a renderer of server-authored configurations; it does not own the layout or the content graph.

Compare with client-driven UI, where layout, copy, and navigation are baked into the client binary / bundle, and the server returns only data.

Why organisations adopt SDUI¶

Decouple UI release from app release. New screens, content changes, and experiments ship without an app-store submission or web deploy — subject to the client already supporting the underlying components and actions.
One design language across platforms. iOS, Android, and web render from the same CHAOS/SDUI configuration (modulo platform-specific layouts), so there's one source of truth for screen composition.
Fast A/B and personalisation. Server can vary the configuration per user / cohort / request with no client work per experiment.

What the server has to describe¶

At minimum, every SDUI system defines four shapes (names vary):

View — a logical screen, addressable by an ID.
Layout — how sections on a view are arranged (single-column, multi-column, mobile toolbar+footer, …).
Components — leaf UI elements (text, button, illustration, list row, …) with typed parameters.
Actions — behaviours attached to components (open URL, navigate to subsequent view, log event, …).

Yelp's CHAOS adds two advanced primitives on top — View Flows (bundled preloaded subsequent views) and View Placeholders (nested async-loaded views) — covered in sources/2025-07-08-yelp-exploring-chaos-building-a-backend-for-server-driven-ui.

Hard constraints SDUI systems must solve¶

Mixed client-version fleet. Old app versions don't support new components. The server must know what each client can render and skip / substitute accordingly — see concepts/register-based-client-capability-matching.
Schema stability vs element iteration. Adding a new component type ideally doesn't require a GraphQL / REST schema change. CHAOS's answer is JSON-string parameters under a stable schema.
Per-feature fault isolation. One bad feature must not break the whole view. CHAOS wraps every FeatureProvider in an error decorator — see patterns/error-isolation-per-feature-wrapper.
Parallel async data loading. Each feature typically has its own data dependencies; the server must fan out upstream calls in parallel — see patterns/two-loop-parallel-async-build.

Known SDUI implementations¶

Yelp CHAOS (canonical on-wiki) — GraphQL-fronted, multi-backend, Python Strawberry subgraph.
Airbnb Ghost Platform (not on wiki) — the widely-cited SDUI precedent.
Lyft Server-Driven UI (not on wiki) — similar shape at ride-hailing scale.
Meta Shops / Facebook Marketplace use SDUI-like internal frameworks (not publicly detailed).

Seen in¶

sources/2025-07-08-yelp-exploring-chaos-building-a-backend-for-server-driven-ui — first wiki instance; CHAOS backend deep-dive.