Server-Driven UI on the web: Examples, what is it and when to use it

A server-driven UI architecture determines which UI views need to be rendered on an application screen.

Most web applications today work this way: a client/server (frontend/backend) architecture. The backend sends data to the front end, and the front end decides where and how to present the data.

Well, the server-driven UI (SDUI) approach is similar, with one twist: the backend decides where and how to present the data. Or better say, the backend decides about the user interface.

We could call it "The Mirror" technique, where the server decides what and how to render, and the front reads this as a list of instructions. 

One of the benefits of this approach is that it enables new features to be deployed on all platforms simultaneously via a backend change without releasing new versions of the native apps.

Pretty clever, I need to admit. There are no molded templates anymore; instead, the server defines the list of components. There is a corresponding UI implementation in the app (UIComponent) for each component defined at the server.

Template creation, by default, implies a dependent relationship between the front-end programmer and the content creators. How?

To fill templates with content, creators must adapt their content to the template. They can't alter or customize the content without a programmer. The same applies to changes made to a page's design or content. When you add new sections or buttons to a website using the traditional method (i.e., the client-side approach), you must create new codes and add new CMS fields.

Rather than using templates, SDUI concentrates on separate components to solve these problems.

JSON! JSON! JSON!

So an emerging thing with SDUI is the fact that it uses layouts as JSON. Something that you can deliver over an API. So you build components, and the API can dictate who sees what information in what order. And believe it or not, this simple philosophy could actually solve very complex problems. 

Wanna know how this actually works? Let's go through some examples.

As you can see in this picture, this imaginary web page is made up of several "components." 

So from the top, we see the page type, a carousel, title, action row, and map row. And then a list of sections; each section consists of a list of components. Each component is rendered based solely on the data contained in JSON. 

The server does all the work of deciding which component to use and how to render. The app/client/front end doesn't decide anything.

The most important thing is that the server ultimately decides the order of these components and the content inside of them.

In these examples, I am actually describing component-based content modeling.

This technique divides content into recognizable ingredients, such as:

These examples show how SDUI works for the mobile application, but the same access is possible on the website. You can add, build or create dozens of different components and match them with specific needs. Isn't that cool? Of course, it is, but it's not all you can do.

This approach can bring in other advantages, such as:

Server-driven UI, or remote UI, is an approach where an application's user interface (UI) is generated and controlled by a server rather than hardcoded on the client side. This allows flexibility, scalability, and easy UI updates without downloading the latest app version.
Here are some examples of server-driven UI applications:

SDUI has proven itself not only as an emerging technique for developers but also for content and design creators. There is no doubt that component-based content modeling will significantly influence the industry in the future, so if you're considering switching to this approach, you should not forget its essentials.

Give your components descriptive names that are easy to search and use from the beginning. Content creators will be able to work more efficiently with components named logically.

Creating a new component for every instance of content is not necessary. Add a configuration option that allows you to customize the presentation. For example, add a call-to-action button and change the button's color.

There is a thin line between freedom and anarchy!

Even though SDUI allows more creative freedom, that doesn't mean that there are no ground rules. You can determine how a blog post should be built or which components to use depending on your needs. When large teams work from different locations, a style guide or brand book can help define the standards to adhere to.

The advantages of SDUI come into play when we want to make changes. Let's revisit the release cycle and see how SDUI can streamline it.

Using the SDUI mobile version of your website release cycle is way shorter than with traditional UI development processes. How is that even possible? Why does Apple or Google don't do reviews on the app changes which SDUI makes? 🤔

Well, the answer is more than obvious; there is no new code! 

There are no new codes, so there is no need to test them. There are no changes to the app, so there are no submissions for a brand-new version. Therefore, there is no need to wait for Apple or Google's approval. Due to the fact that the new app is not submitted, all updates are made server-side, so users see the changes immediately. 🤯

Taking the lead over your competitors is the key. Hence, if you don't want to change the design system, move a screen, or add a button, you can do so without deploying a new application. You can do so without waiting for users to download it. Then you have a faster time to market.

At least in most cases, companies do not depend on users having to update the app to see something new (a new interface) or simply a change in the organization of a screen.

SDUI has a cross-platform approach for content sharing and controller logic. In practice, a server-driven UI gives content managers more immediate control over their content. Integration of the server-driven UI and flexible headless CMS  leads to a fluid content experience. On the other hand, component-based content modeling allows sharing of many of the same functionality, product features, and content across multiple platforms.

You are being able to share the same content, features, etc. It is money-saving. Imagine you have a website, and you want to get a mobile application. Would you invest in a mobile engineering team or build up different platforms if they share many of the same functionality and product features? Ofcourse you won't. Using SDUI components and managing your content on a mobile app is way more time and money-saving.

