Frame 951.png

Hi everyone! I’m Stas, a tech lead at Mish Product Lab. This topic didn’t come out of nowhere, we’ve had plenty of debates inside the team about which proxy and SSL termination tool performs best in different scenarios. At first, our assumptions were based mostly on personal preference rather than data. After a few rounds of arguing (and hoping our favorite tools would win), we realized there was only one way to get an objective answer: run the tests ourselves.

Proxying Out of the Box: A Comparative Analysis of HAProxy, Envoy, Nginx, Caddy, and Traefik

Дубич Станислав

mish_server.png

Hello, my name is Andrey Goncharov, and I’m a Frontend Developer at Mish Product Lab. Today we’ll take a close look at what Server/Backend-Driven UI is, how it works, and why it matters.

<h3>What Is a Backend-Driven UI?</h3>

 Backend-Driven UI (also called Server-Driven UI) is an approach to building applications where the
 backend controls not only the data but also how the interface looks. For example, in a frontend
 app, BDUI defines the layout.


 There are different levels of how deeply this concept can be integrated into a frontend
 application. Think of it as a spectrum.

<img src="/uploads/1644796358_69c744440a.png" alt="enter image description here" />
Yes, it feels like everyone has written an article about this topic already.

<h3>Our Cases</h3>
The easiest way to understand this concept is through real examples.
Case #1: Checkout Page

 A checkout usually goes through several steps: delivery method, payment method, contact details,
 and payment itself. Businesses have different requirements, so the steps vary. Essentially, these
 steps are formed with input fields. On the frontend side, we need to render the forms, handle
 navigation between steps, and send data back. The backend handles the rest of the logic.

A vivid example: CS-Cart
<img src="/uploads/1644796359_09b35c4805.png" alt="enter image description here" />
This is roughly how checkout steps are organized in online stores.

Case #2: Blog Post

 Blog posts are usually created in an admin panel with a WYSIWYG editor. Modern editors allow
 multiple columns, custom components, SEO settings, tags, and more. The backend stores the entries,
 manages access, and provides structure. The frontend renders the content based on that structure.

A good example: Strapi.
Case #3: UI Updates Without Releasing a New App

 Imagine you’re a bank hit by sanctions: your app is removed from app stores, and you can’t ship
 updates. But you still have an option — the entire interface comes from the server as JSON!

A strong example — <a href="https://habr.com/ru/company/yandex/blog/683886/">DivKit.</a>

