Server-Driven UI on the Web: Examples, Benefits & Use Cases

Server-Driven UI
By Arso Stojović
Read time 10 min
Posted on 29 Oct 2022
Updated on 9 Aug 2023

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.

How Server-Driver UI works?

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.

Why Server-driven UI uses components instead of templates?

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.

How to build new components with SDUI

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.

Example 1:

SDUI components

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.

Example 2:

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

This technique divides content into recognizable ingredients, such as:

  • text block

  • image gallery

  • quote 

  • call-to-action

  • FAQ 

  • video

component-based content modeling.

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:

  • A/B testing - Over an API, you can perform AB tests and change the layout, text, and images in a server-driven and performant manner.

  • Building new pages - The process that applies to testing can also be applied to creating new pages. This dramatically speeds up the programming process. For example, programmatic SEO can be more beneficial when used together with SDUI for your landing pages.

  • Personalization -Being able to add, build or create dozen different components and match them with specific needs, is that like a core of the personalization process?

Server-driven UI examples

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:

  1. Content management systems: CMS platforms use a server-driven UI to provide a user-friendly interface for managing website content. Users can create, edit, and publish content without modifying the underlying code.

  2. E-commerce platforms: Online shopping platforms often use server-driven UI to display product listings, manage shopping carts, and process transactions. The server generates the UI components based on the user's actions and updates them in real-time.

  3. Social media apps: Platforms like Facebook and Twitter employ server-driven UI to display user profiles, news feeds, and personalized content. The server dynamically generates the UI based on the user's preferences and social connections.

  4. Collaboration tools: In real-time, applications like Google Docs or Trello use server-driven UI to allow multiple users to collaborate on documents or projects. The UI is updated dynamically as users change or interact with shared content.

  5. Data visualization dashboards: Tools like Tableau or Power BI leverage a server-driven UI to create interactive dashboards that display data visualizations and analytics. The UI is generated based on selected data sources and user interactions.

Server-driven UI essentials

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.

Naming your components

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.

Don't forget about configurations

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.

Don't run away from structured content

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.

Advantages of the Server-driven user interface

Faster time to market

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.

SDUI RELEASE CYCLE

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. 🤯

SDUI updates

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.

There are no app updates

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.

Server-driven UI is focused on a cross-platform approach

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.

Server-driven UI is cost-effective

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.

Autonomy over the content

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.

Disadvantages of the server-driven UI

Two-side rendering

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.

The offline mode makes your app useless

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.

Being universal can elevate some cross-platform concerns

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 and headless CMS

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.

How headless CMS supports server-driven UI

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:

Content modeling

Content modeling

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.

Content creation and management

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.

Content APIs

Content APIs

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.

Content versioning and workflow

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.

Content delivery

Content delivery

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.

Localization and personalization

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.

Webhooks and real-time updates

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.

How to use headless CMS and SDUI

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:

  • Define Content models - Set up content models in your headless CMS. This involves creating content types, defining fields, and establishing relationships between content items. Consider your content structure, metadata requirements, and application needs.

  • Configure Content API -  Configure the headless CMS to expose content through APIs. Most headless CMS platforms provide RESTful or GraphQL APIs for content delivery. Choose the appropriate API type based on your needs and preferences.

  • Develop the front-end - Choose a front-end technology stack for your application. This can include frameworks like React, Angular, Vue.js, or even native mobile app development tools. Set up the project and dependencies required for your chosen technology.

  • Fetch content from the CMS - Use HTTP requests or client libraries to fetch content from the headless CMS APIs within your front-end application. Retrieve the relevant content based on your application's needs and desired UI components.

  • Render Dynamic UI - Based on the received content data, dynamically generate and render the UI components in your application. SDUI's flexibility to create layouts, forms, lists, or any other UI elements based on retrieved content.

  • Handle content updates - Implement mechanisms to handle content updates and keep the UI in sync. This can be achieved through webhooks, real-time notifications, or periodic polling to receive updates from the headless CMS. Update the UI components accordingly to reflect the changes.

  • Customize and personalize the UI -Use the headless CMS content to customize the UI based on user preferences, localization, or any other relevant data. Tailor the UI components, layout, or entire user journey based on the retrieved content to provide a personalized user experience.

  • Deploy and scale: Deploy your front-end application to a hosting environment that suits your needs. Ensure the hosting environment can handle traffic and scaling requirements. Set up caching mechanisms or CDNs to optimize performance.

Conclusion

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."

FAQs

How can a server control UI?

Control power, in this case, has a JSON. How is that? Each component is rendered based solely on the data contained in JSON. This results in the following:

Any request made to a server needs a JSON response which will decide what to show on the screen. This method defines a rule in which a natively developed UI component must be rendered in the view. This results in a high-quality user experience and gives more control over what users can see.

What are the challenges of the SDUI?

The biggest challenge definitely is versioning. Native apps demand regular updates, and many people don’t do updates. As a result, there can be numerous different app versions (many of them outdated). So, a good server-driven system needs to find a solution that will keep users in sync, and the most challenging part is to make all disparate platforms able to render the same thing and support fast API changes.

When is Server Driven UI not appropriate?

Even the powerful JSON response has some shortcomings, and the offline experience is one of the biggest. When offline, the JSON response becomes too large because it needs to respond to any page that users might navigate to in offline mode. As you can imagine, the more comprehensive and complex the website/app is, the longer it takes for JSON to perform and sync.

Server-driven UI pros and cons?

Pros: 

  • The unified client approach- (Android/iOS/web/mobile web) gets the exact same response. 

  • Backward compatibility- SDUI systems can launch features from previous releases depending on their configuration. 

  • No HTML or web-based content is sent from the server, so it is a native UX. 

  • Standardized schema - allows building entire screens across all platforms.

Cons: 

  • Backward compatibility and versioning become more challenging. 

  • Testing costs - Feature releases on server-based client platforms are independent of client releases and therefore are not subject to the same stability checks and regression tests. 

  • Design Limitations - Creating highly customized experiences such as coordinated animations or one-off UIs becomes much more difficult on a server-driven client platform. 

  • Slow loading - Server-driven UI often means that the client has to wait for content to load before displaying anything useful.

It takes a minute to start using BCMS

Gradient

Join our Newsletter

Get all the latest BCMS updates, news and events.

You’re in!

The first mail will be in your inbox next Monday!
Until then, let’s connect on Discord as well:

Join BCMS community on Discord

By submitting this form you consent to us emailing you occasionally about our products and services. You can unsubscribe from emails at any time, and we will never pass your email to third parties.

Gradient