Thank you everybody for joining this session on rapid iterations with server driven U I. Um So first of all, I would like to ask you, you know, what would you do if you were in my shoes? So let me share the story.I joined my current team at Robin Hood that owns critical features around the stock detail pages, the Robin Hood charts and the shareholder experience. Soon after joining the team, I found out that all the three clients that we support like I Os Android and Web are super thick.

What that means is that the majority of the rendering logic was on. So when my, one of my first project that came into my queue, the estimation of getting the work done across all the platforms was super huge, you know, when I got into the room with my engineers and it was like, yes, it's gonna take us few X months to kind of deliver this basic thing.

Um Also on top of it was added difficulty of inconsistencies across the three platforms. So a very basic example is um let's say we had a button on our I Os app. Uh It was left aligned. But on the Android app, it was center aligned, you might wanna know why, because there were two different engineers at two different times implementing, you know, the SIM similar design of the app. And so this caused a lot of like divergent behavior um that accrued over time.

So I'm Akansha Gupta, an engineering manager with Robinhood. And today I would like to share our journey on rapid iterations with server driven U I. Um Since we are all virtual here uh with the show of maybe e hands through chat. Uh How many of you have heard about server driven U I in one form or the another? Anyone here? Awesome. Thank you so much. Yeah, that's perfect. So we do have few folks who've, you know, heard about served driven one. Uh Awesome. So let's just jump into it. So this is by the next 50 minutes where we're gonna talk about traditional mobile development. Uh You know, what exactly is this, you know, server driven? UY, how it works? We'll go through a very basic, you know, sample response just to, you know, uh visually understand the concept.

Uh talking about advantages, challenges and I want to, you know, make sure I leave you all with some key takeaways. Uh So yeah, let's dive into it. So first, I wanna talk about how a traditional mobile development looks like. So we'll have our client developer who would create the layout and presentation of the U I, uh once the code is written, it is packaged into the app and is submitted to Play Store. If it's Android or App Store, if it's I OS, uh next step would be that uh you know, uh the companies like Apple or Google will kind of review our app version. And uh you know, once we get a green lit, they are made available for our users to install. Uh the, the biggest thing here is that even once this is done, we are really at the mercy of our customers to go ahead and update their app version uh so that they can make use of the latest feature. See, there are a lot of hurdles, you know, really to get your code out there.

Um This definitely slows us down, you know, in this fast paced world, uh especially when we want to try a lot of like iterations and, you know, experimentations to find out the right behavior for our customers. Um Another thing that strikes to my mind is this seems to be more of like a static form of development. Um One thing from my experience is that uh if there is like a high severity issue or a trouble ticket from customer, you cannot easily roll back these app versions. So you might wanna like push another code change and you know, kind of have to go through this process. So divergent behavior in consis inconsistencies across your platforms and super slow pace, you know, when we are thinking about these product launches. So um let's take a moment and look at the diagram. We have the client who is sending a request to the server. Uh The server will respond back with the data. So what needs to be rendered? But the U I or the presentation is really packaged into our client app itself. So how does uh this look visually? So let's say we have our three platforms, web I, Os and Android. We have the, we, let's say we have two screens for our app.

And as you can see all in itself is like, you know, a huge chunks of code that needs to be maintained for all three platforms. And as I said that, you know, in this really fast paced world, you know, where technology is changing every minute. Uh Do we really want to wait this long? I hope not, right? Um So here enters the server driven U I. So let's try to understand, you know, what exactly is server driven U I. Uh So in this case, the the server will drive how our presentation or the U I looks like. So uh let's let's just, you know, walk through the basic, you know, example, here, the client will send the request to the server and instead of the server just responding back with the data, it's gonna tell us it's also gonna provide us the data model plus the view model. So what we are trying to do here is tell me what needs to be displayed, but also tell me how it needs to be displayed. Uh The big advantage of this approach is that you are offloading a lot of your logic from the client to the back end. So then you have less dependency on your client. Let's say if you wanna like. Um of course, in this particular scenario, your client literally becomes like a blank rendering slate with very little logic of its own. Um So what does it do?

