 Hello everyone. I'm Toshi. I work with Flipkart with the cross-platform team and We use React Native and React Native for web to build pages and features which run on all the platforms web, Android and iOS. In my journey of building web applications using React to now working with React Native to build cross-platform applications, my team and I have come across various technologies, the challenges and the optimizations and here I am to put together the learnings we have had in these past years. So today I will be talking about a React Native digitized framework which will help you to move fast and build things. I'll start by taking an example of a feature or a program that we just launched, a loyalty program, Flipkart Plus Membership and I want to point out what were the changes that we had to do in the front end or the UI part of all the applications. So we had changes around the pages. We have various pages on the Flipkart application and all the platforms. Yeah. So we have various pages, the home page, the browse page, the product page and when we launched this program, we had certain changes on all these product pages and these changes were also across the verticals. Flipkart serves a lot of categories, hundreds of them and we launched Flipkart Grocery as well. So if you are a Plus Member, you will have various delivery charges exempted. So yes, we had changes across these verticals and all these changes had to be replicated along all these platforms. We are on desktop, mobile web, Android and iOS. So I put this perspective in a three-dimensional graph which comes out to be something like the one axis is a platform where web, iOS, Android reside. The second axis would be around the verticals that we just discussed and the third axis is around the pages that we developed for in an application. So if I put this, a new feature in this three-dimensional space, we need developers to have knowledge of these three of these three axes and probably for one feature, I'll need nine developers and for some three features, I might need 27 developers. So and the scale at which we operate at Flipkart or the scale at which you would be operating at your product company could be something like this. At Flipkart, we have 100 backend teams which are providing us content and we have around 50 product managers who are ready to run experiments and change layouts and we have around 200 UI experiments currently running on all the four platforms combined. But that's the way we operate that we have one UI team which supports all these platforms and takes care of all these humongous changes. So this needs an optimization on our end on the systems and so let's get into the idle world which we think should be applicable here. So I need not write code on a code multiple times in multiple platforms with the same business logic. I should be able to write once and render everywhere. Also at the times when there are high traffic, when there's high traffic for example in Flipkart, there's big billion days we have and there are changes that we need to do in real time. So we need a tech stack that helps us fixing issues in that particular time without waiting for any app releases, whether it be Android or iOS. Also we need to be page agnostic. If a developer today is developing for a browse page or for a cart page, he should be able to develop for a product landing page as well. So you have to be domain agnostic at some point. Then the core UI teams, when the business logic is written at one place, the core UI teams get some time to work on the networking layers, the caching layers, the app size optimizations. And also having said all of this, we need not compromise on the user experience or either the developer experience. So I'll move on to the accesses one by one. The first access that I want to talk about is the platform. At Flipkart, we use React Native and React Native for web to do the cross-platform application development. We have our various pages written now in React Native and React Native for web. So React Native provides us with one feature to be running on one feature or one page or component running on all three platforms. And we have the native fields intact. Since React Native tweaks the native elements of the respective platforms, we have the native fields of the user experience intact there. And also we have capabilities to fix issues in real time with over-the-air updates. And we have our own in-house dynamic update system for that. And also those who are not familiar with React Native for web, these are the abstractions written over web API which helps you use React Native components and APIs using React DOM. So many companies are today using React Native and React Native for web, for writing their application. But what we did extra here was building our own abstraction layer or own kit which is called the cross-platform kit. Our aim is to write components inside that kit which abstracts the user or a developer from the implementations and these components are guaranteed to run on all three platforms. So I'll take an example. These are the three pages which have a similar component or a reusable component which like a sticky footer here. And we have three pages and this sticky footer capability is added to the React Native Recycler List view which we have open sourced. And now you as a developer can directly access it, write your code over it and you did not know how this part was actually implemented. So there are several other components that we have incorporated in the cross-platform kit and this is how we want to move on with the cross-platform development from now on. So the current state of this dimensional graph we just eliminated the access by writing one code which runs on all the three platforms. Now the next access I want to talk about is the page specific development. The problem statement I feel here is how a developer develops for different custom layouts. For example, you are on a product landing page which looks a bit different and then you are on the payments page which looks a lot different. So you as a developer should not be restricted to, okay, today you cannot build that page because you don't have that domain knowledge. So we took a very standard approach here of digitizing our page. We have now divided our page into basic building blocks which are horizontally and vertically scrolling which we call widgets. Also these are reusable and extensible across all pages and it was easy to add and update the number of widgets that are entering on a page. But what makes this framework a rich multi-digit framework? So for example, these are two pages, page X and page Y and these are the widgets that are entering in horizontal or a staggered layout, whichever way you want. It might have a header and footer to this page, custom to this page. So we have a custom header and footer support. You can reuse these components or these widgets across and you can add new ones. Also we support inter-viget interaction here and to optimize the payload on the wire. We also give time to live to these widgets as well as the page. So the problem statement what I want to address here is if you are a product manager or a backend developer or stakeholder for that particular page and you want some UI changes or want to run some experiments. I want that you should be able to go to a configurable console, change the way the page you want to look, want the page to look and the UI should change without any UI developer intervention. So let's see how on a high level it looks like. So these are the data providers or the backend systems we have. I'm taking example of Flipkart data providers that we have and this is the data flowing to the content aggregator service. This is the place where all the data from different backend systems would be aggregated and you have a layout console which connects to the aggregator service and this is the layout console this one where you will actually your product manager would actually go and make the changes and as soon as the changes are made the data in the form of the widgets or the building blocks flow to the front end systems and gets reflected. So ideally you are not making any UI engineer interventions here or deployments here and the changes get reflected in the front end systems. So now the state of the graph comes out to be one vertical axis and this particular axis is subjected to your product. It might or might not exist for us it does and we are still in the process of solving this and this still exists for us. So the slide that we just saw that where we want to be the ideal world. Let's see with the concept of cross-platform using React Native and React Native for web and using digitization where are we? So we are one feature one code on all platforms by the use of React Native and the cross-platform kit kit that we have built in-house which you today could should also build at your at your end. We are solving this problem of replication of code. Also keep by the dynamic update system that we have in-house and the over-the-air updates capabilities of React Native. We are able to fix issues in real time. Also by the concept of digitization. We now view the page in form of components. It's no more a design. It's more about components how the API power these components if it's in the order of one, two, three, four, five or it's in the order of five, six, seven. So whatever API gives me I render that. And I am page agnostic as we discussed. I also pointed this that we have enabled different stakeholders to make the changes now. The UI is not completely dependent on any UI deployment there. We are still in the process of onboarding more and more pages and React Native Flipkart is a hybrid application right now. And we need our core UI teams to work on different app size optimizations and network layers. We have definitely improved developer efficiency. We are like 75% efficient now. It takes around it takes a lot less time to develop pages when we have digitization and when we write one code. And having said all of this, React Native and React Native for web allows us to build even the beautiful animations that we have today. For example, if you see Flipkart's gaming platform, you will see we have done a tons of animations even on web. So these are a few pages that we have on Flipkart today and there are more of them. You can just go and have a look. And what are the challenges ahead here for us? We're still trying to close the gap between the native and the React Native components. The React Native Library as Parshuram said that we are still in the process of we need contributions from the community and bundle size splitting and reductions as more and more pages are getting onboarded on React Native. The bundle size is increasing and that increases the JS passing time and we need stability on certain devices. We are still to be browser compatible. So these are some open source tools you can look at which we have open source in Flipkart and it's an appeal to the front-end community to build cross-platform tools and share all amongst us. Thank you very much. Yeah, Q&A questions please. So do we have questions? Yeah, Sir, can you please turn on the mic? Hi, my name is Ajit and I want to know how you fix the real-time issues especially for the Android application like in case of the Big Billion Day and all that. Yeah, so since I told you we are a hybrid application but the parts that are written on React Native, we can we use our dynamic update system that we have made in-house and we can just update the bundle there. But in case where the parts are native, we will have to wait for Android releases but that's not a very big chunk. Yeah, any more questions? Yeah, so that you mentioned that, you know, you've not yet solved the products part of the thing. What is the challenge in that segment if I may ask? So I told I talked about the verticals. For example, I'll take example of a vertical which is grocery and so if some changes come on that particular vertical, the people or the developers who have that domain knowledge of their work that with vertical grocery, they will have to make the changes. They're still not there that okay, a grocery product manager can go and make those changes and just render it there. So I think if it's electronics, if it is a different category like footwear, there might be different UIs that might be needed. Okay, so yeah. Yeah, Prana, can you hand over the mic? Hi, my name is Satish, very good session. So I have a question that your widgets, right? So you're planning to use them maybe substituting them in different pages. So what are the benchmarks that you follow for creating this widgets because say for example, a widget is taking say 500 milliseconds or something to load. It might be okay for a thank you page or something like that, but it might not be okay for a search page or something, right? So we make the widgets customizable that way. Sometimes we do give height and width from the back and the data that comes for the widgets. It will have the margin, the height or sometimes the color as well. We might tweak the basic UI part from the back end in terms of color, height, size, or if it has to stick to bottom, if it has to stick to the top, we do keep these contracts intact in the data part. And how dynamic is are these changes? Because say for example, I'm trying to evaluate, you know, the performance of a page and you are repeatedly changing, you know, widgets around this. So obviously every widget would have a different rendering time, right? So how do you track those things and how do you make sure that, you know, things work well? So like my main point to know here is like, what are your benchmarks for creating a widget? Like because they have to, there has to be a standard to work across different pages. Yes, definitely. We do have those benchmarks. For example, a widget will have its own TTL for, I just mentioned it here as well that as you're talking about optimization, we might have a TTL for that widget. If the data for that widget is expired, then only we'll render it again. Otherwise it won't come up on the payload at all. And if the particular widget has not expired and it still can be reused with the same color or, or maybe the same image for that matter, we just sent, we don't send the data over the payload. So that optimized or that optimizations that are talking, that you're talking about has been taken care. But yes, the benchmarks vary from widget to widget. And as I told a widget will consist of the actions or the behavior, the data, that means the data that has to be displayed in the widget and the tracking that we have to do with that widget. So these three are the standards that always come with the widget. And according to your use case, you can always have those optimized, whatever other requirements. Thank you.