How Server-Driven UI works and why it simplifies the life of the frontender

Frontend teams often drown in endless "small releases": change the order of blocks, the text on the banner, launch a promotion — and again assembly, tests, rollout to all platforms. On mobile, store moderation is added, on the web — the risk of breaking what worked yesterday. As a result, the product speed drops, and the front-end developer turns into a "manual editor".

Server-Driven UI (SDUI) changes the rules: the server gives not only data, but also interface description — which components to render, in what order and with what parameters. The client becomes a stable rendering engine that understands the contract and assembles the screen from ready-made bricks. The result is that edits and experiments arrive to users immediately, without updating the application and unnecessary nightly deployments.

Why is this necessary? 🤔

• Edits without release: texts, block order, banners — everything changes on the server, the user sees it immediately.

• A/B tests and feature flags: different configurations for segments without updating clients.

• Single contract for iOS/Android/Web: fewer discrepancies between platforms.

• Quick campaigns: The "New Year's screen" is rolled out as a config, not as a new build.

What the SDUI scheme looks like

The server returns the structure: layout (hierarchy), a list of components with type and props, actions and meta-information (version, TTL, flags).

{
  "version": "1.3",
  "page": "product",
  "layout": {
    "type": "Scroll",
    "children": [
      { "type": "Title", "props": { "text": "Best offer of the day" } },
      { "type": "Image", "props": { "src": "https://cdn/app/promo.jpg", "ratio": 1.6 } },
      {
        "type": "Card",
        "props": {
          "title": "Pro Headphones",
          "price": "7 990 ₽",
          "cta": { "type": "Action", "name": "buy", "params": { "id": "hp-2025" } }
        }
      }
    ]
  },
  "tracking": [{ "event": "view_product", "params": { "id": "hp-2025" } }]
}

The client matches "type" → local component: Title → <Title/>, Card → <ProductCard/>, etc.

How is this performed on the client?

1. We get the scheme (with cache and versioning).

2. Validate (JSON Schema/Protobuf) and make graceful-fallback in case of errors.

3. We map type to local components through the registry.

4. Render and connect action handlers (navigation, API, tracking).

// TypeScript pseudocode
const registry = {
  Title: (p) => <Title {...p} />,
  Image: (p) => <Image {...p} />,
  Card:  (p) => <ProductCard {...p} />,
};

function renderNode(node) {
  const Component = registry[node.type] ?? Fallback;
  const children = (node.children || []).map(renderNode);
  return <Component {...(node.props||{})}>{children}</Component>;
}

Where SDUI is especially relevant 🎯

Pros and cons

• Advantages: edits without client deployment, fast A/B tests, consistency between platforms, personalization.

• Cons: discipline of the contract and versions, costs of the registry/validators/followbacks, less "visual freedom" (solved by design tokens).

Common mistakes and how to avoid them

• Without versioning: add version, support multiple generations of schemes.

• Giant "universal" components: keep blocks of medium granularity (Card, Banner, List).

• No validation: JSON Schema/Proto + required fields and defaults.

• Ignore cache: ETag/Last-Modified, TTL, stale-while-revalidate.

• No analytics: describe events in the diagram and process them centrally.

When SDUI is not needed

• Super-creative motion screens and dense custom animations.

• One-time promo landing pages are easier with static/SSR.

• Teams where "pixel-perfect at any cost" is more important than scale.

Mini-example of a scheme for an A/B campaign

{
  "version": "2.0",
  "experiment": "hero_ab",
  "variant": "B",
  "layout": {
    "type": "Scroll",
    "children": [
      { "type": "Banner", "props": { "style": "bright", "text": "-20% today" } },
      { "type": "Grid", "props": { "cols": 2 }, "children": [
        { "type": "Card", "props": { "title": "Product A", "price": "1 990 ₽" } },
        { "type": "Card", "props": { "title": "Product B", "price": "2 190 ₽" } }
      ] }
    ]
  }
}

Conclusion 💡

SDUI turns the frontend into stable renderer, and the product - in quick screen designer. This saves weeks of minor releases, speeds up experiments, and aligns UX across all platforms. If you frequently change your content or launch campaigns, SDUI pays for itself quickly.

In Codice we make programming training fun and easy to understand: we have interesting courses with tasks that help you improve your skills step by step.

And we also have an active Telegram channel, where we discuss cool ideas, share experiences and analyze tasks together — learning becomes not only useful, but also fun.

Have you tried SDUI? Where did it work, and where did it get in the way — and why?