It opens up a plethora of opportunities for companies to be really agile and you know, move faster to ship awesome products. So let's dive a little into, you know, um how this this looks visually. So again, we have our three platforms, Web I, OS and Android. And as you can see, we have, you know, the two, you know, the two screens can be powered from like a single source of truth. So there is like central logic that exists at the server side that can, that can power all the three platforms. And if let's say we have to make a simple change, you can go ahead change the API server response and boom, you know, it's gonna render across all three platforms. Um So how does it work? You know, just like going through a little more, you know, details one step forward. Um you know, the client sends a request to the server, the server will send back a view and a data model maybe using an API call. Uh One of the common for uh and I know, you know, a lot of the companies use is the JSON format, but you can also use, you know, other formats, let's say XML and all. Now, once we have this response from the server, the client needs to be smart enough to like parse this, you know, view and model separately.

So as I said, views will determine, you know how we want to show our presentation layer and the data model will determine, you know, what needs to be rendered. Now, take a pause and think about that. We do want our end customer to do some actions, right? So some sort of let's say there's a button, you know, the customer clicks on the button and there is some sort of, you know, interactivity involved. So these sort of like triggers and actions need to be predefined at the client site. So let me take a very basic example. Uh suppose we wanna build a client component which should understand, you know how to render a button on the server when given a server response. This means you can actually set up a button anywhere on your app without any client site change. This also means that you can actually remove that particular button from your app and change. So you really don't have to go through that whole deployments, you know, mobile deployment cycle and common U I items, let's say, you know, re uh label or button or you know, like some carousals can all be temporized using this. So, you know, definitely wanna refer like the Lord of Rings like, you know, one code base to kind of rule them all. Uh So let's look at a very basic, you know, sample response. This doesn't mean that this is how we implement that Robin Hood.

This is just to, you know, help us all understand the concept. So let's say we are trying to, you know, render fruits on our app uh with apple, you know, 20% people like it banana 25%. So that's like the likability factor. So in an SDY system, um it would look something like what we see on the right. So the type would be home screen. So we are trying to render a home screen where the title should display as fruits. And then we have the fruit sections which contains a sorted list of you know U I elements that need to be rendered. So the first one says, hey, the data model should be that the label should say apple with likability percentage, 20% with some description. Now how should it be rendered? It should be of the type button. So you know, build a button that says apple, uh the color should be red and the height and width should be 20 you know the other uh uh list item is label is banana, you know with the percentage and description and we want to display it more of as a header text with yellow color.

So as you can see in a single response, we know what is to be rendered and how it needs to be rendered. Uh And so the API is returning a collection of all these different EU I components that make the whole presentation of our screen. Now, what are the advantages of this approach? First and foremost, you know, that jumps up is, you know, you write once and you share the business logic across multiple platforms, right? Um So brings in a big factor of reusability in our overall, you know uh design uh since you are, you know, you are able to make your U I changes. So as I discussed, you can add button, remove button, you know, with the with the change at one central place, there is so much power in your hand, right? Um Shorter release cycles, right? You are no more dependent on, you know, Apple and Google to kinda, you know, review your model, you know, then our customers to update the app version to make use of it. So in the market and personally, we've gone from like weeks to literally in a matter of days, like as soon as you have the change in um and your server deployments can be controlled through internal uh approval process so you can really move fast.

Uh You can do a lot of like a B testing with this sort of uh power. You don't have to, again, you know, go through the whole process. One big thing that it helped me and my team was eliminating like the divergent behavior that we had across platforms. So now if you go and look at our I Os Android and, you know, web app, they are pretty much, you know, consistent in terms of the data and the charts that show up. Uh It also helps our client keep super thin. So, you know, majority of rendering logic is now on our service side. So we don't, we have very less dependency on our client platforms. Um One key call out I wanna make is that in times of like a high severity issue, this has really helped us because we can have a faster, you know, M TT R or like meantime to response uh for, you know, remediating high severity issues. So this has really helped us, you know, um with such sort of scenarios. So since nothing comes for free also has its own challenges. Um So the first and foremost is, you know, um it's a pros and cons of both on both sides. So client has no context on the U I. So it kind of becomes as this blank rendering slate. So your system uh the design that you make should be smart enough to have, let's say the client interactions, logging, etcetera defined as part of your framework.

