@rbro112 Hey Ryan, I have some questions related to SDUI not sure if they had been overcome before you left :airb.

1. Some of the UI elements like EditText may require data validation to proceed to the next screen, with the SDUI approach, are we carrying the validation rules along with the same response?
2. For Unified client approach part, does the exact same response mean that we are gonna use RecyclerView/Epoxy/Scrollview to digest the same amount of content as one webpage, instead of dividing the content into multiple fragments/activities/customviews?

Hey Ryan, thanks for sharing. When you say "deferred responses", do you mean paginating UI elements (e.g. return the modules to render first 30 elements)? Do you do any sort of deferred loading within a list?

Say you have a screen that's server driven and the first element is sort of expensive to compute, so you want to return a placeholder component for that, and then return the rest of the page. How do you pass the client information on the placeholder component once it's done computing?

@yarian I assume they are referring to something akin GQL's asynchronous response mechanism of @defer - https://www.apollographql.com/docs/react/data/defer/

hey @rbro112 Liked how simply you explained the complex structured approach of SDUI. Had 1 doubts tho which I wanted to clear out from you.

How do we do state management with SDUI as i believe its good for rendering static screens but cant understand it for the dynamic pages.

How do we do state management with SDUI as i believe its good for rendering static screens but cant understand it for the dynamic pages.

Hey @piyu99, were you able to find a working solution for this? I am also looking for some references.

Perfect timing on that podcast, published just a few weeks ago! That was a great listen, I'm also interested to hear more about Canvas, sounds very interesting. I just built server-driven layouts on our Android app, leveraging our existing SDUI schema, wrapping up that PR now 😄 . Would love to hear how Canvas is taking this task on. A quick search didn't result in anything, so seems like it still might be internal as of now.

Our GraphQL solution leverages a central data mesh & schema built by some brilliant backend engineers. I won't do a great job explaining it myself as I personally haven't worked on it directly, but the developers published some great content to our tech blog, as well as a presentation. This covers the data service, not necessarily the schema/response structure we leverage.

On the mobile side, we leverage some in-house codegen that allowed for a very modularized GraphQL codegen approach in our Android & iOS repos, something we were unable to leverage with Apollo in the past. This helped teams add the GraphQL fragments and queries specific to their product surfaces while being able to share the "core" UI & data they'd like from core modules.

One of the points you mention - Choose the right abstraction level - is something critical we established early on that hasn't changed much since we initially built our system. Most of our UI consists of sections. These sections tend to be pretty large, usually groups of cohesive content, whose styling is mostly driven by the client's implementation of that given section. We have a great design infra team who has built lots of useful tooling allowing us to leverage standard styles & components without worrying much about changing styles. This has been pretty consistent all along, but we do have some sections (ex: TitleSection) that are very configurable, such as text size, weight, and more. Padding & dividers are also entirely server-driven (notice the green spacing in the screenshot below).

It's important to note that for us the data is somewhat separate from the rendering. The GraphQL fragments we use implement a Section interface, which all section data models implement. Section rendering, we call them SectionComponents, leverage specific keys pertaining 1:1 to a rendering. These SectionComponents simply transform the section data model to the UI components that make up that specific section. Every rendering is unique, but can leverage any data model that it would like. This means we can leverage a generic data model like TitleSection, with a title and subtitle across many different unique renderings of a different title SectionComponent.

Here's a simple screenshot I just took showing the breakdown of how our sections are split up to give a visualization of how we tend to organize the content on our screens. Again, each SectionComponent (separated with a blue line) you see here is a unique rendering, with the actual section data model that backs each potentially being reused or shared. The scrollable content is all made of sections, and even the footer (and soon to be toolbar) are server-driven. All of the copy/images are server-driven, with many of the assets & styles being client-driven. It allows us a lot of flexibility with a good balance of rigid styling and client rules. This applies to most of implementations of our SDUI system, encompassing quite a few of the screens you might even use yourself if you use the Airbnb app!

Glad you like the podcast! And thanks for the detailed write up with the custom screenshot, it's super helpful! I'm really curious about this part:

This helped teams add the GraphQL fragments and queries specific to their product surfaces while being able to share the "core" UI & data they'd like from core modules.

1. What specifically do the clients encode in their GraphQL query to render say, the experience details page that you shared? I'm having trouble visualizing what a GraphQL fragment/query would look like in an SDUI context
2. How do you manage the separation between feature-specific components like the ExperincesFooterBarSectionComponent and the general-purpose components that all features may want to share? Do you have a single client-side screen renderer that knows how to handle every component, or are there different renderers?

