Server-Driven UI (SDUI)

In a traditional world, data is driven by the backend, and the UI is driven by each сlient (web, iOS, and Android).
Let's take products listing. You get a JSON with data like: [{"title": "iPhone", "price": 999}, {"title": "MacBook", "price": 1999}, .....]. The client parses this JSON into List<Product> and shows products to a user with predefined UI logic which is hardcoded on the client.

This comes with a few issues.

The most obvious one for me is the versioning problem, which applies only to native apps. If we do things this way, each time we want to add a new feature to our listing page, we need to release a new version of the app for each platform. Most probably, you'll have users that always protract with updates.

This leads to another problem - A/B testing is harder. It's more difficult to validate ideas and extract data from users’ interactions, which could be used to conclude important things about the product.

Many big fast-growing companies like Airbnb, Ozon, Avito have faced these problems and created tools to overcome them.

Let's take Avito - the service where you can sell and buy literally anything. If a user wants to place an ad to sell a flat, the app will show input fields like address, floor, number of rooms, square meters, etc. If a user is selling a car, he sees fields like model, year, mileage.

Okay, you've, as a good developer, foreseen every possible type of product and written a huge amount of complex logic on the client to show required fields based on the selected product type. But the world is constantly changing, and now your users want to sell NFT tokens here and now. What will you do?

The first solution is to add another piece of logic on the client-side and release a brand-new version. I've already mentioned the problems of this approach.

The next one that comes to my mind is to show a WebView. The thing is nobody likes them. They don't offer native UX and often have performance issues.

And the last one is to add a new type of product with some rules for input fields on your backend (from the admin panel, for example) and send it to the client so the client can render the necessary fields. This strategy is called Server(Backend)-Driven UI.

Of course, it's not perfect either.
It's hard to build from scratch and maintain, which makes it expensive. And maybe one day, you'll like to add some fancy type of field or section, so you'll end up releasing a new version.

#dev