Why Server-Driven UI Is Key to the Longevity of Web Software Architecture Platforms
Get more done through less copy and pasting — and more experimentation
Is the architecture platform you’re working in held together by duct tape? When you pick up a task, do you spend more time figuring out where to make the change and how it all works? Have you picked up a task thinking it’s a simple change, but it took weeks?
Yeah, I have!
Web software is becoming more complex. The larger it gets, the more complexities arise. The good old days of building a straightforward server-side rendered (SSR) website are fading away. Whilst at Expedia Group for almost five years, I worked on building new pages to help migrate off the monolith system. The move was towards a microservices-based platform. Now, over at Atlassian, I am doing the same. Many big companies have shifted away from those large SSR monoliths and begun dividing them into two major domains: frontend and backend.
The frontend would use a declarative programming library such as React, Angular, or Vue. Component libraries are created from these for reuse and consistency.
The backend would follow a microservices-based architecture which contains a bunch of domain-level services. These services would then fall under some gateway that will handle authorisation and coordination.
This separation of concerns has enabled us to build better-looking websites because talent is now specialised to a domain. Yet, complexity from end-to-end is higher. Bugs are now harder to find, testing is more involved, and logging output is also getting higher. Overall, the cost is significant.
Making major changes to an existing domain is expensive, and building a new one from the ground up is unjustifiable. The issue I commonly see is in new or changed data models supplied to the front end.
Work often consists of refactoring or adding the same but different components into the UI. The infamous copypasta. This can be the addition of new fields, component items, etc. There are times when business logic is defined within the frontend codebase. This then needs updating due to backend response changes. You spend more time fixing or adding repetitive boilerplate code and less time on actual business value and problems.
This problem raises an opportunity. To fix the communication between the backend response and the frontend application.
Airbnb was one of the early pioneers to seize this opportunity and announced it publicly in an article introducing their Ghost Platform. Their solution was to follow a Server-Driven UI (SDUI) paradigm.
So, what is SDUI?
Server-driven UI (user interface) is an approach to building user interfaces where the UI elements are formed and controlled from the server-side rather than on the client-side. In this approach, the server shapes the UI and provides the client blueprints for interpretation.
For example, we are familiar with seeing a data response that would look like this:
{
"data": [
{
"name": "Bob",
"email": "[email protected]",
"phone": "1111111111"
}
]
}
In SDUI, it looks like this:
{
"data": [
{
"type": "paragraph",
"text": "Employee name: Bob"
},
{
"type": "paragraph",
"text": "Employee email: [email protected]"
},
{
"type": "paragraph",
"text": "Employee phone: 1111111111"
}
]
}
In the above examples, rather than supplying a bunch of data for the frontend to coordinate and handle, the server can provide a UI schema. No longer will the UI need to massage the data into a UI component, rather it can read and display.
This provides us with many benefits.
- Business logic must live on the server
- Experiments and features get controlled from the backend
- No more copy-pasting UI code around for similar views
- Mobile applications can have UI updates without requiring you to release a new app version
- New views can get created using preexisting components
In SDUI, the UI becomes dumb, and so it should be. The separation of concerns (SOC) also becomes clearer. When a bug occurs, distinguishing whether the issues sit in the backend or the frontend, it’s clear. For any issues that relate to data, missing components, missing information, or wrong order of components, it’s in the backend. Anything visually related, like spacing, styles, rendering, etc.; it’s the frontend. As long as the UI schema contract is followed, the SOC is clear.
The problem with scaling that I’ve seen is that both the backend and the frontend scale as large as each other. For example, when a new landing page gets created. The backend will need to create a new service to supply data. The frontend will also need to create a new service or a new page. The backend and the frontend will start creating new work. Imagine this in a large company with many teams. The amount of code that gets created grows quite large quickly.
In a mature SDUI platform, the case would be different. The backend will have a new service, and the frontend would only need to handle the routing and connectivity to it. This would make the frontend a plug-and-play model.
The goal is that the backend should leverage all of the existing component schemas to build the new view component or page. The frontend will only update if a new design component gets introduced. The worry of unmanageable scaling on the frontend is completely removed. Concerns are now only focused on the backend.
Since SDUI provides a solution for the frontend, it doesn’t require a complete rewrite of an existing platform. Existing domain services within the backend can remain as is. SDUI would act as the backend for the frontend (BFF). The SDUI BFF will stitch the domain service response and provide the UI schema to the frontend. The process can be done in stages as a migration towards a long-term scalable future.
When SDUI is done right, it’s an amazing superpower. Product teams are now able to deliver their ideas a lot faster. Researchers are able to create many different types of experimentation to yield the best results. UI engineers can focus on real problems and not feel like they are copying and pasting components around the place. Backend developers have a better understanding of their craft with visual results. Artificial intelligence (AI) won’t be slapped in but rather form a direct relationship with composing the results.
To me, this is a perfect world.
If you’re interested in reading more about SDUI, I have a documentation guide outlining all you need to know to get started with building your own SDUI platform.