Server-driven UI (SDUI)

Server-driven UI (SDUI) is a way of building user interfaces that are specified on the server.

The gist of the concept:

  • You build a library of UI components the usual way in your web app or mobile app (say, a bunch af React components or Swift UI components).
  • For your app’s various pages and screens, rather than hard-code a composition of these components (with hard-coded props, content, etc.), you specify this composition as some data structure (say, some JSON schema).
  • You store and manage this data structure on the server, so that it’s easily edited.
  • In your app, when rendering a page or screen, you first query this data structure from the server, and then render the page or screen based on this spec.

Some benefits and characteristics of this approach:

  • Nimble: You can quickly update your UI without redeploying your app and going through any app store publish process.
  • Platform-independent: You can control your UIs this same way across platforms, whether web or mobile.
  • Dynamic: You can more easily make your UI dynamic with respect to the user’s persisted data.

It’s very similar to using a headless CMS in spirit, but SDUI more specifically describes use cases that are geared toward building user interfaces rather than (say) blog posts.

You can also learn more about a real-world case study of SDUI in A Deep Dive into Airbnb’s Server-Driven UI System.

Plasmic and SDUI

Plasmic is a visual editor that exposes its model representation via API, so it fits the SDUI use case naturally. The editing experience being visual means editors are not working with JSON data structures or filling out nested forms, but could be directly seeing and manipulating the UI that they are building. Plasmic users can visually drag-and-drop your existing components to compose some larger screen or experience. Developers can query Plasmic’s API for the latest such arrangement of components to determine how to render them in the corresponding mobile app or web app.

Note that the Plasmic Studio visual editor is a web based platform. So, if you are registering code components, then they will need to be React (DOM) components, since you cannot render iOS components natively in the browser. You’ll need these web-based components for your content creators to drag and drop. Alternatively, you can create these components directly in Plasmic Studio, wielding it as a no-code tool—then you wouldn’t need to register React code components.

You will also need corresponding components for the mobile platforms you’re targeting—or at least, you’ll need the equivalent code path to exist. You are treating the Plasmic components as a data structure—one that your content creators can visually compose and manipulate—and interpreting this data in Swift/Kotlin/React Native into the final rendered elements on the screen.

Using WebViews

As an alternative to using native components for these content-driven parts of your app, you can consider using WebViews. These render HTML/CSS directly in specific sections of your app. This makes it possible for you to use Plasmic Studio much more fully as a no-code tool, including all of its rich styling and layout capabilities, without needing to worry about implementing your own native code to render the content. Often, content heavy sections can lend themselves well to rendering HTML/CSS directly in the WebView, and user won’t be able to tell the difference.

Was this page helpful?

Have feedback on this page? Let us know on our forum.