In the world of app development, the push for faster updates and more dynamic user experiences is constant.
Traditionally, changing even a small part of an app’s interface, like moving a button or adding a promotional banner, required a full development cycle. You had to change the client side code, test it, and submit a new version to the app stores, a process that could take days or even weeks. What if you could update your app’s look and feel without waiting for another app store release, using components already built into the app? This is the core promise of server-driven ui.
Put simply, server-driven ui (or SDUI) is an architectural approach where the server dictates the structure, layout, and content of the user interface. Instead of the UI being hardcoded into the client application (like an iOS or Android app), the app fetches a description of the UI from a server and renders it on the fly. This description, often a JSON payload, tells the app which components to display, in what order, and with what data.
Major companies like Meta use this technique for parts of Instagram and their other platforms to roll out UI configurations and experiments from the server. It’s a powerful shift that turns your client app from a static blueprint into a dynamic canvas controlled by the backend.
Why Bother? The Architectural Goals of Server-Driven UI
Adopting a new architecture is a big decision, so what are the driving forces behind server-driven ui? The goals are centered on agility, consistency, and personalization.
- Faster, More Flexible Updates: This is the primary goal. SDUI lets you change what an app displays without forcing users to update when the change uses components and actions their installed client already supports. New client capabilities still require a client release. This is especially critical for native mobile apps where the app store review process creates significant delays.
- Cross Platform Uniformity: It can help teams align experiences across web, iOS, and Android by managing UI composition through one server API. Each platform still needs a maintained implementation of the shared component contracts. Yelp uses this approach across six variations of its two major apps on Web, iOS, and Android.
- Dynamic Personalization and Experimentation: Because the server decides what to show in real time, teams can tailor the UI for different user segments or run A/B tests without shipping separate app versions for supported changes. Shopify uses this to show different store layouts to different merchants. For example, a “Best Sellers” section might only appear for stores with a high volume of products. A traditional client can also personalize from data or remote configuration, but SDUI centralizes the layout and component choices on the server.
- Reduced Development Overhead: Updating shared layouts from the server reduces the need to repeat the same UI changes across separate codebases. Once the necessary components are in place, teams can spend less time coordinating platform releases.
The Core Philosophy: Guiding Principles of Server-Driven UI
Server-driven ui is more of a design philosophy than a specific framework you can just plug in. To implement it effectively, teams follow a few key guiding principles that reframe how they think about the relationship between the client and the server.
Start with the Screen: The “UI Design First” Approach
This principle flips the traditional development process on its head. Instead of building an API based on your database models, you start with the ideal user interface. You design your API response to perfectly match what the screen needs to display.
This is sometimes called a demand driven schema. A practical way to do this is by creating a “dream query”. This is the ideal API query you wish you could run to get all the data needed for a specific screen, perfectly structured. At Yelp, for example, engineers start building new GraphQL APIs by first writing a dream query that reflects the desired user experience. By starting with the UI’s needs, you create an API that serves the product directly, eliminating the need for complex data transformation logic on the client.
Keep the Client Simple: Reducing Client Side Logic
The goal here is to keep UI composition decisions on the server and make the client a focused renderer, not a “dumb” one. The client still handles rendering, input, navigation, accessibility, local state, network and offline states, and platform-specific behavior.
When client-side if/else statements choose between layouts or content variants, that composition logic may be a good candidate for the server. When it is duplicated across multiple platforms (web, iOS, Android), it multiplies the engineering effort and creates opportunities for inconsistencies. Centralizing those decisions lets one backend change reach compatible clients on their next fetch, while interaction and platform logic remain in each client.
Serve Ready to Use Content: Return Product Info, Not Domain Data
This principle is about the shape of the data your API returns. “Domain data” is raw, low level information like status codes, boolean flags, or raw numbers that the client has to interpret. “Product info” is presentation ready data that can be displayed directly.
For example, instead of sending a price as a number and a currency code (domain data), the API can send a pre formatted string like “$19.99” (product info). Instead of sending an isNewUser flag, the server can include a “welcomeBanner” component in the response when appropriate. The server can handle shared formatting and localization decisions, while the client still renders the result and applies any required platform behavior.
Speak a Common Language: The Role of a Design System
A unified design system is crucial for a successful server-driven ui implementation. A design system is a collection of reusable UI components and style guidelines that ensure visual consistency.
When all clients share this common visual language, the server can send abstract instructions like “render a primary button with this label,” and each client’s design system can map that instruction to its platform-specific implementation. This provides a common language between the server and the clients. It allows one JSON response to describe a comparable experience across native and web interfaces without pretending that every platform renders identically.
How Server-Driven UI Works: Architecture and Implementation
Now that we understand the philosophy, let’s look at the technical nuts and bolts. A server-driven ui system has distinct components on both the server and the client.
The Overall Blueprint: SDUI Architecture Explained
A typical server-driven ui architecture involves a clear separation of concerns.
- On the server side, you have a pipeline that assembles the UI description. This often includes a template layer defining possible layouts, a data layer to fetch content, and an API layer (like GraphQL) to deliver the final JSON to the client. Shopify’s architecture for their Shop App is a great example, with distinct layers for template processing, data loading, and GraphQL mapping.
- On the client side, the app needs a rendering engine and a library of native or web UI components. A “component registry” is used to map the component names received from the server (e.g.,
"ProductCarousel") to the actual visual components in the app’s code. The client receives the JSON, loops through it, and uses the registry to instantiate and display the correct UI elements.
Defining the Building Blocks: Component and Action Modeling
For the client to render anything, the server needs to describe the UI using a shared vocabulary of components and actions.
Component modeling is how you represent visual elements like buttons, lists, and banners in your API. You can use an explicit type model, where every component has a specific type in your schema (e.g., ButtonComponent, ImageComponent). This is very clear and type safe. Or, you can use a more flexible generic descriptor model. This is what Yelp’s CHAOS framework evolved to use, where components are described by a type string (like "chaos.button.v1") and a generic JSON payload of parameters. This avoids constant schema changes every time a new UI element is introduced.
Action modeling defines what happens when a user interacts with a component, like tapping a button. Just like components, actions can be modeled explicitly (OpenUrlAction, NavigateToScreenAction) or generically (actionType: "chaos.open-url.v1"). The server includes these action definitions with the components, telling the client exactly what to do upon user interaction, making the dynamic UI fully interactive.
The API Conversation: SDUI Schema Design
How you structure your API schema is key to making your server-driven ui flexible and maintainable. If you’re using GraphQL, you can define your UI capabilities directly with GraphQL types.
A common pattern is to use union types or interfaces. For example, a screen’s content area could be a union of ProductList, ProductCarousel, or ErrorMessage. The server decides which type to send back, and the client’s query is prepared to handle any of them. This allows the UI to be highly dynamic, changing its entire structure based on the available data or user context. The schema can also be designed to mirror the UI’s hierarchy, with a root UIScreen type that contains fields for navbar, body, and footer, each containing more components.
Here is a simplified example of what an SDUI JSON response might look like for a home screen:
{
"screen": "home",
"components": [
{
"type": "banner",
"data": {
"title": "Welcome back, Sarah",
"subtitle": "You have 3 new recommendations",
"imageUrl": "/images/banner-summer.jpg"
}
},
{
"type": "product_carousel",
"data": {
"heading": "Best Sellers",
"items": [
{ "id": "p1", "label": "Product A", "price": "$19.99" },
{ "id": "p2", "label": "Product B", "price": "$34.99" }
]
},
"action": { "type": "navigate", "target": "/products" }
},
{
"type": "primary_button",
"data": { "label": "Shop the sale" },
"action": { "type": "open_url", "url": "/sale" }
}
]
}The client receives this payload, looks up each type in its component registry, and renders the corresponding UI element. The server controls what appears, in what order, and with what data. To show a holiday banner instead, a product manager updates the server config. On the next fetch, clients that already support the banner component can display it without a redeployment.
Choosing Your Tool: GraphQL vs. REST for Server-Driven UI
Both GraphQL and REST can be used to deliver UI configurations. GraphQL is often favored because its typed schema helps prevent breaking changes and its single endpoint can aggregate data from many sources efficiently.
However, a purely GraphQL approach can have drawbacks. Client queries can become very large and verbose, listing every possible field for every component. Yelp’s team found that maintaining explicit GraphQL types for hundreds of components was impractical. Their solution was a pragmatic hybrid: they use GraphQL as the main API “envelope” for high level structure, but embed REST like JSON objects for the individual components and actions. This gives them the flexibility of JSON for fast iteration while retaining the safety and structure of GraphQL for the overall API.
Putting It All Together: Adopting a Server-Driven UI Framework
Implementing server-driven ui is a journey. It requires careful planning, the right tools, and a shift in mindset.
Getting Started: How to Adopt SDUI Incrementally
You don’t need to rebuild your entire application at once. The best approach is to adopt server-driven ui incrementally.
Start with a single screen or even just one component, like a promotional banner. You can also kickstart with a template to move faster while you learn. This allows your team to learn the process in a controlled scope. You can also apply SDUI only to new features, leaving legacy parts of the app untouched. This phased approach balances innovation with stability. There is an initial overhead in setting up the infrastructure, but starting small helps manage this complexity and delivers quick wins.
The Prerequisites: Key Requirements for Implementing SDUI
To be successful with server-driven ui, a few things need to be in place.
- A Collaborative Culture: Backend and frontend teams must work together closely.
- A Strong Design System: A shared library of UI components is essential for consistency.
- A Capable Tech Stack: Your client apps must be able to render UI dynamically from a data structure, and your backend must be able to assemble and serve UI configurations quickly (something a no-code backend builder can help with).
- A Plan for Versioning: Your system must gracefully handle older app versions that don’t support new components. Yelp’s requirements for CHAOS, for example, explicitly included forward and backward compatibility.
- A Focus on Performance: Dynamic UIs can introduce latency. You need to manage caching and set performance budgets to ensure a smooth user experience.
Production Compatibility and Safe Rollout
Not everyone will be using the latest version of your app. Before sending a new layout, the server needs to know which components and actions each client supports. Version your schemas and components so it can send the right configuration. If an older client encounters something it doesn’t recognize, it should skip that block or show a fallback rather than break the screen.
Start by rolling out changes to a small group of users. Watch for rendering errors and unrecognized components before expanding the rollout, and keep the previous configuration ready in case you need to roll back.
Building vs. Buying: Designing an SDUI Framework
Some large organizations, like Yelp, build their own internal SDUI framework to serve their specific needs. Designing a framework like Yelp’s CHAOS is a massive undertaking, requiring dedicated teams to build the backend services, client SDKs, and documentation.
For many startups, agencies, and even enterprise teams, building a custom framework from scratch is not feasible. If the goal is faster UI updates and dynamic experiences, maintaining a custom SDUI framework may not be the right path. For web applications, WeWeb offers another route: visually build your interface, connect it to data, and publish changes from one place.
Real World Examples in Action
Let’s look at how these concepts are applied in the real world. For more real‑world projects, explore the WeWeb showcase.
A Deep Dive into Yelp’s CHAOS Framework
CHAOS, which stands for “Content Hosting Architecture with Optimization Strategies,” is Yelp’s unified, cross platform framework for server-driven ui. It was created to consolidate multiple disparate SDUI efforts into a single system for Yelp and Yelp for Business across Web, iOS, and Android, which Yelp describes as six variations. Yelp connects CHAOS to its maintained Cookbook design system and uses the generated Konbini bridge layer to keep component contracts aligned across platforms. Platform-specific implementations can still differ, and unsupported backports require explicit handling. One of CHAOS’s key goals is to enable optimization and experimentation, allowing teams to use machine learning to determine the UI layout to show a user.
The Step by Step Flow: The SDUI Use Model
So how does a request flow through the system?
- Configuration: A UI layout (e.g., for the home screen) is defined on the server using a schema of known components.
- Fetch: The client app starts up or navigates to a screen and makes an API call to fetch the UI configuration for that view.
- Render: The client receives a JSON payload, parses it, and uses its component registry to render the corresponding native or web UI elements.
- Interact: The user taps a button. The client looks at the action model attached to that button in the JSON and executes the defined action, such as navigating to a new screen or opening a URL.
- Update: A product manager wants to add a holiday banner. They update the configuration on the server. The next time users open the app, compatible clients fetch the new config and display the banner without an app update because the banner component is already installed.
This model lets teams decouple supported visual configuration changes from slower client releases.
Frequently Asked Questions about Server-Driven UI
What is the main benefit of server-driven ui?
The primary benefit is agility. Teams can update, test, and personalize supported parts of an application’s interface from the server. For native mobile apps, that means many configuration changes do not require users to download a new app version. New components or actions still require a client release.
Is server-driven ui only for mobile apps?
No. Native mobile teams often adopt it to avoid waiting for app store review when changing layouts that existing clients support. Web teams can deploy client code more directly, so SDUI is useful there for different reasons, such as composing personalized screens from a central service or coordinating UI contracts across web and native clients. It adds little when an ordinary web deployment, CMS, data binding, or remote configuration already solves the problem.
Does SDUI replace traditional UI development?
Not entirely. It’s a powerful approach that complements traditional development. Teams often apply it to screens that change frequently or require personalization, while more static parts of the app, like a settings screen, might remain hardcoded.
What are the downsides of server-driven ui?
The main trade offs include increased initial complexity, a dependency on network connectivity, and potential performance overhead if not managed carefully. A well designed system needs fallbacks for offline states and must be optimized for low latency.
How is server-driven ui different from a web page?
The difference is not native widgets versus HTML. SDUI can drive native mobile components or web components. What distinguishes it is that the server sends a structured description of the interface and the client maps that description to components it already knows how to render. A conventional web page usually ships its layout in client code or HTML, then loads content and configuration separately.
Can I build a server-driven ui without extensive coding?
A custom SDUI framework requires engineering work on both the server and client. If your goal is a dynamic web app with centrally managed updates, WeWeb lets you build visually and publish changes without creating that framework. The distinction is how updates reach users: publishing a web app delivers updated client code, while SDUI sends interface descriptions to an existing renderer.
Is Server-Driven UI Worth It for You?
SDUI is a powerful architecture but not the right fit for every team. It makes the most sense when:
- You ship to multiple platforms (web, iOS, Android) and need to coordinate interface composition
- You run frequent experiments or need real-time personalization
- Native mobile app store review cycles are slowing down your ability to iterate
- You have the engineering bandwidth to build and maintain a component registry
For smaller teams or simpler products, the setup cost can outweigh the benefits. A visual development platform like WeWeb offers many of the benefits those teams are looking for: centralized web app updates, a shared design system, and dynamic data binding, without building a custom SDUI framework from scratch.
