Server-Driven UI — A Brief Introduction

Over the course of time, frontend development has evolved a lot. Right from developing static web pages, to the introduction of JavaScript, AJAX and many JS libraries, the way of development has grown. Even the Server can now send us the html files as preloaded pages on runtime, all thanks to Server Side Rendering. This article covers another simple yet efficient way of developing applications on mobile and web where the server will drive the layout on the frontend. We will see its advantages, how we can develop this and where not to use this. Lets get started.

Image Credits: Google Images (https://www.jmix.io/blog/simplicity-focus-through-server-driven-web-ui-development/)

What is Server Driven UI?

SDUI or Server Driven UI is a way to dynamically render UI layouts on the pages based on the server responses. It adds a flavour of dynamic and controllable UI from the server to the front end.

SDUI is made possible by server API responses which decide the layout in which the page should render. No doubt, the client has to be prepared with the generic components and all possible layouts the server can ask for based on the client-server API contract.

Before getting more into the SDUI, let's first understand how the development process works without SDUI :

1. Frontend develops the pages based on the UX shared by the designer.
2. The backend develops the APIs to accommodate the functional requirements.
3. Frontend integrates the APIs to make the data and functionality available to the users.
4. The code is tested and reviewed.
5. Code is deployed and a new release comes to the pipeline.
6. The latest build is available to the users.
7. Users download the latest app ( in the case of mobile apps ) with a newer version number, or they refresh the web page after downtime for deployment maintenance.
8. Change requests come.
9. Frontend develops the pages based on the feedback shared and new requirements.
10. The backend develops the APIs to accommodate the functional requirements.
11. Frontend integrates the APIs to make the data and functionality available to the users.
12. The code is tested and reviewed.
13. Code is deployed and a new release comes to the pipeline.
14. The latest build is available to the users.
15. Users download the latest app ( in the case of mobile apps ) with a newer version number, or they refresh the web page after downtime for deployment maintenance.
16. Change requests come.
17. and this goes on…

Now, after reading the above process, the question comes is why we should let the user download the new updates if the changes are small and known. Isn’t there a way to handle this with simplicity :

Yes, there is, It is SDUI.

How does SDUI work?

The client has to be ready with the components as part of different layouts that the server can ask for. Think of this as different possible UI elements the client has to show, only if a certain requirement comes. Google and Apple store does not let you change the code without releasing a newer version of the App. The application team has to go through the entire release cycle to make the changes available to the users.

Implementing SDUI

SDUI can be made possible using JSON responses from the server. Usually, the server sends the data over the Response body, but in the case of SDUI, the server will respond back with data + UI.

This response object should be made over the top of the client-server contract and should always follow the model. The idea is to render components which the server is asking for a page and the frontend has to make sure that it has all the components readily available.

In the above code snippet, you can see that this response from the server is passing multiple keys which define their role. The page key defines the page name, the layout defines the page's architecture. The server can change the layout from the grid to flex at any time using this config. The next key is the components which take all the components the client needs to render on the page. Each object inside this array contains props which can be the input to the component.

Now, the front end has to prepare a map where it will define all possible components it can offer to the server.

Now once the frontend gets the response from the server, it can render those components.

Where SDUI is not suggested to implement :

SDUI cannot be used in all use cases. There are fewer use cases where SDUI can be passed and normal development can be done.

1. Nested Components
2. Complete new release cycle

Benefits of using SDUI :

1. ByPass Release cycle overhead
2. Faster Change Delivery to the users
3. No Frequent Deployment and download
4. Users get changes available without downloading newer updates from App Store/Play Store.
5. UI Layout control from Server

So Many API Calls to update the view, how can we simplify this?

Well, the answer to this depends on the architecture the app team is following. One of the efficient ways is to use 2 Phase rendering.

2 Phase rendering : Usually in the SDUI the server response combines both data and the UI layout configs. This increases the server response size and might pull us to trouble. To tackle this problem, we can segregate the the data and the UI and pass them as different responses. So whenever the user is not using the App or is viewing some page, the App can pre-load the page and keep it ready until user loads the app back or navigates to the page. This way the user will not see any loading icon or has to face any lag while using the App.

I hope this article has added some insights to SDUI. Please add your feedback and questions in the comments section below.

Thanks.

written by
hariom sinha
New Article drops every Sunday .
Follow me on : https://medium.com/@sinhahariom1