{"id":90811,"date":"2024-09-30T12:23:06","date_gmt":"2024-09-30T04:23:06","guid":{"rendered":"https:\/\/version-2.com\/?p=90811"},"modified":"2024-09-19T12:25:43","modified_gmt":"2024-09-19T04:25:43","slug":"backend-driven-ui-fast-a-b-testing-and-unified-clients","status":"publish","type":"post","link":"https:\/\/version-2.com\/en\/2024\/09\/backend-driven-ui-fast-a-b-testing-and-unified-clients\/","title":{"rendered":"Backend-driven UI: Fast A\/B testing and unified clients"},"content":{"rendered":"
\n\t\t\t\t\t\t
\n\t\t\t\t\t\t
\n\t\t\t\t\t
\n\t\t\t
\n\t\t\t\t\t\t
\n\t\t\t\t
\n\t\t\t\t\t\t\t\t\t
Backend-driven UI is a fresh approach to user interface development that hasn\u2019t gotten much attention in UI design circles. The reasons for that include high upfront costs and the dominance of frontend-driven setups. However, there\u2019s much more to the story.<\/div><\/div><\/div>

<\/p>

As a Senior Frontend Engineer at NordLayer<\/u><\/a>, I recently dove into BDUI to see what makes it stand out. In this article, I\u2019ll break down where UI development is now and how adding more server-side power could improve the usual frontend-focused methods.<\/p>

Frontend-only UI development<\/b><\/h2>

Imagine a simple UI feature, like the banner at the top of a page. How does our team create this banner? Let\u2019s take a look at the 6-step development lifecycle for a single feature.\u00a0

<\/p>

A basic development cycle for a UI feature.<\/p><\/div>

Development starts with requirement gathering<\/b>, where the product owner (PO) outlines the desired functionality of the UI element. In this case, we want it to display a static message. So we design<\/b> the banner, and as it\u2019s a frontend-only feature, we may skip backend development<\/b> and go straight into frontend development<\/b>, then testing<\/b>. After that, there\u2019s only one step left \u2013 deployment<\/b>. That\u2019s it \u2013 the job\u2019s done\u2026<\/p>

\u2026 or is it?<\/p>

Emphasizing the backend\u2019s role<\/b><\/h2>

Let\u2019s say this whole process takes a week, depending on your setup. But features don\u2019t simply stay the same indefinitely \u2013 we iterate upon them.<\/p>

For example, we\u2019d like to show a different message for the second iteration. However, realizing that the message will change a lot, we\u2019d move its management to the backend. To ensure a smooth integration between departments, the backend engineers build an API and provide it to the frontend team. After testing and deployment, everything\u2019s ready to go.<\/p>

Let\u2019s iterate further. Now we want to deliver tailored messages to different user segments, as part of an A\/B testing strategy. The beautiful part? No more frontend changes required! The frontend’s role now is simply to call the backend to retrieve the display message. Our UI approach is now effectively ‘backend-driven,’ enabling faster iterations and more flexible content management and delivery.<\/p>

The goal of backend-driven UI<\/b><\/h2>

Simply stated, backend-driven UI aims to make user interfaces a function of state.<\/b><\/p>

Spotify expressed BDUI as UI = fn(state) <\/b>in one of its early talks on the subject. This distills the idea beautifully. What we\u2019re trying to achieve here is making the interface depend entirely on the state provided to it. Imagine a webpage structured using JSON data objects, which in our case, become the state<\/b>. Each object represents a component on the frontend client.\u00a0

<\/p>

A mobile UI defined by JSON components.<\/p><\/div>

The benefits of backend-driven UI<\/b><\/h2>