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.
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:
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, SDUI can be beneficial if you want to do a Programmatic SEO strategy 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 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.
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.
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
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?
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."
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?
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.
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.