As for Canvas, it is really new and is fully internal right now and I'm not sure if we'd be able to decouple it enough from Lyft to open source. We use protobuf for our client-visible APIs, so Canvas consists of a set of primitives like buttons, layouts and action callbacks defined in protobuf, renderers on the mobile clients and web for rendering those primitives in a hierarchy, and a feature-agnostic backend service that manages screen templates composed of those primitives (like say, "help screen"), and exposes those templates to other backend services so that they can incorporate those templates in their responses. We're using Canvas in areas where we don't want to be blocked on client releases to test out new kinds of components our layouts.

There are limitations to Canvas though, because it's really hard to specify UI with fancy transition or branding animations, and it's really complex to model UI that has client-side state, so long-term I expect the server-driven parts of our app to be a hybrid of Canvas-driven UI alongside the existing macro-component models.

1. Everything in our SDUI boils down to screens and sections. We query a list of both as top-level fields in our request. We mostly care about one screen in that list, the "ROOT" screen. Other screens can be sent, which are usually subpages. These subpages and ROOT all leverage the same list of sections. A screen has a layout (in schema) associated with it for portrait and landscape form factors. Each layout also has "placements" that specify the sections (and some light styling) in order in which to render them in that given placement. The specific screen example above has "Nav" (toolbar), "Footer" (bottom book bar footer), and "Main" (main scrollable content) placements in which our sections are rendered and placed into. Right now we leverage Epoxy (Android, iOS) for our declarative UI building).

2. We leverage a plugin system on a per-feature basis to pull in section renderers at runtime. On Android specifically, we accomplish this through Dagger multibindings. This means that if a feature queries a section's data model, it can also render that given section, without an explicit dependency on the section. We decouple business logic from the section's rendering (to a point, some sections do require client state to render, which we provide a way to leverage through a similar plugin system) through an event-handling system. Events can be fired from a click or other user action that is passed to an event handler. These actions/events are also typed in schema through an Action interface. Event handlers can be scoped generically (we have a lot of "core" events for basic functionality) as well as scoped to specific features.

We're trying to limit the amount of feature-specific sections we have, and leverage a bank of 100-200 "core" sections that are flexible enough (within means) that they can be configured dynamically based on the use case.

Ahh this is really cool. We don't have anything like (1), but with Canvas we're doing a plugin approach very similar to (2). It's nice to know that other companies are thinking about these challenges in a similar way. Thanks for the detailed response!

Similar to the more general UI discussion in #53.

I have! Jetpack Compose on Android is also very similar, and I am starting to prototype a generic server-driven UI approach that will leverage both frameworks. Hopefully, I'll have an initial prototype of this that I can open source before too long 😄.

I'm looking forward to it, @rbro112 !

From my side started a brief prototype on how could it work using SwiftUI—backenddrivenswiftui. Nothing special at the moment, just parsing json and building corresponding views with properties. Next step will be adding some actions and maybe check Jetpack Compose also.

hey @kandelvijaya Had 1 doubts tho which I wanted to clear out from you regarding SDUI

How do we do state management with SDUI as i believe its good for rendering static screens but cant understand it for the dynamic pages.

Hi there, quite long time but here are my thoughts.

SDUI is easier for read only screens. They don't have state that changes often.

However we do employ state management of for example wishlisting and reacting to changes somewhere else in the app via delegated cache type to the main bundle. We don't have read-write capability as of now (example text_field) but if we did, we would rather offload the changes to backend and rely on it providing accurate state on next call.

If you do have specific example then happy to ponder and share my thoughts.

shameless plug here - please check out ensemble it solves all the problems you are taking about and lets you build highly interactive, pixel perfect production apps with 100% SDUI.

Apps like MyPlace, Tin, etip and many many more.

@nitinjainhcl The answer to both of your questions is generally yes.

In its most simplest form you can think of Server Driven UI as a mechanism for passing props from your server into your components on your clients. These components need to be compiled into the client application.

You'll need to define a schema that allows for this and your server and clients will need to conform to the schema.

thx for the reply...
in one of the scenarios where I want to modify my JSON schema and add a component that is not already there, how this is going to work on the client?

@nitinjainhcl you'll need a supporting component on all clients. The challenge IMO is to make your components generic enough so you can get maximum reuse while avoiding an attempt to recreate HTML/CSS/JS. IMO it's possible to do this and create a toolkit that you can leverage from the backend that makes velocity far faster than even building in modern web frameworks (ie. React).

Declarative UI is a massive enabler for native development as it was for web applications (and arguably the web with HTML essentially being "declarative UI").

At REA Group (Melbourne, Australia) where I work we've successfully used SwiftUI, Jetpack Compose and React as the rendering engine for a number of Server Driven UI implementations.

One of those implementations allows for quite flexible manipulation of the UI with regards to layout, with essentially a SDUI API that provides access to a small subset of the web's Flexbox implemented in SwiftUI, Jetpack Compose and React. While flexible this API has a strong adherence to the project's design system. This seems to be a good fit providing a lot of power from the backend while maximizing reusability.

