🚀 SDUI is an approach where the server gives the client an interface description (usually JSON), and the client renders it. Change the UI — change the data, not the application build. Fewer releases, more flexibility. ✨
📦 Definition: what is the essence of SDUI
Server-Driven UI - this is when the server manages the structure and behavior of the UI: sends the screen layout to the client (components, their properties, actions). The client knows how to draw basic blocks and associate them with events, but layout logic and variability live on the server.
{
"screen": {
"title": "Product of the day",
"blocks": [
{ "type": "image", "src": "https://cdn.example.com/promo.png", "ratio": "1:1", "alt": "Promo" },
{ "type": "text", "style": "h2", "value": "Discount -30%" },
{ "type": "button", "style": "primary", "text": "Buy", "action": { "type": "POST", "url": "/buy?id=42" } }
]
}
}The client did not have to change the code to draw a new screen — he only drew the sent scheme.

🔍 How it works step by step
The client requests the screen configuration from the server.
The server returns JSON/DSL with UI schema and actions.
The client renders the UI from the schema and signs the events.
Business logic (A/B, features, display conditions) — on the server.
This is especially convenient for mobile applications where releases are moderated.
💡 How SDUI is useful for a frontender
Fewer releases: we edit the UI on the server — the client picks up the changes immediately.
Unified experience across platforms: web and mobile clients render one scheme.
Quick experiments: A/B tests and feature flags — without recompiling the client.
Content- and config-centric approach: the design system can be "pulled up" through the scheme.
Experiment without release: the product team changes the text of the "Buy" button → "Add to cart" in the server response and looks at the conversion on the same day.
📌 Realistic API example
The server can give not only a list of blocks, but also terms, data bindings and events:
{
"screen": {
"title": "Catalog",
"blocks": [
{ "type": "search", "placeholder": "Find product..." },
{ "type": "list", "items": "{{products}}",
"item": {
"type": "card",
"image": "{{item.image}}",
"title": "{{item.title}}",
"price": "{{item.price}}",
"cta": { "type": "button", "text": "Add", "action": { "type": "POST", "url": "/cart/add", "body": {"id": "{{item.id}}"} } }
}
}
],
"data": { "products": "/api/products?query={{query}}" },
"experiments": { "cta_text": ["Buy", "Add", "Add to cart"] }
}
}Templates {{placeholders}} are substituted by the client from the data requested by the links.
✅ Pros
Reduced time-to-market for UI changes.
Centralization of display rules and interface variations.
Unified design system through component abstractions.
⚠️ Cons
Debugging is more difficult: bugs are possible both in the scheme and in the client.
Requires discipline of versioning the scheme.
Restrictions on "rich" interactions on the client.
🔧 Where SDUI is especially appropriate
Mobile applications with long release moderation.
Projects with frequent promotions/redesigns and A/B tests.
Cross-platform products (Web + iOS + Android).
🧭 Conclusion
Server-Driven UI accelerates product experiments and reduces the number of client releases. It works well where the UI changes frequently and you need to quickly roll out variations without repackaging applications. At the same time, it is important to think about the versioning of the schemes and the boundaries of responsibility between the client and the server.
📚 Do you want to delve into the topic?
In the attachment Code you will find detailed lessons on various topics, step-by-step exercises, error analysis and convenient practice right on your phone or browser.
And if you want to be aware of the news, new features and useful materials - subscribe to our Telegram channel. It's cozy, businesslike and with love for code ❤️
