Skip to content

CONCEPT Cited by 1 source

Server-owned schema versioning

Definition

Server-owned schema versioning is the discipline of keeping all component-version negotiation logic on the server in a server-driven UI system, so that:

  • The client reports only its app version + platform.
  • The server decides, per-component-per-request, which version of that component to emit (or to skip entirely).
  • The client renders whatever the server sends, with no local version-to-version reconciliation logic.

The contrast is a two-sided versioning protocol where both server and client carry schema-version state and must agree; this forces coordinated deploys whenever either side evolves.

Appcraft's stance

Appcraft moved from TNA's two-sided versioning to fully server-owned versioning as part of its 2018 redesign (Source: sources/2024-05-15-zalando-transitioning-to-appcraft-evolution-of-zalandos-server-driven-ui-framework):

"With the previous TNA system, both server and clients had to exchange information about the schema version, adding complexity. We sought alternatives to reduce errors and simplify maintenance. With a more flexible layout structure and by keeping the logic of binding data and layout in the server, we achieved reduced complexity in the clients by leaving the sole responsibility of rendering to the app. The schema versioning remained on the server."

What server ownership enables (verbatim from the post)

  1. Per-app-version / per-platform / per-premise / per-A/B gating — "Enable or disable components and their behaviour targeting specific app versions, platforms, premises and A/B testing."
  2. Hotfix-free incident remediation — "Resolve incidents quicker without the need of a hotfix by removing for example faulty components for specific app versions or OS due to bugs or performance reasons from the server."
  3. Retain backward-compat via min-app-version per component — "Retain backward compatibility logic on the server, as we can specify a minimum version for a component."
  4. New pages without a client change — "Adding new appcraft pages in the App without the need of client changes, by just configuring the new page route and the minimum app version supported."

These four capabilities are all server-side levers; the client is strictly a renderer.

What still requires a client release

  • A new primitive (Label, Button, …) — see concepts/client-release-needed-only-for-new-primitives.
  • Extending an existing primitive's contract — adding a new prop or event type the client needs to handle.
  • A new action type (e.g. a brand-new navigate-to-AR- view action).

Everything else — new screens, new compositions, new variants, new A/B cohorts — ships on the server.

Contrast with client-reported spec versioning

A related but different pattern is client-reported spec version, as in Yelp CHAOS via Konbini: the client reports its bundled component-version-set; the server skips components the client can't render; for components that changed contract, the server emits migrate(V1) → V0 functions to downgrade. The shape is:

  • CHAOS/Konbini: client tells server "I speak android@23.0", server tailors response.
  • Appcraft: server tells client "this is the screen", server has already decided — based on app version — which components to include.

Both are server-owned version logic in the sense that the decisions live on the server. Appcraft's variant is slimmer: the client doesn't ship a spec file at all, it just ships its app version.

Trade-offs

Pros:

  • Only one place to change schema logic (the server).
  • Incident remediation is a server deploy, not an App-Store release.
  • No client-side version-reconciliation bugs.

Cons:

  • Server has to track every app version in the wild and emit compatible JSON for each one.
  • An old client can still render a component incorrectly if the server's per-version decision is wrong — client has no fallback logic of its own.
  • No client-side renderability check; the server's capability-estimate is authoritative.

Seen in

Last updated · 550 distilled / 1,221 read