This is coupled with a flexible actions systems and the entire app is kept in a state tree upon which the actions can operate. Because it's declarative UI, changes to the state tree are rendered out visually on screen.

This allows you to make your UI truely dynamic with actions defined on the server but then executed on the client based upon certain events/triggers occurring. For example, let's say pressing a button should make some content appear, that's a simple InsertEffect connected via OnPress trigger. As all "elements" in the state tree have ids, that content can be inserted into a particular part of the state tree which then causes a render to occur.

The really powerful thing about this actions system is that we use it for everything. Navigation, dynamic content/UI manipulation, web sockets, deep linking, forms, logging, tracking, optimistic UI changes, even triggering payments using the in app payment systems for Apple and Google. As an added benefit, once we had implemented web sockets we were able to implement hot reloading without any client changes whatsover!

What's more, we did this with a very small team, just a couple of native developers and a few web developers.

We absolutely would not have been able to build this system without native declarative UI so as I said, it's an enabler.

Hey @alexhayes, this sounds really cool! Is the implementation open source? I am curious to see how it implements state management.

Unfortunately not. There are two blog posts 1 2 and an accompanying video that talk about the various aspects of the framework but nothing else public.

Essentially the entire app, from the top down was stored in state, with effects that could inject and manipulate that state. I know that sounds like it shouldn't work, but drilling into that state tree and manipulating it was orders of magnitude faster than say SwiftUI rendering, so that was fast enough for me.

Great insight @danielvdao thanks for sharing. This is essentially the same conclusion that I've come to while building out our second iteration of SDUI at REA Group (I've commented in other places in this discussion about our implementation).

When we looked at the options what I felt it came down to was that this is Server Driven UI, so naturally it should be the server that deals with versioning, not the client. Once we come to this conclusion we can then accommodate for the various different scenarios like you've listed gracefully.

Note that in our implementation, components themself do not fallback. If the client doesn't know about a component sent from the server it simply won't render it. It's the server's responsibility to send something that can be rendered, that includes attributes of a known component.

In our implementation, for every request clients send a custom header that indicates versioning details of the client, such as the framework version, app version, app name, OS, OS version, manufacturer, model number etc.

It's then up to the server to return something appropriate for that client.

In practice we've had to do this very little because we focused early on low level, granular components, but where we've mostly needed to do this is in places where we don't have parity on the clients - for example, we may not have SuperDuperComponent on Android, but we do have it on iOS.

Where this happens we create a SuperDuperComponent on the backend which acts as an interface to render that component in the client. We then embed that logic within the backend SuperDuperComponent, this way we don't need to have if/else logic all throughout the backend code to handle this and it makes it really easy when, say for example, Android does reach parity, we just change that single backend component, leaving the fallback for old versions. Once we no longer support the old version we would rip out the fallback (however we've rarely done this, but IMO that's not been an issue).

@larionov I've just written a blog post about REA Group's second attempt at this type of architecture.

https://www.rea-group.com/about-us/news-and-insights/blog/introducing-atomic-part-one/

Part two, which I think will cover more of the information I think you're after will be out tomorrow 🤞 - I'll post back here with a link.

@larionov took a little longer than expected to get the post out due to a backlog of other posts - but it's here;

https://www.rea-group.com/about-us/news-and-insights/blog/introducing-atomic-part-2/

Down the bottom it includes a demo video that showcases what the developer experience is like as well as some of the features we've implemented.

I think you missed the point

SDUI is a different technique, it;'s been used by companies like Amazon, Lyft, Uber, Workday and many others for years. Check us out at https://ensembleui.com

Downloading PNGs or any image really, is actually a form server-side-rendering. There was was an interesting strategy used by Amazon's Silk browser for low powered devices that would server render all/parts of a web page in the cloud or not that worked similarly to what you are describing. This is of course less of an issue today as mobile devices have made massive leaps in battery, memory and cpu specs.

SDUI is slightly different in that client-side rendering is still taking place, however layout decisions are happening server-side. The base set of components which can be laid-out are typically fixed and configurable through JSON (or really any encoding parsable by the device). The goal is for rapid reconfiguration of a user experience to meet ever changing business needs. SDUI typically makes the most sense in very feature rich mobile apps who's business/CX need change faster than their mobile teams can release new versions of the app.

As many other posts on this thread have pointed out, the cost of creating such a system is high and should not be taken lightly. I have seen many attempts either fall short of the full configurability goals or they become overly configurable and drain system performance to unacceptable levels since layouts contain so many configurable elements that parsing and rendering do not meet necessary SLAs. Finding the right balance between configurability and performance is really what shifts us between client-side rendering and SDUI and it certainly gets murky and fast as to which side of the line you are on.

