Skip to content

PATTERN Cited by 1 source

Server decides, client renders

Problem

When flow logic — which step comes next, what copy to show, which option to present — lives inside a shipped client binary or bundle, changing it requires an app-store submission or web deploy and staggered rollout. For a flow as critical and as device-fragmented as authentication, that feedback cycle is measured in weeks, which makes experimentation prohibitively slow and forces the client to anticipate and reproduce every case across many platforms.

Solution

Move the decision boundary off the client. The server decides what to present and in what order; the client is a thin renderer that knows how to display a fixed set of screen types and send actions back — with "no opinion about sequence, copy, or flow logic." The screen becomes the unit of abstraction: identifier input, challenge, account picker, and error recovery are each a screen fully defined by a server response.

This is server-driven UI applied to a flow-logic-heavy, correctness-critical surface. In Airbnb Flexible Authentication the load-bearing instance is that the client never decides which challenge to present — the policy engine does, and the client renders whatever challenge screen it receives.

To keep the thin client and rich server in sync, the server-side screen schema generates typed client definitions (Web, iOS, Android), so client/server mismatches surface at development time rather than at runtime.

Consequences

  • Strategy changes need no client release. Per-region and per-experiment tuning ships as server config/data. Airbnb ran 20+ experiments in three months, most with no client change; iteration collapsed from weeks to days.
  • Less client code. Removing sequencing and flow logic from the client (plus design-system and localization streamlining) drove a 60% code reduction and a 100 KB smaller web bundle — itself a win for slow connections and constrained devices.
  • Uniform behaviour across a fragmented fleet. One server-authored flow renders consistently across "nearly every client type," eliminating per-client bug reproduction.
  • Generalizable thesis. Airbnb frames it broadly: "for any flow where context determines the right experience, moving the decision boundary off the client unlocks the iteration speed needed to act on what you learn."

Relationship to SDUI-on-content

Prior on-wiki SDUI instances (Yelp CHAOS, Zalando Appcraft) apply server-driven rendering mostly to content screens. This pattern is the same substrate applied to flow / decision logic (which step, which auth method, which recovery path), where the payoff is experimentation velocity and availability rather than content freshness. It also depends on server-ranked fallbacks and identify-first-then-challenge to have decisions worth centralizing.

Caveats

  • The server-side screen-schema format and codegen toolchain are not disclosed in the source.
  • Centralizing flow logic concentrates correctness in the server: a bad server-authored flow can misroute all clients at once (mitigated at Airbnb by experimentation gating, though not detailed).

Seen in

Last updated · 623 distilled / 1,987 read