Skip to content

CONCEPT Cited by 3 sources

Server-Driven UI

Definition

Server-driven UI (SDUI) — sometimes backend-driven UI — is a UI architecture in which the backend decides what the client renders and what happens on interaction, delivering a per-request view configuration (a tree of layouts, components, and actions) that a thin client-side runtime interprets into native (or web) widgets. The client ships a vocabulary of component and action types; the server composes instances of that vocabulary at request time. The client's job shrinks from "implement each screen" to "render whatever configuration the server sends and route interactions back through declared actions."

Contrast with the classic model, where the client owns the screen: layout, copy, control flow, and the behavior of every tap are baked into the shipped app binary (or the shipped JS bundle) and can only change when new client code ships.

Why it exists: the deployment-latency argument

SDUI's load-bearing motivation is mobile deployment latency. On the web, "users are one refresh away from using the latest client code," but native mobile apps carry a unique constraint: "every change requires a new build to be deployed to and reviewed by the platform's app store, and it still requires that users download the latest version once it is available … any change, however small, can take several days to reach the users in the best of cases. In the worst cases, a user may never update the app, and they will remain in a time-locked experience" (Source: sources/2026-09-29-yelp-the-making-of-the-yelp-assistant-ui).

SDUI collapses that latency: "If we ever make a change, all we have to do is update the backend and all clients receive the latest configuration within minutes of the change being deployed." Two consequences engineers cite explicitly:

Anatomy

A production SDUI system typically has:

  1. A component/action vocabulary — the finite set of building blocks a client version knows how to render (chaos.button.v1, chaos.open-url.v1, …). New elements require either a client that understands them or a compatibility mechanism (below).
  2. A view-configuration surface — the wire format the backend emits (Yelp's CHAOS ships components/actions as JSON strings under a stable GraphQL schema; Zalando's AppCraft ships an Elm-architecture-style tree). See json-string-parameters-for-schema-stability.
  3. A client runtime — interprets the configuration, renders native widgets, and routes interactions back through server-declared actions.
  4. A backend composition pipeline — builds the configuration per request (Yelp: ChaosConfigBuilder → ViewBuilder → LayoutBuilder → FeatureProvider).

Backward compatibility: the hard part

Because clients update slowly, SDUI's central engineering problem is serving new UI to new clients without breaking old ones. Two disclosed mechanisms, at two granularities:

  • Client capability matching (feature granularity) — the backend inspects the requesting client's declared capability (platform + supported components/actions) and omits any feature the client can't render, rather than sending something it will fail on. Yelp's CHAOS does first-match Register selection; see register-based-client-capability-matching.
  • Component-version negotiation (component granularity) — each client bundles a spec enumerating the component versions it supports; the request carries that spec; the backend picks a compatible version per component and falls back to a migrate() downgrade on breaking changes. This is content negotiation / protocol negotiation applied to a UI schema (Source: sources/2026-04-22-yelp-how-yelp-keeps-server-driven-ui-consistent-across-four-platforms).

Keeping the wire schema stable while element content evolves (carrying element payloads as opaque JSON strings) is the trick that lets new elements ship without GraphQL-schema churn — at the cost of losing per-element schema validation in introspection.

Hybrid SDUI

Pure SDUI struggles where the client genuinely needs native capability the framework hasn't built yet — text input, outbound network requests, camera, gestures. The pragmatic answer is hybrid native/SDUI: keep a native shell for the hard-to-serverize parts and make only the dynamic region server-driven.

Yelp Assistant is the canonical hybrid instance on the wiki: the top bar and input bar are native, the scrolling chat content is server-driven via CHAOS. The team chose this "because CHAOS doesn't provide affordances to send requests to the backend and support for text input fields did not exist at the time" and "building support for network requests or input fields required more time than we wanted to invest. Our goal was to build something, ship, and start learning." Making the two halves cooperate requires blurring the boundary — a tapped Send in the native bar mutates the server-driven content's dataset; the backend can push a client action (DisableChat) to a native-owned surface (Source: sources/2026-09-29-yelp-the-making-of-the-yelp-assistant-ui).

Relationship to view/data separation

Mature SDUI systems separate the view (the configuration template, often fetched once) from the data (content that hydrates it, streamed as the session progresses) — an application of separation of concerns to the client/server contract. Yelp Assistant fetches the CHAOS view config once at launch, then hydrates it turn-by-turn with MessageEvents; "Whether the client renders a user message, a typing indicator or something completely new does not matter, as CHAOS abstracts it away." This decoupling is what lets new message/feature types be added server-side without a client release.

Tradeoffs

  • Pro: minutes-not-days iteration on native surfaces; cross-platform consistency from one source of truth; reversible decisions; A/B and gating without app releases.
  • Con: an SDUI framework is a large upfront investment ("only a handful of people were familiar enough to build something with it" early in CHAOS's life); a new competency to learn (onboarding cost); cross-platform rendering bugs still slip through ("what works well in one platform is buggy in another"); backward-compat machinery is mandatory; opaque payloads lose schema validation; not everything serverizes cleanly (hence hybrids).

Seen in

Last updated · 766 distilled / 2,225 read