excellent points, I couldn't agree more. We built quite possibly the world's first ever and end-to-end (i.e. zero code, all SDUI) system back in 2007. It is still in use as core platform for a $80b+ public company. I was one of main architects. We have done the same with Ensemble this time for anyone to use. You may think I am tooting my horn but go and try it out. Would love to get some feedback as well as you are quite knowledgable in this space.

Good point. I agree with your general observation that SDUI is really like building a browser within a native app. The big difference and why it will always be faster than a browser is that SDUI is configuring pre-built and pre-compiled rich components. This may and will 100% of the time include some logic as well so any practical SDUI platform has to allow you to write some code (Ensemble provides javascript for that).

When you go to a webapp, you download lots of HTML + javascript. HTML is like an assembly language of div/span and basic form inputs. Everything on top of it whether it is react, angular or just plain js component is built with the basic building blocks of div/span etc. Browser only knows about those divs and spans. As a result, it has to interpret 100 or even 1000x more HTML/JS to render the page. HTML does not have a first class, pre-compiled DataGrid, Calendar, Carousal or any such rich component.

That's why SDUI, when done right, is like a modern rich browser that will always perform better than HTML and have richer interactions. Again, if done right.

Agreed. Key point is that to do it right, you have to tune your configurability. Too small and you are back to HTML. Too big and you can't remotely configure as necessary. That said, browsers can support predefined components these days as well which can dramatically lower the HTML over the wire. These are cacheable as a separate JS library. I've learned over the years to never count the browser out as it keep surprising me. Their ability to stream process our server generated complex layouts with ever-changing component needs have been what's kept them in the game. Their primary weakness continues to be JavaScripts single threaded nature which puts data manipulation directly on the rendering thread (us mobile devs know better!). As the bottlenecks in web-worker communication improve and browser support continues to grow who knows where we'll wind up. There are also multi-screen work flows that really very few frameworks support properly outside of fully client-side rendered applications which needs to be addressed, but that is a whole different can of worms.

All that said, mobile apps provide a certain look and feel which you will never be able to fully achieve in a web port, so yes, there is and will always be a place for purely native rendered CX. I am in no way suggesting giving up native rendering. I find it better to know the competition than to count it out (and I have to support web with my solution anyway so might as well make it the most performant possible). What we do know is that our customers care more about performance (every 100ms matters to them) and some of our most critical business units care more about configurability, than either do about perfect looking CX with rare exception. To address these complex trade-offs we have had to adapt out solution to use a hybrid approach in app depending on the business unit with which we are working.

well said again. Would you be interested in a private demo of what we have built? would love to get your feedback

Hello everyone. I also have the same doubt as @renukame . In the company where I am, we are implementing SDUI, we have encountered the difficulty of managing the routes and/or pages since when starting the application flow we do not know the number of screens, as we click on the response It tells us the data for "the next screen" but that screen is not declared in the project, there is only the first and only one. There will be cases where the flow has 2 screens and in another 5 that is where we don't know how to address it because if this would happen what @renukame says, reusability or scalability? Do we couple that rendering logic into a single component or do we have to create the total number of screens that could be used?

Thank so much.

@kmahmood74 @thiscompsciguy @alexhayes

hi @henryinfanteg your use case is pretty common among enterprise apps that are driven by workflow. Back in Workday, we built an SDUI for all dynamic scenarios like this, every screen was dynamically generated in that case and there were a good 20,000+. I am very familiar. Ensemble will be able to handle it through dynamic navigation built into the platform. You may think I am shamelessly plugging my own platform but that's the only fully SDUI platform that I know that can handle any use case.

Awesome looks great. I wasn't able to find a way to define client side logic. This has been the biggest headache we've run into in past attempts.

Thank you @thiscompsciguy for sharing your experience,
We took a different approach to it; we decided to go with the action-tree system and dispatch events to registered classes. To connect the SDK with the existing business logics, we leverage KSP to generate all glue code and JSON generation.

Most of the Nativeblocks' parts are open-source; you can find all of them on @nativeblocks.
Here is an example that might be helpful on how we implement it.
https://github.com/nativeblocks/nativeblocks-template-android
https://github.com/nativeblocks/nativeblocks-foundation-android
https://nativeblocks.io/docs/compiler/kotlin-action/
https://nativeblocks.io/references/android/core/action/
https://nativeblocks.io/references/android/compiler/action/

For example, this is a very simple case, you can define an action in code and later, based on the ketyType and other parameters, reuse this component from the server

@NativeAction(
    keyType = "EVENT_SENDER",
    name = "EventSender",
    description = "Send an event to Firebase.",
)
class EventSender {

    @NativeActionParameter
    data class EventParam(
        @NativeActionProp
        val key: String,
        @NativeActionProp
        val value: String
    )

    @NativeActionFunction
    fun sendEvent(param: EventParam) {
        // Send the event to Firebase
        Log.d("HELLO_NB", "sendEvent: ${param.key} and ${param.value}")
    }
}