What Is Server-Driven UI?
judo.app
judo.app
Admittedly it was a weird DSL and I can't say for sure I'd do it again.
The incompatibility of GraphQL and SDUI is obvious; the former dictates UI from the frontend, the latter from the backend. Poor performance stems from SDUI acting as a shim around as set of native component; another abstraction that introduces slowdown.
As for the rest of the point, difficulty in hiring for the bespoke SDUI framework, loss of expertise on the platform of choice... those are all things I've in the tech giant I work at. To the point, that the GraphQL folks had to sit down with the SDUI folks to tell them to back off.
For better or for worse, SDUI the buzzword disrespects mobile engineering. Bored developers leap at the chance to force an overengineered DSL on their coworkers, while upper management is sucked in by the illusion of a thin client offering complete control with no cost whatsoever.
They created it after seeing how effective the intercoolerjs/htmx approach was for their web application.
Hypermedia is a neat approach to building applications. We should look into it more.
One big difference: instead of JSON, we use XML to represent the UI. XML is a hypermedia format with built-in extensibility, which makes it a good fit for server-driven UIs. We wrote about this decision here: https://engineering.instawork.com/when-xml-beats-json-ui-lay...
JSON has a data model based on the lowest-common-denominator data structures available in programming languages, i.e. lists and dictionaries.
HTML/XML has a radically different data model that's based on documents that are filled with content with intermixed markup/metadata.
As a result, representing pure data is awkward in XML but straightforward in JSON, and likewise representing a document of mixed content is very very awkward in JSON but quite straightforward (and easily extensible) when represented as XML.
It's one of those "use the right tool for the job at hand" kind of things.
After discussing more the benefits, I am in favor of us using the pattern because it means we’re moving a lot of complex logic about deciding which “tiles” to show off of the front end client(s) where it can be hard to maintain. We’re centralizing it one place in the backend and surfacing higher level decisions to hide or show the tile, rather than surfacing lower level data the clients need to crunch and reduce into a decision about a tiles visibility . Since the server is a single place to determine which tile to show, we can do things like quickly disable a feature for whatever reason.
We’re cognizant it could become over complicated if we try to do something like reinventing flex box, but I think that using the pattern tactfully is sensible. We’re specifically only doing SDUI to decide which “tiles” to show, not to try to power things like the layout which we are hard coding on the client. I think of it less as SDUI (buzzword) and instead think of it as a helpful way for my teammates to understand “thin client fat API”
I think most people assume the granularity of control is the same as with HTML, which does make it sound like reinventing the wheel, so it's important to think about it in terms of components, not individual elements. For us, the level of granularity that worked best looked something like the different types of posts in a Facebook feed, where each post (e.g. video, photo, text-only, event) would be represented by a different server driven UI component. It also helps when the JSON you get from the server maps directly to the UI, so you can visualize the UI in your head. This means a lot of sum types / tagged unions that don't exactly map well to language constructs in Go, which we used for our backend, but work absolutely great in Kotlin & Swift.
One thing we didn't find a good solution for is formatted text though, so we ended up supporting a bastardized subset of Markdown that got us 90% there, but it just felt wrong.
Downloading remote code from a server is different than downloading UI configuration. The code required for an SDUI implementation is contained within your app and goes through the normal review process.
Kind of reminds me of Mozilla XUL (rest in peace...)
The general problem that arises from "reinventing the wheel" is that people implementing these SDUI things don't necessarily have experience with layout engine design. Case in point, look at the example:
...
{
"padding": [7, 14, 7, 14],
"image": ...
"label": ...
}
...
They were touchscreens ( I am not making this up ).
I can't imagine us being where we are at today if we had to make a trip through shitty iOS toolchain every time we tweak a UI element. We have very complex & custom views per customer.
If I had to do it all again from zero today I'd use pure HTML solution. The advances in open web capabilities give us what we need now.
Uh, no, not at all.
Kind of like... a browser. :)