Uh The second biggest challenge is building the right back end abstractions, right? For example, as we saw in the uh in the JSON uh code piece, we had, you know, like a lot of nesting there. So what level of nesting is? OK. And you know that fine line is definitely missing, right? So um it's more think about it more like a recursion, like you can go as deep as you want, but you do want to have a boundary somewhere. Uh Testing can be challenging sometimes because you have so much power, you know, as you know, with the making changes to your server, you want to make sure you're not breaking any of the U I, right, any of the clients. So there's always like, you know, this, this testing thing that that can become daunting sometimes. Um Also, you know, as we saw that these server responses can get super large because we are getting the data as well as the view models, uh you know, performance and so on and make sure, you know, it's very well load tested. Um So that, you know, you're not having any sort of optimization of performance issues. Um So I do want to talk about, you know how we use that Robin hood at a very high level.

So these are the screenshots that you see of our ETF pages So just to give a background ETF is some, you know, is a collection of stocks. So as you can see, let's say a single ETF will have 25% of technology stocks, you know, 14% financial energy and so on. So all these charts and pages are driven through a server driven U I at Robin Hood. What this means is that, let's say my product comes to me and, and you know, it's like here, Kanga, we want the technology sector to look like red because we feel, you know, red uh appeals more with technology. It's just a single line of code at the server side and you know, that will just go across all the three different platforms. So it's as simple as that. So it's giving us a lot of flexibility to control all these various, you know, components, colors and layout that we have. Um not just that sort of data, like all the charts that we heading through NSTOY, any chart, you can simply think about it as the granular level xy coordinates. And you know, these are the points that make segments and you know the lines.

So let's say if I want to add more charts, uh add more points to the chart or like maybe extend my chart left and right. It's as simple as to, you know, make a server side change and you know, it will be reflected across all platforms. So I do want to you know, um summarize the talk with, you know, sort of like some key takeaways that SDU I is super powerful, you know, very fast development and it, you know, helps with iterations, uh saves a lot of time by avoiding duplicative implementations, especially like the divergent behavior that, you know, my team had in the start.

Um But yeah, power comes with responsibility. So um it's not a silver bullet solution. So one thing that comes to my mind is um let's say your product case is a very small basic app that has a lot of static data then is using SDO I might be over engineering. So make sure that you look at the pros and cons and depending on what stage are you in, you know, by the right call. And with that, uh thank you everyone for, you know, attending this uh session. Um I can take any questions if you have uh feel free to put them on the chat. Um Thank you, glad you guys like it. And if you have like any questions, you know, later on, feel free to connect um to the women in tech or my linkedin. Uh Yeah. So one question here is, what was the main reason you decided to switch to Sdy? Uh Great question. Uh One of the major reason was that we have a lot of moving parts in our app as you saw like the ETF sections, the charts and one common trend was, we are doing a lot of like user research, right?

So, you know, there are few components that users prefer to have over the left or right. Uh You know, just to make sure what appeals to them better or, you know, helps with. So, um exactly as you said, you know, A B testing. So this really helped us to do faster A B testing and these sort of experimentations. Um how hard was the migration process and how did you sell this idea to the business? Uh Great question again. Uh Vira Lakshmi. Um So the migration process a lot depends on, you know, do you have a framework in hand? Uh if you know, you're starting from scratch, um like the M it's, it's not really, it, it was a, you know, multi mark set of process where we did like several iterations having like, you know, milestone one, milestone two. So for example, the first idea was to just move the static data, you know, uh to sty and then charts was like a fast follow up. Um selling the idea to the business was really going back into the back, uh you know, the backlog that we get from product.

And um you know, consolidating the ideas that, that where the shipping time can literally be, you know, a day or two where we've been, you know, scoped like weeks to, you know, get that product out to the audience. So um like putting that, you know, one pager with the TLDR and you know, pointing out request that had happened in the past to show them that value of, you know, how, how much value this can bring to the company. I hope that answered your question. Uh Any more questions in the last few seconds looks like. No. Thank you so much for attending and yeah, um see you, see you around. Thank you. Bye bye.