<h3>Why Use This Approach?</h3>
Because it allows you to:
<ul>
 <li>Change the layout of a frontend app significantly (Case #3).</li>
 <li>Restructure an existing screen (Case #3).</li>
 <li>
 Run A/B tests easily (Case #1 and #3). Normally, this requires coding, deploying new bundles,
 and lots of manual work.
 </li>
 <li>Quickly add promotional content from the marketing team.</li>
 <li>Create new content pages on the fly.</li>
</ul>

<h3>What Happens If You Don’t Use BDUI?</h3>
Different roles in the team face different problems.
<ul>
 <li>
 Project managers: 
 need to consider the complexity of changing page structures. What if the team lead is
 inexperienced and can’t guide them well?
 </li>
 <li>
 Testers: 
 global changes to a hardcoded structure usually trigger full regression testing, which can delay
 the release by days.
 </li>
 <li>Developers:</li>
 <ol>
 <li>Must hardcode layout changes in code.</li>
 <li>Have to integrate external data sources for new blocks.</li>
 <li>Need to remove unused sources when blocks are deleted.</li>
 <li>Must adapt layouts when blocks are added or removed.</li>
 </ol>
</ul>

<h3>A Timeline Problem: Negative Case</h3>

 Imagine building a small hostel booking service. You have designs, contracts, and deadlines. Right
 before the release, the client asks to swap a promo block with a “bed selector” component.

It looks simple: just switch two blocks. But technical issues can appear:
<ul>
 <li>The page may have been hardcoded with fixed sizes and margins.</li>
 <li>Data sources may require a specific request order.</li>
 <li>The code may be messy, and the only developer who fully understands it is on vacation.</li>
</ul>

 Another hidden issue: a hardcoded UI has no “contract” for structure or data. You only know what
 to expect after reading the code.

What about adding a new page with text content?
<ul>
 <li>
 You need to dive into the code and copy a typical page with its layout, essentially copy-pasting
 boilerplate code.
 </li>
 <li>
 You might need to register the page in the application router and put it behind authentication.
 </li>
 <li>You need to hook up the data source.</li>
</ul>
This makes it very hard to:
<ul>
 <li>Run A/B tests.</li>
 <li>Add content without developer involvement.</li>
</ul>
In other words, the frontend becomes a rigid program, disconnected from any external scheme.

 At its core, Backend-Driven UI is about receiving a screen schema from the backend, processing it,
 and rendering the layout. Sometimes it includes the entire site map.


<h3>Building a Good BDUI</h3>
What do we need to make Backend-Driven UI convenient?
<ul>
 <li>
 A backend contract.
 The format of the screen layout must be clear.
 </li>
 <li>
 Initial component state 
 If needed, it should be encapsulated properly.
 </li>
 <li>
 Layout description level
 Block nesting, vertical/horizontal placement, block sizes.
 </li>
 <li>
 Page parameters
 For example, page number or filters
 </li>
</ul>

<h3>How to Implement It</h3>

 The best way is to put the layout generation logic into a separate microservice, that is a Backend
 for Frontend (BFF). Don’t bury polymorphic layout logic inside your main backend.


<h3>Who uses BDUI in the industry and how?</h3>
Example #1: BigTech, Ozon
Ozon’s mobile app uses BDUI for:
<ul>
 <li>A/B testing</li>
 <li>Extract business logic from Web/Android/iOS apps</li>
 <li>Delivering changes faster to users</li>
</ul>

 Here's a great article where they explain how they prepared the logic for interface formation:
 <a href="https://habr.com/ru/company/ozontech/blog/661941/">
 How Backend-Driven UI Works on Mobile Client
 </a>


<img src="/uploads/1644796391_10708cecac.png" alt="enter image description here" />

 Screenshot of the application with widget explanations on the page, screenshot from the Ozon
 article.

Example #2: BigTech, Alfa-Bank

 A good article on Habr where Alfa-Bank engineers share their experience: Evolution of
 Server-Driven UI:
 <a href="https://habr.com/ru/company/alfa/blog/668754/">
 dynamic fields, handlers and multi-step flows
 </a>


 I should note that they discuss not so much the layout aspects, but rather everything else: event
 handling, business logic in complex forms.

<img src="/uploads/1644796364_56d3f6c927.png" alt="enter image description here" />
Screenshot from an article with an example of event handling.
Example #3: BigTech, Airbnb

 The booking service Airbnb, no longer operating in Russia, also built its mobile app on the BDUI
 concept. They use it mainly for A/B testing. Here’s a code-rich article with their approac
 <a
 href="https://medium.com/airbnb-engineering/a-deep-dive-into-airbnbs-server-driven-ui-system-842244c5f5"
 >
 A Deep Dive into Airbnb’s Server-Driven UI System
 </a>

<img src="/uploads/1644796365_14325dbba4.png" alt="enter image description here" />
This is how Airbnb transforms data into a user interface (screenshot from their article).
Example #4: No-Code, Unflow

 The popular no-code trend often makes its way into client applications through BDUI. For instance,
 <a href="https://github.com/unflowhq">Unflow</a> allows customization freedom and provides SDKs
 for mobile platforms.

<img src="/uploads/1644796390_d19c4778ca.png" alt="enter image description here" />
Here’s what the screen editor in Unflow looks like.
Example #5: No-Code, Strapi

 An interesting implementation is Strapi, a headless CMS. It provides an interface for editing
 content but doesn’t generate the site or the final display. For example, you can create a “page
 layout” entity and add blocks to it. However, this approach is inconvenient and doesn’t allow
 seamless integration with other data sources.

<img src="/uploads/1644796387_5342ec13ae.png" alt="enter image description here" />
Strapi Admin Panel
Example #6: Implementing the Concept in CS-Cart CMS

 Another implementation is the so-called Block Manager. Essentially, it’s a simplified visual page
 layout editor. It lets you build or rebuild a page without writing any code at all. The
 block/widget settings are a whole universe of their own.

<img src="/uploads/1644796360_9f4491f533.png" alt="enter image description here" />
Page Layout Editor

<h3>Conclusions</h3>

 Backend/Server-Driven UI is still a niche concept. Building a full interface with this approach is
 expensive, but it works well for two cases:

<ul>
 <li>
 Large enterprises 
 need to test hypotheses, deliver features and fixes quickly, avoid drowning in duplicated logic
 across multiple client applications.
 </li>
 <li>
 Small businesses 
 don’t have the resources to build custom solutions. Instead, they use no-code platforms — which
 are often based on BDUI — assemble screens, connect an open-source client to their instance on
 the platform, and everything just works.
 </li>
</ul>

 Used wisely, BDUI is powerful. Applying it to the right parts of a system (like complex forms) is
 the right choice. The more business logic you keep on the server and the less on the client, the
 more stable your app will be.

Backend

hello@mish.design

Moscow

Nizhny Novgorod