14 ms·

My team is trying (something like) this pattern out. Initially I had the sentiment that many commentators here had, “this feels like re-inventing HTML”. After

My team is trying (something like) this pattern out. Initially I had the sentiment that many commentators here had, “this feels like re-inventing HTML”. 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”

Zanfa 5y ago
We used this pattern a lot at my previous company with a lot of success over the years. Operating in almost 10 different countries, mostly running lower end Android phones and being able to slightly customize parts of the UI on the fly to suit different markets is really powerful. I've been hearing how webapps on phones are going to be indistinguishable from native apps soon(tm) since around 2012, but it hasn't happened and I don't see it happening any time soon. 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.

Zanfa 5y ago

We used this pattern a lot at my previous company with a lot of success over the years. Operating in almost 10 different countries, mostly running lower end Android phones and being able to slightly customize parts of the UI on the fly to suit different markets is really powerful. I've been hearing how webapps on phones are going to be indistinguishable from native apps soon(tm) since around 2012, but it hasn't happened and I don't see it happening any time soon. 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.