Just like with a headless CMS, a server-driven UI gives content managers more immediate control over their content. With the CMS, content from different sources can be combined to match a customer's specific needs. To be successful, content today needs to be rich, relevant and adapted to the channel and touchpoint. The server-driven UI approach enables content managers and customers to have better experiences.

One of its most significant drawbacks is that data and user interface are combined in a single response when using SDUI. When viewing a listing screen, the user interface must be fetched. UI and data are displayed on a blank screen while the user waits for the server to load the UI and data. This is a step backward, unlike the traditional approach where the UI is embedded into the app and never needs to be loaded.

Synchronization between the server and the front is essential for Server Driven UI. Neither side can use an incompatible model. To avoid network failures and incorrect data, the front end must be prepared to deal with data failures and errors. As a result of SDUI, the backend will be responsible for much of the work. An internet connection is 100% necessary for the app to work. Because of that, development teams will be more intertwined than ever before.

Despite SDUI's effectiveness, it raises some cross-platform concerns. In what ways can a single platform move in a different direction? Is it necessary to write specific or universal commands? SDUI depends heavily on the specificity of the contract that you write. If your server only has properties that work across all platforms, you will miss out on the opportunity to take advantage of things that might be unique to iPhones or Androids, where you will need escape hatches and ways to drive it or insulate it. One of the biggest challenges is you build a feature for a specific platform and experiment with it. How do you extend that cross-platform?

Server-Driven UI (SDUI) and headless CMS are complementary technologies that provide flexible and efficient content delivery and user interface development.

When combined with SDUI and a headless CMS, the headless CMS serves as the content repository and management system. At the same time, the SDUI architecture handles the generation and delivery of UI components. The headless CMS delivers content through APIs, which the SDUI server consumes to generate UI components dynamically. The server can request and receive content from the CMS based on user interactions, device types, localization, or any other relevant data. The received content is then used to render the appropriate UI components sent to the client for display.

Combining SDUI and a headless CMS allows for the separation of concerns, where content management is handled by the CMS, and UI generation is managed by the SDUI server. It provides flexibility, scalability, and personalization capabilities, as content updates can be made independently of UI changes, and UI components can be tailored based on received content. Headless CMS enables efficient content management and delivery, while SDUI streamlines UI generation and updates.

Headless CMS supports Server-Driven UI by providing the necessary infrastructure and tools to manage and deliver content to the user interface. Here are some ways a headless CMS supports SDUI:

Headless CMS allows you to define content models representing your content's structure, fields, and relationships. You can create content types and specify the fields required for each type. This content modeling capability ensures that the CMS understands the data structure and can provide it to the UI in a structured format.

Headless CMS provides an intuitive interface for content creators and editors to create, edit, and manage content. Users can leverage the CMS's content editing features, including WYSIWYG editors, form-based inputs, media management, and collaboration tools. This simplifies managing content and allows non-technical users to update content without modifying the UI code.

Headless platforms often expose APIs that allow developers to fetch content programmatically. These APIs provide access to CMS content and enable the front-end application to retrieve content on demand. The APIs can be RESTful or GraphQL-based, allowing flexibility in fetching specific content items or performing complex queries.

CMS platforms often provide versioning and workflow management features. This allows teams to collaborate on content creation and review processes. Content can move through various stages, such as draft, review, and publish, with the ability to roll back to previous versions if needed. This ensures that the UI always displays the correct and approved content.

When a request is made to fetch content from the CMS, it dynamically generates and delivers the requested content in a structured format. The headless CMS retrieves the relevant data based on the requested content types. It applies any filtering or sorting criteria and formats the response for consumption by the front-end application.

CMS supports localization by allowing content variants in different languages. It enables content translation and management of localized versions. This ensures the UI displays the appropriate content based on the user's language preferences. Additionally, CMS platforms may provide personalization features that allow you to tailor content based on user attributes, device type, or other relevant factors.

CMS platforms often offer webhooks or real-time notification mechanisms. These allow you to subscribe to events or changes in the content, triggering notifications or callbacks to update the UI. This enables real-time updates and ensures that the UI reflects the latest content changes in the CMS.

To use a headless CMS with Server-Driven UI (SDUI), you must follow these steps to integrate and leverage these technologies effectively. Here's a general overview of how to use a headless CMS and SDUI:

It should be clear that SDUI is not a magical solution for mobile app development or an ultimate way to deliver perfect UI experiences. It may be best to go with a server-driven approach in more marketing-driven areas, or on landing pages, rather than complex parts of the website.

The advantage of this approach is that you can change your app's screens or make changes without sending a new release to your users. Nevertheless, don't forget that server-driven user interfaces are still a "new thing" that has not been thoroughly researched. There are elements you need to consider, like where is the best time to load the information about your pages, how you create cache for them, and how you structure special screens that are very "unique."