Backend-driven UI: Fast A/B testing and unified clients
Adomas Liutkus
September 18, 2024
Table of contents
Backend-driven UI is a fresh approach to user interface development that hasn’t gotten much attention in UI design circles. The reasons for that include high upfront costs and the dominance of frontend-driven setups. However, there’s much more to the story.
As a Senior Frontend Engineer at NordLayer, I recently dove into BDUI to see what makes it stand out. In this article, I’ll break down where UI development is now and how adding more server-side power could improve the usual frontend-focused methods.
Frontend-only UI development
Imagine a simple UI feature, like the banner at the top of a page. How does our team create this banner? Let’s take a look at the 6-step development lifecycle for a single feature.
A basic development cycle for a UI feature.
Development starts with requirement gathering, 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 the banner, and as it’s a frontend-only feature, we may skip backend development and go straight into frontend development, then testing. After that, there’s only one step left – deployment. That’s it – the job’s done…
… or is it?
Emphasizing the backend’s role
Let’s say this whole process takes a week, depending on your setup. But features don’t simply stay the same indefinitely – we iterate upon them.
For example, we’d like to show a different message for the second iteration. However, realizing that the message will change a lot, we’d 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’s ready to go.
Let’s 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.
The goal of backend-driven UI
Simply stated, backend-driven UI aims to make user interfaces a function of state.
Spotify expressed BDUI as UI = fn(state) in one of its early talks on the subject. This distills the idea beautifully. What we’re 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. Each object represents a component on the frontend client.
A mobile UI defined by JSON components.
The benefits of backend-driven UI
Redesigning our interface becomes streamlined: This can be achieved by simply changing the order of our objects. We can also add components without any frontend redeployment.
Backend-driven UI allows us to unify our client approach because this state can be used to populate any client, whether it’s mobile, desktop, or otherwise. This way, users get new features at the same time, regardless of what client they’re using. In terms of development, this helps developers across various teams follow a similar workflow.
Easier A/B testing. All we need to focus on is how to deliver different states based on user feedback, and with that, we can get really flexible when conceptualizing and experimenting with new UIs.
The cons of backend-driven UI
Uneven developer distribution
As mentioned before, every useful software development approach will have downsides. Implementing backend-driven UI means migrating all logic from the frontend. Naturally, this will result in higher workloads for backend developers. Keeping that in mind, does the usual developer distribution change when using this approach? Generally, yes, but this ultimately depends on the product/app/service you’re building. Some are already more backend-heavy than others.
Workload will vary depending on the stage of implementation. When starting with backend-driven UI, designing the architecture, agreeing on the contract, and executing the switch is heavily dependent on all engineers. Questions mostly arise when the migration is complete. From then on, backenders will have bigger workloads.
High cost
The upfront cost of introducing backend-driven UI can be significant. When making a UI reliant only on the state provided to it, the implementation can quickly become overcomplicated. This impacts the pace of development. It’s not an easy task, but we’re trading high upfront costs for being faster and more flexible in the future.
You should first consider whether this approach is even useful for your specific business. Spotify popularized this approach because it wanted the ability to experiment fast and flexibly with novel UI features. But if you’re building an admin panel, does it need to be backend-driven? Will the interface change a lot, or will you be conducting A/B tests for the users? Implementing BDUI should align with your tech setup and business goals.
Sanity check: Is BDUI for you?
With the pros and cons in mind, let’s address some common questions:
How much should you commit initially?
Backend-driven UI doesn’t need to replace the entire system. You can also take a modular approach when determining viability. As an example, you can identify specific parts of the application that you could make backend-driven. The banner example that we discussed above could be something to start with. If that works, try it out on a more challenging feature like a table or carousel.
Are we inventing HTML again?
Avoid being too detailed. Taking a simple feature like a text box, we could go overboard and start thinking about allowing different text colors, size changes, or other modifications… But then we’d come dangerously close to CSS and HTML, which is certainly not the goal! Remember: Enable backend-driven UI using general components, not detailed blocks.
Do we have the foundation to implement a backend-driven UI?
Do you have a design system? As we said above, being too detailed will cause problems. With a design system in place, we have a very clear direction on where to go. Development becomes very logical as long as our frontend can handle our designed components. Everyone uses the same components to describe UIs: Whether you’re a mobile developer, frontender, or designer, we all speak the same language. A button means the same component across different contexts.
Big Tech and backend-driven UI
Most of this article's content is based on findings from Lyft, Spotify, Airbnb, and others. These are huge companies with the resources to make backend-driven UI a reality.
And even though BDUI can be a pricy upfront investment that requires developer redistribution, its long-term benefits – including flexibility and faster adaptation to user feedback – are a huge upside for many teams, products, and apps.