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:

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?

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