 Hey guys, good evening and welcome to the last talk of the day. So I am Srikanth GS. I head technology at a company called Hasho Innovations Private Limited. We are a 30 odd crew and we are also a fully owned subsidiary of a company called Build Desk. I hope some of you guys might know about the company. It's a largest payment processor in India. So before actually getting into what we used to do or what we did, I'll just give you an insight on what we used to do before this particular product. We were into the BFSI and fintech domain and payments. So our expertise were into payment processing and such kind of, you know, typical areas. But we kind of deviated from all those. Hi. So we kind of deviated from all those when we were kind of interested in the cryptocurrency domain. And that's all this is about. And when we got interested in it, we thought, okay, we'll just go ahead and make a cryptocurrency exchange. It's not very difficult to look at. It's just something like a single page application. You can just go ahead and make one. And then we had some level of expertise in the crypto underings as well. So based on that, we thought, okay, we'll just go ahead and make one. Okay. This is me in a nutshell. I kind of travel, I kind of code and I kind of manage stuff more of a technologist and the last part is what I am right now, a crypto evangelist. So what this presentation is not, it's not going to be a coding exercise. I think there'll be like very, very minimal or at least one slide with the code. It's not a programming tutorial. You are not going to gain any programming knowledge out of this. And it's not a technology recommendation. I wouldn't recommend React or any other particular stack as a takeaway from this. And there is no demo. It's going to be me talking most of the time. And it's more about, it's about self-learning. At the end of the day, you kind of forget to look into what you did and how it impacted a lot of customers and your own developers. And also it's about the retrospection on what you did and what you did wrong and right. That's all this is about. That's the whole presentation is about. So as I said, we built a cryptocurrency exchange. And it was during the whole boom and in 2016, early 2017, when the wave was happening, the whole cryptocurrency wave. And then we were like wanting to catch the wave as well. So we built something like this. This is roughly the screenshot of the product. Just to highlight, it has a lot of data. And the whole exchange concept, if you have ever traded in a NSE or a BSE stock exchange through any kind of brokers, Aroda, GeoJet, Sher Khan, whoever it might be, you might see that the whole dashboard is filled with the data. And all decisions are made based on the data. And if you don't get those timely data, you are kind of on the wrong wagon altogether. So this was our initial stack. We used to write Ruby on Rails for like years, probably a decade or so right now. And in the prior company, everything we used to write Ruby on Rails. So it was our first choice always. We don't ever think on what to use for our stack. It's Ruby always. And then we used Postgre on this. The entire deployments were on Dockerized. So that was an experiment which we took. Instead of the traditional Capistrano-based deployments, we used a Dockerized deployment model. This was a whole experiment that we took at that time. It kind of really, really paid off. And then the orchestration was done using Rancher. So Rancher currently, the 2.0 runs on Kubernetes. But earlier it used to run on its own Cattle framework. So Rancher is something that we used. And the last two part, this was brilliant. We would never go back to something else. This is something so good. But this is the best part. Writing on Ruby on Rails, it's very easy. It's one of the best backend stack you can use to write on stuff. And we had the shortest time to market. We actually wrote code for six months or less. So it was like a huge short time to market actually. And things went pretty well until the side of the story. The whole customers came in. We never anticipate a flow of customers like that. When you write good product and then you tend to push it to the market. And then what so happened is that we did a good PR. So that was a good thing. And the company that is owning us, they did some kind of a backend work as well to promote us. And the whole thing paid off. So we went up and had the best thing to face ever, which is the 3 Os. It's about scaling and the user experience and availability. You tend to couple scaling and availability is something totally different actually. Availability is about what your customers actually see. They don't really see scale. They only see the availability of story and the experience. And scaling is your worry. Your customers ever get to see scale at all. So what went wrong? The very, very simple thing, the stack couldn't scale. The Rails view rendering wasn't really efficient because when we used to do the FinTech and payments, the transaction, you know, it had its own flow. It had multiple legs and there was asynchronous behavior in it. It used to go through banking and then come back from banks as a redirect. All those flow used to be there. And in that time, we got that time, you know, between the customer experience, there was a lot of time and that time played good for us. But in this case, we didn't have time. Customers needed that data instantly. And we had to show it to them because if they don't see the right data, what they're going to end up is with an opportunistic loss. We can't really blame ourselves or the customers that they didn't get the right price at the right moment to make the seller buy decision. But then again, that's what the problem is. You know, you shouldn't ditch your customers and give them wrong data, right? So Rails view rendering wasn't efficient. We just had jQuery in front of it. It was like the simplest thing to go ahead with. We just had plain jQuery, vanilla jQuery, and Rails were back in it. This was in the solution, you know. And then we faced the business horror, which is this EEO asking me what went wrong, and then comes the three-letter word that they always tend to put on emails, RCA, they need the root cause analysis of everything. And all the CEOs out there, they don't get the tech, but they just need that RCA, you know, with a lot of stuff. So yeah, we gave the RCA, it was heavy long-running SQL queries. The main evil out of that, and we didn't have efficient caching, a very natural thing for a small product which was kind of cooked up in six months. And then we had, we were throwing final to bad gateways to our customers just like that. It was like, people would just type our domain and then they would see final to bad gateway, NGINX throwing all that, and HAProxy running it on front. So we didn't have any way to let the customers know that we are down. So what happens here is that, unlike a banking industry where you put your money in an SBI or an HDFC or any other bank, and you believe that when the net banking goes down, you don't really think that HDFC looted your money. You just assume that it's out there, it's in the bank, it's in the branch. So you can walk into their bank, or maybe if it's like you can tie UPI, you can do IMPS, you can do any channel, get your money back. But when a cryptocurrency exchange, which holds the people's money, goes down, the immediate thought they have is that we looted their money and ran away. Because that's what you see throughout the globe, you know. Moundgogs and every major exchange out there, they face this challenge all the time. You know, people run away with people's money and there is no trace. So when our website goes down, it's more than the availability, it's about the trust that's going away, you know. People just assume that we ran away with people's money. And then again, it's about the data. You know, a trading app or a trading exchange, it's mostly a single page app. You know, when I say mostly, you have other pages, which actually takes care of deposit of cryptos, withdrawal of cryptos, all those fancy stuff. But most of the time, people kind of stick on to the page that you saw earlier. Sorry, this one. You know, people kind of stick on to this page where you kind of see the, you know, the markets out here and the personal summaries out here. And this is an order book, you know. You kind of see the sellers and the buyers listed out. And on the right side, that's a trade history. So people kind of worry about this. You know, this is the decision logic where they see the trade history. And this is the open orders by your cell. And based on that, they kind of tend to make their own decisions. And the whole thing is about data. So it's almost a single page app. Most time is actually spent on the trading and data is extremely important. If you have ever traded a cryptocurrency trading on any platform, you would really wonder when the Bitcoin actually shoots up to $18,000 and come down to $4,000, you kind of panic and you kind of try not to die. So that's how it is. And it's real-time updates. Customers make decisions based on data again. So real-time updates, when you kind of drill down, it's mostly WebSocket updates. The servers actually throw the data through WebSockets. We kind of display it through charts and graphs. Decision is based on the candlesticks and all those kinds of fancy graphs, Fibonacci graphs and all. And all the extra requests that's firing back and forth, along with events alerts and notifications. You know, you have to give customers all these lifecycle data, whether the trade was successful, whether the order was well placed, all these kinds of miscellaneous data. So this is the nutshell of the data we have to give customers on a very, very aggressive basis. And this is the problem at hand, scaling. It's a mammoth task. You can't really assume that you can throw hardware at everything and scale. That's the decision that we took at the starting point. When we had something like 10,000-plus customers on a real-time-per-second basis, and we had to throw hardware at the problem, it didn't work. Technically, saying we were so bad that we had a 64-core 512GB DB instance, and it couldn't handle the load. And that's so pathetic. We really have to admit that that's how bad it was. And so splitting it into the chunks, fixing the SQL queries. That's obviously a problem that you have to look at, caching of responses. And the last thing is what I'm here to talk about. It's about decoupling the front-end. The customer should experience a totally different experience compared to a traditional Ruby on Rails app. So fixing the back-end issues, this is just a single-slide stuff about what we did. We fixed the SQL query, the obvious thing to do. We moved it to Amazon Aurora, which kind of gave us a three-times more performance than I opposed great. We cached the requests and data. We used Memcache and Redis. It was good as well. A lot of stale data. You kind of make a lot of data. Every single order that was placed, every single transaction that went through, every single trade that happened, you don't ever want to go back to it. It's historical. But customers want them. So you kind of move them to ELK stack, the Elasticsearch stack. And the final part, the ugly part, which we really did not want to do, but I'm a Microsoft fanboy, so I kind of push C-sharp. I get to have that top-level approach of things. I pushed C-sharp, and it actually did pay off. We did the complex weightlifting through C-sharp and .NET. So that's the stack. We are kind of moving to F-sharp right now. This is the JavaScript part of the story. We had to do simple DOM manipulations. We had to show the customer data. Handling of event cycles, which was the data coming through WebSocket. We had to present it to the customer and remove it when it was stale. When the trade happened, you had to remove it from the order book, or else customers would assume that there is still a buyer or a seller out there. This was what we used to do. We used jQuery, which was coming bundled with Rails, and then Vue.js for simple data bindings. This is when we actually stepped into something other than pure jQuery. We had something for the data bindings. So this is the limitation of the setup. You might obviously be getting it. It's cluttered and spaghetti JavaScript code. You write more and more JavaScript code, and finally, you have no idea where to touch. It's so ugly that you kind of ditch it and then rewrite it everything again. There is never ending conflict across multiple frameworks, and Vue and jQuery had some kind of conflict between them, and they were quarreling every single time like your mom and dad. So this was happening more and more. The front end was still tightly coupled with the back end, because it was still Ruby on Rails again. You kind of assume that it's something totally different. You kind of imagine it is different, but it's still, it's the same thing again. Vue rendering was a toll on the app server. We used Puma underneath and then along with the Nginx, but then again, the whole server side rendering of the whole front end, we just couldn't handle it. So we decided to decouple the front end, and deciding on a front end framework. That's the most challenging part. You have a lot of contenters out there. If it were just one single framework out there, it would have been so nice and easy. And your problem would be like, oh, okay, I have this. I'll just pick it and make it, maybe a quiz of it. Now you have Vue, you have React, Backbone, Angular. I think there's more. I don't know more stuff. So that's all the things that I know. So we had that, and we had Roadmap for mobile apps. It was early 2017, so we didn't have mobile apps. We had a Roadmap for mobile apps as well. We wanted to have Android and iPhone apps. So that was also one of the reasons for choosing the front end. This is what we finally came down to. We had Vue.js as a contender and the React. This is the very, very, very traditional comparison study which we did. Finally, I don't even think this is relevant anymore, but back down in 2017, it was very much relevant there. So Vue had a lot of good parts. We had, it was very lightweight. When we used the data bindings part of the Vue, it was very, very lightweight. It had much better documentation. It was so well written that we were in love with the documentation. It was really easy to integrate. The plug and play behavior of Vue into a traditional HTML app, it was really, really good. But then again, for React, we had a lot of benefits around as well. The pure JavaScript nature of React that was one of the most loveable things out there. It had a really good community. And the last part, this is something that the CTO always tends to worry about. It's about the hiring. You have attrition in your company. People walk out. You need to have that talent pool coming again and again. And for that, you need to find the right stack. You can't just assume that, hey, you're a full stack developer. Come do whatever stuff you want to do. People just don't do that anymore. So React had better talent pool at that time again, 2017. This is the short list. We chose React. And it was because of extremely good JavaScript library support and the exceptional talent pool which we could hire. And the last part, the React native for apps. View also has come up with something good. But then again, at that time, React native was kind of really robust. And it was a really good option for building native apps as well. This is when the whole problem started. You just tend to be at the top of the food chain. And then you assume that your developers will immediately learn stuff. You turn in the recommend to them and then they'll write code on the new stack immediately. You tell them, React, yeah, you get it in a month. You tell them, you get in a month. That's what you assume. That's not what you get, eventually. It was too minimalistic. You assume that's a good point, that's really bad point. Not all your problems were taken care of. You had to figure out what is the right piece of the React which you need to use for the right purpose. If you were to choose Angular, you had the whole framework coming with you. That's what we had with Rails as well. Everything was there. You need web sockets, it's there. You need something else, that's there. Everything is there. But when it comes to React, everything is there. But you need to figure out what to use with what and you have God knows no way of identifying what is gonna have a conflict with what. You just assume that they're not gonna fight each other. The concept of a state store was new. Till then, when you use jQuery or even to some extent view, you were throwing state around. State was there which was actually associated with a single element or a component and then you tend to store it there itself. You mutate it, you play along with it. It was all imperative in behavior. You kinda go with the flow. If it happens, it happens. And that was something new to us. The single state store, that was something new to us. And the one way data binding was extremely challenging. I'll say what it was good or bad later, but it was extremely challenging. Earlier we could just pass data. It's our God damn framework. You can pass data from one component to another. Who's actually stopping you? But in this case, it was the hierarchy. It was a parent-child approach and that was quite difficult to digest to start with. And not so good documentation. Again, you have queries, you have difficulties, you have all your problems. If you were to use traditional Ruby on Rails or Python or anything, the documentation is so well done, you kinda go back to it and then, okay, do a half-day digging and you kinda get what you wanted to know. In the case of React, that was not the story. Oh my God. This is where I had a lot of fights with my developers and engineers. They really did not want to write JSX. They were like, HTML, ERB, we are fine with it. We might even write Hamel for you, but we will not write JSX for you. How much of a good it is, what of a good nature it has. Developers were like totally against the idea of writing JSX and I had to push it down them. So this is where I have personal retrospection and self-learning as well. You shouldn't push stuff down your developers throat. It's really, really bad to do. But then again, when you have business pressure, when you have a necessity to bring in revenue, customers breathing down your neck as demons, you have to give them that. You have to push your developers to do work. This is bad, but this is the learning part. You can go down the approach for one year or two years. You can improve yourself and give better life for your developers. So in difficulty and inertia learning JSX, it was extremely painful for them, but they kind of learned it. The good part. So we had components, components and components everywhere. The whole thing was cluttered earlier. Now you have beautiful separate, separate small components. The trade history that I showed you, the sell order book, the buy order book, everything is a component right now. You want to put it in two different pages. We can do that. It's very easy. It's a component. They are not going to fight each other. It's a totally decoupled, self-sustaining stuff out there. Reusable code with single responsibility. You can use single responsibility as a magic word everywhere. Even when you write Ruby on Rails as a backend stack, single responsibility, lean methods, and never touch fat methods, more than five lines of code and you can break it down. It's not really easy to go for that approach anymore. So we got that actually. When it came to React, we got that single responsibility thing coming out very nicely. It was very easy to manage, as I said. You can decouple it and you can throw it around like balloons and then it just worked. Without any or very low side effects. This is what was the magic part of it. Earlier it was side effects. Side effects and side effects. It was everywhere actually. So you kind of update something, something else update somewhere else. You have no idea it got updated. Then you kind of tend to update it again and it wouldn't just work. And then you go to the console and developer console and everything and you kind of try to figure out if there is any console.log the developer actually wrote, which he did not, obviously. Then you kind of juggle through the code and try to figure out where the problem is. We didn't have that anymore. At least to some extent, we didn't have that anymore. So there was little to no side effect at all. So this is something that's nice to have. As I said, there's no code. This is just fancy writing out there because you guys would love to see some line of code at all. The pre tag out there. So this is some code. So we had components for the trade history. It was clean, you know, it was just six or seven lines of code to actually manage the whole trade history part happening. We did a push out or subscribe out there, get the data through a pusher web socket. Yeah, we moved to pusher by the way as part of the scaling because the action cable couldn't handle it. We moved to pusher as well. So the trade history channel is binding to a standard component and then you throw the trade history items into a dispatcher. And then the dispatcher kind of takes care of it. It presents it beautifully on the trade history page. Very nice. This is what we got. This is something that we did not have. This is something that react gave us. Again, the good part, clean data, data which is better handled. There is a single storage of data. So when it comes to mutation, you don't have to worry that you have, you know, ugly states thrown around or ugly data throwing around. It was at one point. So if it's ugly, it's only ugly at one place. You don't have ugly data everywhere. The one way data binding, the hierarchy part is something that we loved. Now you have that parent-child approach to you. So your perspective kind of improves itself on designing, you know. Earlier when you had to build something, you tend to build it as and when it happens. You have no approach or a perspective on what to build and how to build, you know. You don't have that foresight. You need a trade history table. Okay, I'll just put a trade history table that just works, right? Nice, nice. So that's what it used to be. But right now we'll just think, where is this trade history actually being plugged into? Who's the parent of it? You know, how is the parent gonna throw data into the child? Is it gonna be stuck there? Is the trade history table ever gonna push something back up the parent which you need to think about already? Is the props and promises doing work? Fine, all those kind of thoughts came into the whole story as well. The last part, you cannot accidentally pollute data. So it's a good thing, but I totally disregard that. I'm a person who always choose freedom over some kind of a compulsory behavior because one of my friend had a React ML talk last time here. So he was talking about variants in React ML, you know. So what he kind of pushed to everybody was that this is the only right way to do it and React is actually not gonna let you do it any other way. And I was totally opposing that idea. I'm not a developer or a program who likes that. I should be the person making that choice. What is the programming language telling me how to do right stuff and wrong stuff? That's what it used to be till we had the problems. I kind of tend to agree to him at least 50% he shouldn't be hearing this at least. So you cannot accidentally pollute data. Data pollution is a total no go and that's the best part we had as well. The invisible DOM. So earlier what do you normally do? Document.getElement by ID, you kind of tend to manipulate it by hand. You have jQuery, you put the dollar out there and everything works, right? So the DOM suddenly became invisible to us. We didn't touch it directly. So that's a good part. The declarative approach, you know, we coming from an imperative style of a language which is Ruby on Rails, the declarative way was suddenly something new to us because we are stepping into functional as well. The F sharp side of the story and to some extent React ML and OK ML. So the declarative approach was something new to us. You know, you tend to forget or you tend to purposely ignore how to do things. You don't think about how data flows anymore. You don't think about what is the mutation that you need to accommodate. You don't think about what data state you have to change so that you achieve the result. You just think about what is it supposed to be there? What is your customer gonna see? Is he gonna see the right-right history? Is he gonna see the order book? Is he gonna see a red and black color? Is he gonna see the green color out there? So that what a customer sees or what is the experience that he has to get? That approach was something totally new that React gave us as well. So this was something that F sharp was also trying to give us but this was most striking when React kind of forced it down. You know, the declarative way of doing things. You do not directly touch the DOM anymore. You know, that's taken care of by the framework. Updates are bashed and automatic because earlier when I said that there is a trade history which is actually the decision logic for all the customers to make their decisions again. So that was like 13 DOM updates. You know, when a WebSocket data came in, we had to throw 13 updates for all the elements because the price up there on the ticker that had to change, the trade history summary had to change and order had to be removed from the sell order or buy order. Lot of stuff that graph had to change. So there was 13 DOM updates which was happening for every new trade history that was coming in or a trade that happened. This just happened to be magically one. You know, the dispatchers kind of took care of it. All the 13 updates kind of went magically invisible and we didn't have that kind of a personal performance degradation anymore, you know. Updates are bashed and automatic. Think about what and not how. This is what I said earlier, you know. You kind of totally have a different perspective running in your head. You forget or purposely forget how things are to be achieved. You kind of think about only what to achieve rather than how to achieve. Lines of code came down. This was clean. You know, peer review became easier and then your code review part became easier. The CI CD part became easier. Tests became easier. You have no idea what, like everything became easier and that was magical, you know. You have hundreds of lines of code coming to few. Component decision made code smaller. So you have small components and then naturally you can reuse it. Naturally you write less code. Legacy JavaScript code wasn't reusable, obviously. It was cluttered. It was ugly. It was more like noodles out there. There was no way to debug or test. Now, test became much easier. You could have small unit tests and then you could have even bigger integration tests out there and that was much easier as well. It's decoupled and self-handling. You know, self-handling and self-sustaining. Each component reads right now self-handling and self-sustaining. Earlier, you had to kind of meddle with it and make sure that it worked right. Right now, we just assume it works right because we write the right way and then we just get it that it's working right. MVC to pure API. So when I say MVC and when I say pure API, even API is MVC only. We have the controller. We have the view throwing the JSON data. But the experience what a user sees or a developer sees, it's different. Functionality was extremely interwoven with view. You tend to tell the developer, use controllers properly, use model properly. But then again, when you had to show things in view, you had to have that helpers and all those elements which had to tightly couple into the business logic altogether. So functionality was really interwoven with you. Single code base and hard to maintain. You were writing lines and lines of code and then you were your developer kind of quits. Another guy comes up and then knowledge transfer, you take three months of the first developer. He's not gonna agree for a three month notice period. You have one month and of that one week, he'll have some kind of an illness. The rest three weeks, he'll have laziness. So your KT is going to be extremely delayed. Actually, there is no KT altogether. You just assume that the next developer comes up and figures it out magically. Again, which doesn't ever work, but that's what we face all these days anymore. So that was easier. You had smaller code base, at least when all these troubles add up, your new developer will kind of assume to get it much faster than the old developer anyway. Transition to pure API, everything returns data. So this was good for us because it was good for testing as well. We had a lot of testing framework out there. So for all these testing frameworks, a pure data testing is much easier than going through a Selenium framework which used to test buttons and views and view elements to actually assert that the data was right. To assert the data is right, you have to test the data, right? Why are you testing views? Which we used to do, right now we are just testing data. We are not testing that whole view element anymore. View, it goes through an independent testing altogether. View can be anything web or mobile. This was good for us. This was an added benefit. It was a truly added benefit, but it came along with it. So view can be anything. Reignative, so we haven't started using it yet. When I say one year down the line, this was the reason why we kind of... This was probably the plus point that we gave to React compared to view. No, we haven't used it yet. We have written the entire web and Android and iPhone app. It was Objective-C as always and it was Java as always. So we are thinking about using React Native. Small companies, these mistakes you always tend to make. You assume that you can start using new stuff, but you can't. You don't have people working on it and you don't have the knowledge for that as well. So future labs in React Native. As we are just promising, the stock might actually encourage my developers to actually agree on to that. So future apps in React Native. Pure API model complements this approach. This I'm certain. You just don't have to worry about ugly stuffing of data along with functionality. This is gonna definitely complement the approach. Frontend developers can actually collaborate. Earlier, frontend developers were like some kind of an aliens out there sitting in the same company but had no clue what the backend guys were doing. It's not anymore. They can collaborate well with the backend developers because the backend developers are just throwing data. They have no clue what's happening in the frontend. Earlier, they had some level of control and that dominance over the frontend developers. The frontend developers were just UX guys who used to build pretty UX. They didn't have business knowledge. They didn't know what is gonna go where, right? So they were keeping aside these aliens out there having some kind of a wall between those two guys and then there were two different teams all together. All the egos coming in. Now it's not there. You need your frontend developers to do something. You can't just present raw JSON data to your customers. They're not gonna agree to that, right? So you need your frontend developers. There is some kind of a collaboration and that harmony that is coming in which is very good for a good engineering company. UX and apps coming under an umbrella. That's a yet another story, right? You have your app team which talks something totally different when you have a Ruby on Rails team which is actually talking all the magic out there which I totally hate but still Ruby on Rails giving all the magic out there. Your app team guys are still stuck with very legacy code base of Java and Objective-C, right? You have that verbosity coming along with it which nobody should talk. Totally, my friend and engineers don't really wanna talk on Java and Objective-C anymore. You can probably supplement it or compliment it with Kotlin and Swift. Still, it's the same ugliness, right? So that's where the React Native might actually help. My app team will also come talk to my backend team and the frontend team. They are not aliens anymore. I have around 30 people of that, around five people as app developers. Frontend is around four people. And the rest is backend. And all these nine people, they were aliens so far. They are not aliens anymore. They are coming and talking to the backend guys and the frontend guys. They're partying together. They are going for meetups together. So that's nice. That's very, very nice for the company. Benchmarking. So you need proof, right? At the end of the day, when I give an RCI to my boss, the CEO out there, I need to give him proof that I did something wonderful to actually improve the product. I can't just say that, okay, you have to assume that everything is working good and better till the new customers come in and then have this whole scaling problem again. So I have to give him proof and also I have to give him proof to Zyna for example. She wanted benchmark data. So this is the funny benchmark data out there. So we have Ruby on Rails with no optimization. That was ugly 2.8 seconds for the page load. And that is when customers wanted to make 10 trades in the 2.8 seconds. I have no idea how they'll actually do it. They wanted to actually. They said high frequency trading, API calls and all those stuff. All the fancy stuff, they wanted to make 10 trades in 2.8 seconds. They could only make one. So that's 2.8 out there. With backend optimization, just the SQL and the Aurora and all the fancy caching, we got 2.03. And with the React front end, we just did this as an experiment. We did have a lot of time, so because of the RBA and the stuff, cryptocurrency is kind of in a very bad state right now in India, the gray area. So we had a lot of time. We don't have a lot of customers playing around with us. We're hoping that will change in another month's time, but still we had a lot of time. So we just did, okay, we'll just throw away all the optimization just test how the React alone could handle it. It was far better. It was 1.8 seconds, around 23 seconds, comparatively lesser than a pure backend optimization. So that is proof. That is proof to actually give effort and put money into and put the bet into having good front end developers who can give you better products. That's a guarantee that I'm giving to the company. And along with all backend optimization and front end, it was less than 50% each. 1.07 seconds, this is not good by the way. This is not a credit for me. It's really bad right now. 1.07 is still bad, but when you come down from 2.8, it's still a credit. You know, I can tell my engineers that I brought it down from 2.8 to 1.07, but the target is it should be less than a second always. It should be 0.6.5, something around that. So this is the benchmark, the fancy figures. Unsolved issues. So this is still what I'm struggling with, you know. Virtual DOM is at times slow. I have no idea why it's slow because I'm not an expert in React, nor are my engineers. It's really slow. So we are kind of hoping that it's a problem with React, not our problem. That's one easy way to get out, you know. It's React's problem, it's not my problem. We are still trying to prove that with Vue. I have absolutely no idea, but we are just trying to prove it that, you know, Vue is offering a better virtual DOM than React. We are still experimenting with it. We are not sure if it's gonna gain any result, but at the end of the day, probably it will come and tell us that it's your problem again, not my problem. Upgrading and updating is not easy as expected. We assumed that when you have everything decoupled and you have everything that is in a component model, when you have everything in a small, small fashion, you can put it into a box and just assume that. When the box color changes from green to yellow, React version X to Y, it just worked. It didn't for most of the parts. It did for most of the parts as well. So you don't know, but to some extent, it's still ugly to upgrade. You assumed that everything is gonna happen automatically. It did not. It's a decent trade-off to go with, you know. Even Ruby on Rails 4 to 5 was bad, 5 to 5.2 is still bad. It's part of the game. High memory consumption, we have no idea why that's happening, 16.3 MB. This is the client-side of the browser memory that's happening for a single-page app which is just throwing data around. 16.3 is a bad number. We want to take it down to 5.6. So we are still figuring out what is wrong with it. So this is also an unsolved issue. Slow startup time to 219 milliseconds. This is on top of the whole client loading that happened and post that. So 219 is not a good figure. So this is also a trouble for us. This is actually the whole pain point of all four items, you know, the startup time. Because customers expect, as soon as the page loads, everything works. It doesn't. So there is another 219 milliseconds which we really want to trim down to 50 or 45 or something like that. So these are the unsolved issues right now. The learnings. You know, after doing all this bad stuff to your developers and to your CEOs and to your COOs, being the CTO out there of a 30-member company and plus hardly five members who are there in management, you have that upper hand, you know. You have that upper hand that most people are doing stuff that you are telling them to do. So this is the learnings, you know. This is something that I personally got. Scale is not a front end or a back end only problem. You tend to assume that it's a back end problem and then kind of ignore the front end or you assume that it's a front end problem, ignore the back end. It's not. It's a problem. It's a holistic thing that you have to look at. It's a problem of front end. It's a problem of back end. It's also your emotional problem. Because you are one of the component of scale. You assume that code is a component of scale. No, you are also one of the component of scale. If you are not in your right senses, you are not going to scale good. Customers tolerate informed issues, not final tools. This is specifically for us, by the way. Not for everybody because for some people, final two. If Flipkart is down for some time and final two is throwing, you tend to go to Amazon and shop your favorite mobile phone. You know, you don't kind of panic and then go everywhere, right? You don't call your support numbers immediately and then we don't have support numbers. But then again, you don't do that stuff. You know, you don't call Flipkart just because their site is down. People will actually do that to us. So customers already informed issues. If we can at least put the front end out there and which says that something is going wrong, we'll come back shortly. This was nice. You know, we did do this with HAProxy and all the magic of 500s being covered with fancy pages. It really doesn't work. You need customers trust altogether. So customers already informed issues. Developer happiness is extremely important. I have to go back home and sleep. You know, I don't want my developers who call in the morning and say that I'm having, you know, a bad tummy. I'm having somebody some issues and then they are taking leaves because they're scared. They're scared of JSX. They're scared of React. I don't want that happening. Developer happiness is extremely, extremely important for a company which is small to sustain. You have to, you really, really have to hear them out. You have to figure out what is troubling them and you have to try to fix it yourself. That's your job. So initial learning curve can be future productivity. This is something that the developers and myself learned after going through the initial learning curve and the difficulties. You know, JSX is good now. You know, even if it was difficult in the early days, it's good now, but you can't always trust that that's so right. Sometimes initial learning curve is not gonna pay off. You have to bet on it to some extent. You have to assume that your developers will also trust you. You know, that is where your credibility, if you stay with them, if you are a manager or if you are an architect or if you are a CTO, if you stay with your developers and if you give them confidence that, if they are gonna suffer, you are also gonna suffer. You know, if they are gonna have a tough time and have to stay back at eight o'clock in the night, you are gonna stay back with them. If you give that confidence, it'll pay back. It'll, that's where the, you know, the whole experience can be made better between a management and the engineers as well. The takeaways, rewriting code base isn't easy. We did that. We took around a year's time and we wrote the six month code in a year's time. Six months, we took Ruby on Rails. We took a year's time for React and Ruby on Rails. So we did that. We really went through that effort. Not all companies can actually have that luxury. You know, you don't have, certain companies don't even have money to survey for three months or four months and it's a really, really good thing we had. We had to say that, you know, we had that one year time to take an effort and re-render code base. When you're forced to do it, decide wisely. You know, we were forced to do it. Our stack was not good. We had to do well, you know. So you had to decide wisely. We did not decide wisely. I'm saying we really did not decide wisely. We just went with React because it was a hunch. It was just a gut feeling to go with React. You know, we should have done much more exhaustive research on what is good, what is bad. But then again, we didn't do that. So that's a takeaway, you know. You have to do that, take that effort, that advantage to yourself to actually decide on what is the right tool for your whole ecosystem. React is not a one-stop solution. It was just a fit for us. It was good for us, you know. If we had opted for view, I think we would have gotten comparable experience. Now, nothing more to say that React is bad or view is good or maybe the other way around. It would have been comparable. So React is a good choice for us because it was something like a single-page app and it was front and heavy for the customer's experience. But if you are right now having a website which is actually not in any of these domain or directions, you really don't have to go with React. You know, you can still go with Ruby on Rails. There's nothing wrong. There's really nothing wrong. You don't have to be that high-five umbo-jumbo guy sitting out there in one of these chairs and trying to say that, hey, we are also using React. You don't have to do that. It's okay to use your traditional stack. You can try Java code. It's fine. It's fine as long as it's about delivering. You know, if you can give something back to the company or the organization or your team members or if you are a company which is just made of developers, if you're gonna give back to something, to amongst yourselves, at least, it's all about delivering. It's not about using fancy tools. It's definitely not about using React or View or one or the other. It's definitely about delivering and it's about the personal satisfaction that you get after delivering it. You know, you have a timeline you tend to always forget about it. You have a deadline you always tend to cross. You have people who's gonna give you a call at night and say that, hey, you did not do the commit yesterday night, that is gonna happen. That's gonna be there for really, really long time, but it's all about delivering. So if you do that, you are successful. It really doesn't matter what stack you use. That's all, guys. Thank you very much. And my name is Trikan G.S. That's fine. Thank you very much for your handle. And any questions, please? And I'm sorry to say that I'm not a tech wizard, so if you ask me anything very deep into React, I might not be able to answer. So if you ask me about how to run a technology team, I'll actually be able to answer better. Any questions? Great. That's nice. I'm actually free of all the worries. I thought you guys might actually ask me JavaScript. Thank you. Thank you all, guys. Have a nice day. Have a great evening.