Server-driven UI (or Backend driven UI) strategies #47
Replies: 24 comments 40 replies
-
|
Hello, I'm working at Molotov.tv in France as an Android developer, and we implemented server driven UI. All the navigation is pushed by the server and then is map on the app side to fragments or activities. Backend can push dialogs or screens via what we call About the UI, most of it is on the backend and is used by web developers (desktop app and smart TV), but mobile apps, we decided to move away from it as it complexifies a lot our code, we still keep some parts though, like buttons, texts which are variable from a dialog to another for example. I think personally that it's important not to go to far in server-driven UI. Before moving a bit away from it, the app was way to generic, which had a lot of drawbacks for us and didn't really helped us to develop faster. Still it was very important for the product owners to keep the dynamical navigation, which in the end I think our app benefits a lot from it. |
Beta Was this translation helpful? Give feedback.
-
|
Hey! I work at Airbnb, on a platform team that has implemented a robust SDUI system across Android/iOS/web for our product teams to leverage. I've implemented our Android approach to this system. I'm biased given my work on this team, but SDUI has been a largely positive shift for us on quickly launching products & experimenting, especially given we share the same responses across all three of our primary platforms (web, iOS, Android). But it introduces a large amount of complexity and is quite a paradigm shift from more "client-driven" development our developers are mostly used to. Pros
Cons
OverallSDUI is incredibly powerful when launched, but migrations to SDUI are tough in my experience. Without strong tooling or a dedicated team to support platform changes & improvements, it might not be worth the complexity for small teams to build leveraging SDUI, especially if there's not enough time for a proper migration. We're in the process of quite a few migrations, so many things are partly client-driven, partly server-driven. In the perfect world, every screen is server-driven and leveraging the same rendering code. In practice, there will always be a mix of the two, and we'll have to see how this perfect world plays out in the future. Mobile-specific, I personally think with the adoption of Jetpack compose and SwiftUI, we'll see significantly better tooling of server-driven UI implementations, as both implementations of more declarative rendering match up much better conceptually and in implementations with SDUI responses. |
Beta Was this translation helpful? Give feedback.
-
|
Related #43 |
Beta Was this translation helpful? Give feedback.
-
|
Love the responses so far! At Lyft, these are our main motivations for adopting server-driven UI:
However, we don’t have a single one-size-fits-all solution for server-driven UI, since the demands of a live-updating in-ride experience is quite different from the needs of a server-driven form flow for onboarding a driver. Thus we currently have a few different solutions and occasionally teams have to build new ones. For our teams that are looking into building server-driven solutions, here are the downsides that we ask them to think through:
To minimize potential problems for Lyft teams extending or building new server-driven capabilities, we have these general recommendations for them:
Lyft engineering also has a podcast episode discussing this topic more, have a listen if you’re interested! P.S. @rbro112 we’d love to learn more about the GraphQL solution you’ve adopted at Airbnb and how you’re using that to structure your SDUI APIs |
Beta Was this translation helpful? Give feedback.
-
|
Hey everyone! Can I add questions regarding modern frameworks? 😅 |
Beta Was this translation helpful? Give feedback.
-
|
Interesting discussion! I assembled some information about bigger companies applying SDUI in their apps:
https://dev-ios.blogspot.com/search/label/server-driven%20UI |
Beta Was this translation helpful? Give feedback.
-
|
Hi there folks, I was meaning to write a blog post on Backend Driven UI strategy. Its going to be long. TLDR: I work at Zalando and my team works on the backend driven UI framework. AppCraft is the name of the project and has 3 parts. Backend (react + graphql + personalization engine) which spits out JSON the clients (Lapis/Golem i.e iOS and Android framework) consume to produce AppExperience. Thanks @pkcpkc for the mention up above. One big consideration to keep in mind when going for the strategy is the range. Let me explain: Backend Driven UI consists primarily of 3 parameterization: Data, Design, Behavior
The extreme opposite is the Web. It allows full parameterization and even comes with scripting language (bonus). We at AppCraft have gone for all 3 parts but constrained on Design (fixed static typed animations support) and Behavior (client exposes event/action which are shipped as part of framework). Event can be The UI is compositional and purely functional. We got couple of primitives and they can be composed to create effectively DOM like structure or ViewTree. Abstraction and Encapsulation of these primitive is left to the backend Component. This allows amazing reusability while lowering the cost of detailed knowledge on primitives for everyone contributing. I would love to share more but my key observation is find where your needs are on the parameterization range. This is effective guide for us to answer are we reinventing the web browser or providing OS tailored experience. In that I do want to present a subtle question I'm looking for more concrete evidence: If we build backend driven UI truly powerful, would it be be closer to how Web Browser work? |
Beta Was this translation helpful? Give feedback.
-
|
At @sampingantech we're working on a partial features for our SDUI only for form (wizard-like) screens. We decide to chose JSON Schema 7 at the moment as our payloads structure, the actual rendering in android was also inspired by the team behind reactjs form There's a few problems we've come so far: Brainstorming done with a few caveats at the moment, there's no native android solutions (library) exist at the moment to start development, so we need to come up with our own solutions instead, therefore we're choosing At v1.1, we're god classing everything on Phase v2.0, we're open sourcing our solutions for this dynamic ui in our github @sampingantech, but due to a limitation and use-cases that coupled with our current solutions and projects, we decided to closed source it :( but you guys can take a look the early implementation here and say hello to the author of our v2 development thanks to @ilgaputra15. The solutions now more generic and a little to platform agnostic (a few of google maps and android import still exist though) :))) A versioning exist at server-side, to handle different form rendered in android based on which users already submit the form, then mapping the key-value question with users-defined input (answer) as: so we don't lose relation between them (e.g: user able to see their last answer, before submitting another with updated form structure from Web Portal) Because JSON is actually unordered, to achieve ordered question (rendered in Android & our Web Portal), we were defining a new key-value pairs outside reactjst conventions, called A Google Form sectioning/conditional answers introduced at v2.5 and we're using approach of multi-step wizard as stated in the point no. 2, also there's a new property called Bonus screenshot: |
Beta Was this translation helpful? Give feedback.
-
|
It's interesting to note that many here implemented their own SDUI code or strategy and unfortunately the result is a private project / API. In case anyone is interested in an open source API to implement SDUI strategy on web and mobile, I recommend Beagle |
Beta Was this translation helpful? Give feedback.
-
|
SDUI is a great design approach to overcome some of the challenges where we wanted to have quicker updates on all the media channels without forcing users to update through the store route. I recently started on this approach and during brainstorming found a couple of open questions, could anyone here help us with some of the implementation behind the SDUI.
Any suggestions are welcome here... |
Beta Was this translation helpful? Give feedback.
-
|
Plaid Engineering has a good blog write up on how they approached SDUI using directed graphs: |
Beta Was this translation helpful? Give feedback.
-
|
What a great discussion. I was contemplating the move to server-driven UI/UX as well, and I received so much insight here, so thank you guys. And I was able to prove that a lot of the concerns I had were valid. Having said that, I'm wondering if anyone made a good use of the declarative nature of SwiftUI or Jetpack for SDUI at all? I know there have been some discussions around the web, but I'm interested to see if anyone made real improvements by combining the two concepts. I'll begin my journey soon anyway, I'll update my progress. Thanks all. |
Beta Was this translation helpful? Give feedback.
-
|
I want to chime in here and say that this has been a great discussion to follow. Our team is trying to implement Server Driven UI. We've had several different iterations of it internally (e.g. re-usable components like widgets / banners and some screens) and have faced some challenges. That said... the benefits outweigh the challenges. We find that product velocity, developer experience, and product experimentation exceed the development cost. I was wondering if people were willing to share some of their solutions! I've managed to consolidate commonalities across different resources and can share at the bottom of this post. The biggest pushback we've seen regarding SDUI is related to versioning. The common problems I've heard are:
My thoughts re: above and from what I've read online are:
Any thoughts on above? Am I correct in thinking these are the only options? I doubt it, since it seems like there are some good discussions here, but wanted to check in as well 💚 Here are the resources I've found: |
Beta Was this translation helpful? Give feedback.
-
|
Hi All, I've been mostly a passive user of the GitHub, and recently came across this discussion and found it very interesting. Below are few points as to how we implemented our SDUI. We don't have need for persistent data so that was more or less ignored in our implementation.
|
Beta Was this translation helpful? Give feedback.
-
|
Hey everyone, we at our company are considering this approach and would be very interested if you could comment about any new findings for the two years since this was first posted. Would you do the same migration again? |
Beta Was this translation helpful? Give feedback.
-
|
Hi guys, is there any example of SDUI using Graphql and federation? I imagine different graphs combining into a supergraph with all the operations and components in one place. But I can't find any kind of example. |
Beta Was this translation helpful? Give feedback.
-
|
Unless you're downloading PNGs from a server and rendering them on screen as is in the phone, there is no such thing as Server Driven UI! You'll always have code that takes some sort of JSON and outputs UIViews/SwiftUI.View/Fragment. Understand your product, figure out the levers that have to be moved and parametrise that using native code. |
Beta Was this translation helpful? Give feedback.
-
|
One more SDUI framework, looks very promising https://github.com/divkit/divkit |
Beta Was this translation helpful? Give feedback.
-
|
At Ensemble, we have built an open source SDUI framework with browser based editor and from what I know we are the only SDUI platform with several production apps and almost a million devices running apps built with Ensemble. Check us out - https://ensembleui.com |
Beta Was this translation helpful? Give feedback.
-
|
Hello Amazing people out there , i was going through this chain of messages it really helps me in understanding how SDUI works, but how do we maintain balance between scalability and reusability of components.so basically what is the best approach ? to have generic component and make it flexible for gaining reusability or have specific components depending on where it is going to be rendered |
Beta Was this translation helpful? Give feedback.
-
|
Hi guys, I was going through the conversation, and I am developing an SDUI using Flutter. I have one major question related to navigation. This question isn't specific to any particular framework, but since I am developing with Flutter, I thought it would be useful to mention Flutter. How should navigation be handled? Should we use the framework-level navigation system, or should we implement our own navigation system using a stack? Framework Navigation: If we use a framework-level navigation system, we can only use pre-defined routes like (/homepage, /profile, /login, etc.) that are specified during build generation. If I want to display a new route without an app release, this might not be possible. Own Navigation: If we create our own navigation system, we would need to manage many aspects similar to what Flutter, KMM, or Jetpack Compose handle. We would need to implement proper stack navigation. In this case, everything would be rendered on the same page. For example, if I render the homepage and then navigate to the profile page, we would push the profile page JSON over the homepage. Currently, we are able to generate UI from the server using JSON, and for navigation, we are using Flutter's navigation system. I need your help with this. How should I move forward? |
Beta Was this translation helpful? Give feedback.
-
|
Hey everyone! 👋🏻 We’re working on a Server-Driven UI framework for Flutter and would love for you to check it out. 🚀 |
Beta Was this translation helpful? Give feedback.
-
|
@dream11 is coming up with a SDUI framework for React native |
Beta Was this translation helpful? Give feedback.
-
|
Hi everyone, For the past year, at @nativeblocks (https://nativeblocks.io/), we have been building SDUI SDKs and a platform that addresses most server-driven UI problems. We solved many common issues and edge cases, It's worth taking a look at it (https://nativeblocks.io/features/)
I'm here if you need to learn more about Nativeblocks |
Beta Was this translation helpful? Give feedback.


Uh oh!
There was an error while loading. Please reload this page.
-
Hello everyone!
I’m working at OLX Brasil as Software Engineering Manager in a team called Mobile Platform which is responsible for the platform development of our mobile apps. We are studying Server-driven UI (or Backend driven UI) strategies for our mobile apps and we would like to know if anyone here has already had some experience with this approach that we can start some discussions here! 😄
Beta Was this translation helpful? Give feedback.
All reactions