What exactly is Backend Driven UI?
Common accepted definition of what is Backend Driven UI doesn’t exist. Independent assessment and judgments are abundant. Rightfully so. Having worked on BDUI for 4+ years my taste of what qualifies as BDUI will be varied from differently experienced engineer. Thus, covering the extreme ends with some examples is good way to illustrate what the subject is. I will also challenge the name itself at some point. The post covers and invites you to think and question the name and what it means.
We have 3 parts. Backend, UI and driving. Literally.
A ColorPicker iOS app might not need backend but most apps will. For example; Zalando app talks to Backend to retrieve list of product or details on a specific product. Amazon will do the same. Notes app uses CloudKit to store and sync data. In most cases; mobile apps are fancy JSON pretty printer. It’s a powerful yet diminishing take on app development but it’s true. It’s a common recurrent post on twitter too. So we got 2 parts; Backend and UI and either one drives the other? Is it backend driving the App or the App driving the backend? I think it’s about perspective.
Who drives?
If I tap on heart icon on product; it fires up REST call and backend system favorites product item storing it on a Database. The heart icon animates during this time to filled state. Did the tap event drive the backend or the backend drove the UI (heart filled)? It will be a chicken egg problem for most cases.
Applications are interactive. On a interactive system, Client (Mobile UI) and Server (Backend) typically exchange state. Any good UI needs to be in sync with application/user state. User event, system event or remote change can all cause state change. Therefore, beyond the first view render, it’s not worth pinning what drives our interactive UI.
For now; any UI that is a function of server response; we can call it backend driven.
Let's take few examples:
UIImage(url: <URL>)- ProdcutDetail page which loads a ProductInfo model which is then used to fill in the UI.
- An app requests to get a screen passing in user locale, preference; the response is targeted to the user preference and as such no 2 users will get some response and thus the UI.
- Try it out; open a new web browser Tab and infer what the UI structure looks like for https://random-ize.com/random-website/ (most knows what Youtube or Twitter site looks like by now)
Simplest form of BDUI
- Anytime you fetch for structured data (JSON) which your app screen uses and represents in UI; content is not statically known. It’s a function of response. Since response was emitted by Backend; UI is a function of backend.
- Most apps (or pretty printer fancy UI) or read only representation of external data are some way backend driven UI.
- In the following snippet, UIImage is a placeholder to represent whatever the URL resource points to. The resource is provided by our NetworkStack (Backend). Thus this is some form of BDUI
let imageURL = MyNetworkStack.getRandomImageFromUnspalash // Example retrival from backend
let imageView = UIImage(url: imageURL)
This is a case of data parameterization. UI is a function of data which is received from Backend.
Isn't everything Backend Driven?
Most apps talk to backend (Client Server Architecture), however majority of the apps do data parameterization, which engineering community doesn’t consider to be BDUI. The true exception is the app which doesn’t talk to external service via network request. There are few apps; Calculator, Color Picker, Camera (photo taking part), Compass. However; Compass is event driven based on events from GPS. We won’t go to event driven UI. Maybe someone already is on it.
What are we missing to be BDUI? What else can we parameterize?
Design Parameterization
UI consist of data on skeleton (eventual image on UIImage skeleton, username on Label, price string on AttributedString of Label). We will refer to it as data parameterization.
UI also consists of design. Design is how a system works including how it looks. We are interested in how it looks for now. A really long name on Label makes the design weird but that’s not what we are bothered here. Arrangement of visual elements, composition of visual elements and visibility of visual elements constitute perceived design. Engineering terms to describe them are composition and layout of visual elements. Visual element here refers to smallest unit of UI.
Can we change design of the screen as a function of backend response? Can the response encode the layout and composition of the elements? If we could then we have design parameterization.
Imagine we got both data and design parameterization. Let’s say we can render a page on app in various ways as specified from backend (we will see couple of concrete example of specification later on).
Let’s imagine we define a Label component using JSON as such.
{
"type": "label",
"id": "uniqueIdentifier",
"flex": {},
"props": {
"text": "Tap to see",
"text_color": "#FFFFFF",
"font_weight": "bold",
"font_alignment": "left",
"font_size": 21
}
}
Flex is object that contains layout information. This example uses FlexBox to define platform agnostic layout semantics. Props is straight out of React concept; it contains data needed for component. Our Label seems like a button component but it has no way of specifying tap event action from backend. If we had a scrollable layout, we might want to paginate when the user scrolls to the end of the contents. We might want to track when a button is tapped. We might want to alert user at other times. Layout and Data parameterization is not enough. Welcome to Behavior parameterization.
Behavior parameterization.
Behavior parameterization is hooking dynamic actions based on events on the view. The number of events is smaller compared to actions. For the above Label , onTap is one event. We can attach Track , OpenDeeplink or Alert action. Please note the set of events and permissible actions need to be exposed by our client rendering engine.
Let’s rewrite our Label to create a Button which when tapped launches a Deeplinked page.
{
"type": "label",
"id": "uniqueId",
"flex": {
"flex_shrink": 1,
"flex_grow": 0,
"padding": [
0,
5,
0,
5
]
},
"props": {
"text": "User Account",
"text_color": "#FFFFFF",
"font_weight": "bold",
"font_alignment": "left",
"font_size": 21
},
"events": {
"tap": [
{
"type": "deeplink",
"id": "_3bb4envat",
"props": {
"url": "yourapp://userAccountPage"
}
}
]
}
}
There are 2 immediate questions or curiosity points right here.
- Is it possible to define & expose all actions upfront in the client framework?
– What about having scripting language on top of this JSON markup?– Isn’t the markup similar to HTML for Web? - What about animations?
– Animation can be thought of as change of state interpolated and rendered as each time. Kind of what SwiftUI does.
These are fantastic questions and I pondered over them quite a bit. You are getting in the right direction.
On the contrary, if we consider these above technique of Data, Design & Behavior parameterization as first abstraction and second exposition of interface model which happens to be Codable/Serializable types, it is standard abstraction and encapsulation. And I think this school of thought is valid too. Not everything has to be named.
Extremes
Flexibility is achieved by additive support for parameterization. Leftmost represents no parameterization whatsoever (not useful for most apps), rightmost is full support for BDD parameterization plus a runtime or scripting language support.
Oh well..
We will keep the high level simple and conclude this chapter by reaping that we need 3 forms of parameterization; data, design and behavior for a sound backend driven UI framework. The name (Backend Driven UI) sure is ambiguous but clarity relies on perspective and need.
My personal opinion: if a client absolutely depends on initial response from Sever to display UI and there is no way to infer what the resulting UI will look like in the absence of response then we can assume its Backend Driven UI.
