Understanding Server-Driven UI through Primephonic
For as long as I can remember, I have loved music. Some of my go-to genres have always been rock, pop, electronic, alternative, and occasionally metal. There is one genre, however, that always intrigued me — classical. I found that I would sometimes happen upon a piece that I liked, but the genre as a whole still felt pretty inaccessible… that is, until I found Primephonic.
Primephonic is a streaming service designed exclusively for classical music. A few weeks ago, I decided to give it a shot. I loved the experience of using the app. I could engage with the music and learn about the genre, as well as its many sub-genres through thoughtfully curated playlists. I could like certain pieces, which saved them to my “Favorites” playlist. I could search for music by instrument or orchestra. And I could listen to podcasts that delve into the history of each era within the genre. But the purpose of this post is not to highlight all of the cool things Primephonic has to offer those interested in classical music (there are many!). Instead, I will provide my perspective on Server-Driven UI — a concept that I first encountered after reading a blog post from Laurens Van Den Oever titled Discovering Server Driven UI. In his post, he describes how Server-Driven UI was used in the development of Primephonic to greatly improve the app’s performance as well as the overall UX.
What is Server-Driven UI?
Server-Driven (or Backend-Driven) UI means that a server is responsible for rendering what the user sees on the screen (or screens), not the client. To illustrate the difference between traditional, Client-Driven UI and Server-Driven UI, I will turn to an example featured in Joe Birch’s article, Server Driven UI, Part I: The Concept. (For the sake of the comparison below, the syntactical differences between each dataset are only important to the extent that they reflect the conceptual differences between Client-Driven and Server-Driven UI).
The image above demonstrates a Client-Driven UI in which the client requests data from a server, and the API responds with the object shown in the center image. Now, consider what the user sees both before and after the request is completed. Sure, the page might look different upon successful completion of the request-response cycle, however the components that make up the screen/page are not actually changing. The UI itself is “statically defined by the client.” The server, in this example, is simply populating pre-existing UI components.
The image above shows different data being returned by the API. In this depiction of the client-server data flow, the application/client lacks the components necessary to create the UI. As a result, these components are provided by the server. Joe Birch says it best when he writes, “[T]he server will return what that screen should look like — this is in terms of both the data for the screen and how that data should be presented… [O]ur application becomes a simple renderer of visual components.”
Advantages of Server-Driven UI
As a novice software engineer, I was initially confused by Server-Driven UI. I have only been using React for a few weeks now, and over the course of those few weeks, a great deal of time has been spent learning the art of building lightning-fast single page applications — thereby minimizing clients’ communication with the server. “Why make screens entirely dependent on data received from the server? Shouldn’t that kill performance?” I wondered. Laurens Van Den Oever offers an answer in his post, Discovering Server Driven UI. He first explains that JSON can be easily compressed between 20 and 30 times, effectively reducing the issue of data quantity to one piece of the larger performance puzzle. Ultimately, Laurens concludes that “perceived performance is more important than actual time spent processing data.” And because data queries can be made in parallel, any performance loss effectively “makes up for the increased request size.”
Laurens also describes another advantage of Server-Driven UI as it relates to communication between frontend and backend teams. He explains that Server-Driven UI effectively unified the frontend and backend developers. Using Client-Driven UI, frontend engineers handled questions regarding user flows and interaction patterns, while backend engineers handled questions about the data coming from REST endpoints. With Server-Driven UI, frontend and backend developers began thinking about the same thing — screens! Moving the conversation toward this new common ground between the frontend and backend streamlined communication between the different teams.
I have listed the other primary advantages of Server-Driven UI below, courtesy of Siva Ganesh Kantamani and his blog post, Exploring Server-Driven UI.
1. Businesses no longer need to depend on users to update the app to show specific UI or to change the order of the UI (at least for the most part).
2. Specific features can be tested on the fly.
3. It’s easy to ship new features and create more reusable components.
4. Native experience for users and reactive for companies.
This is far from an extensive list, however, it addresses the key benefits of using Server-Driven UI. A more thorough analysis of the advantages will be reserved for a future blog post. I will also refrain from discussing the important question of when to use Server-Driven UI for two reasons. First, I hope to do more research on this topic and test it out myself before compiling an answer. And second, there are many other fantastic blog posts that address this topic specifically (Laurens Van Den Oever’s and Joe Birch’s are particularly great).
Conclusion
For those who were unaware of Server-Driven UI before reading my post, it is my hope that you now have a basic understanding of how it works and its advantages over traditional, Client-Driven UI. For those who knew a little bit about Server-Driven UI, I hope my explanation helped fill a gap or two in your understanding. Personally, I was thrilled to discover that an app I had recently come to enjoy offered such an interesting gateway into this technical topic. And finally, if you are even remotely interested in expanding your classical music palette I would highly encourage you to download Primephonic.
Happy coding!
