 Hey, so my name is Nabindu, I'm an engineer with Haptic So basically how many of you actually know about Haptic, like you just want to have it with hands Okay, so Haptic is a startup which is running for the last four years and so So primarily we started with and M-Commerce kind of You know view where you know, we have our app and then you can check The bot and get things done. It could be flight booking, everything Well, when it worked we found out that Half years back our admin engine was not so great, right? Obviously We had we were just started with NLP and all sort of stuff We realized that a lot of our chats were not being handled by the bot and we decided to print those chats and you know Give an actual human being to take to and then reply to the user so that the user experiences Which led to us to create a chat application This if I would give you an example would most probably be like what's up where Where you know People can come in and know each chat when it get the bot doesn't understand It comes to you and then existent that we have at our on-premises could actually answer your query So Just to go before you go forward We would like to just tell you a few things. We have Python workshop at Arctic, right? So most of the people who come in as an engineer are primarily working on Python and all sort of stuff So we are very new to the front-end architecture stack But we could understand that legacy clients our architecture won't work here Obviously, right because there are a lot of things has to be taken care There has to be sockets and all sort of stuff so that the each chat can come in very quick and you can reply and all happens very instantaneously so we Put out few to do so we thought that we first have to separate the front-end from back-end Remember we are the back-end back-end engineers talking about this and Then we wanted to make different teams able to work in parallel By which I mean that you know Obviously and then wanted to make it look great This was our very first, you know customer-facing app. So we wanted to look at you know nice and clean So, I think most of you might have done this Earlier as well two and a half years back we started with HTML CSS and jQuery Please notice HTML CSS and jQuery These are mentioned separately because we are bunch of back-end engineers have nothing to You know deal with all sort of stuff before and certainly figure out. Okay. We need to work on this stuff What do you realize that you know we started off very quickly, isn't it? We started delivering products and obviously we started writing a lot of cool And our life path very simple We are up and running with the chat application in about two to one-half months Simple jQuery HTML CSS and as the product manager could see that you know We had a lot of improvements and the things are working really well they started coming up with lots of new features and We are very excited. Yes. We started keep on adding them and then they found out. Okay. It's working fine We are adding a lot of course. We are building product, you know shipping new features every day and and sort of stuff Until we realized that you know our system is becoming very slow By which I mean that you know if someone comes in with a chat and then You tend to reply to the chat and then you need something else to be opened up in your tab or something like that It would take a lot of time. You would each and every chat that was coming in We We were taking a lot of time actually trying to figure out how the EY was or wait for the EY to respond before Actually, it could actually serve the user and this was a big problem for us, right? So because we wanted to create a product which would make our life simpler But instead it was making things tougher as we go on and we wanted to build product very fast, we wanted to add new features and Certainly, we started finding our people coming to us and telling this Imagine you are in a fast-paced startup and then the dance you are working on Currently come up and say that I can't touch this piece of code because it's too dangerous for me to touch at this moment At this last stage of release as it may predict other stuff, right? Because we are building so complicated system. In fact, the system wasn't complicated. We made it complicated to be very cranking up with all this jQuery event handling event burpling and all sort of Jargon saw all sort of stuff which we never knew before, right? We eventually, you know saw that those things were Hemphering our user experience a lot and obviously the assistants are also not so great about handling those kind of stuff So we decided, okay, let's take a step back and see what's going wrong over here So we started devying, you know, what is the problem and what's causing these kind of delays or sluggishness of the UI So we found three major problems, right? The first problem being Whenever something changes in our application, right? You can say that the state of the application has changed, right? And whenever you wanted to see what has changed or what is the current state of application We always needed to wait at all Right for simple example, I could say is if I say whether the exception is online or offline and based on that if I have I have productors, you know, or do something else, I would actually see the Let's be very simple example, right? I'd say the green or yellow or red Purple that you would keep up whether the assistant is or the user is online or offline You'd read the color of it and find out whether he's offline or online So in the entire state of the application while residing in the top, right? You would just keep on data attribute and we find out that two people are writing same data That they attribute it to different ways into different places It was not making any sense and rather than the actual HTML code, it was more of the data that was residing in the HTML And that was really, really happening or in the experience or let's just say how we progress with our next stuff or proceeding Also, there are multiple sources of truth in the application One could say that the The assistant is or the user is online by seeing multiple different things Someone read that if the color of the bubble is red, that means he's offline Someone will see if the text is offline, he's offline and different things or someone will see the data attribute Whether it says on and off So there are multiple sources of truth in our dom and everybody who read differently and that that obviously, you know Leads to a lot of errors and issues in our application And one strange thing that happened was people don't keep on adding event listeners, right? This is I'm not printing this up, but it's our first time we figured out the simple button had more than 15 of event listeners A simple button which you do the same at that thing Because someone would not know If somebody else has created a separate JS file because obviously we were in jQuery So we didn't have any one of bundles or something sir So we would have 10, 15 HTML or JS loaded in our HTML and somebody would add a separate Event in a separate JS file. I would never know right and then I would still add and then I'll I'll be like It was working on while I was working on my tab now what's not working Obviously that people or a few other people might have just used pre-emptive or they are just gone Like, you know, everything is working in your staging environment and you go to production. Nothing is working What is happening? Like, I have written my code perfectly fine. It's not working So these are the three major problems you saw That was causing a lot of issues in our system Be the sluggishness of the system because for every time we do something Not just updating the dom to lead on the state of the system we're reading from the dom And obviously there are multiple sources of truth. It has become very difficult for us to maintain what makes sense Or what is the correct way of defining some structure? I'll just give a very quick example of here. This was a very small component or like to say jQuery thing that we had I just switched it's just as on and off, right? It's a very simple piece of code And then you could see there are two things I noticed that One says check, that means it's on and something else says on like on and off the trigger thing, right? We actually found out two tabs using this particular element and to read the state of the application in a different way Somebody was reading the checkbox report type whether it's checked or not checked and someone else was reading whether the text says on and off Right, this was a very very huge problem for us because we could understand that if you still if you keep Going forward like this, there'll be a Problem by two days might bite with each other. No, this is the right thing to do You should not change that I may simply Like change on to active some some other day and then some something will just you know read So you have a very good realization Obviously we had spent around two and a half months just reading the product And it was looking great until then we realized that you know, this is not the way you should move forward And then we should think about something else which would actually solve our real life problems So again when we researched uh with different other companies At bay area or some other, you know, local companies or what how they are actually solving these kind of problems We could figure out these few things which are definitely needed if we are moving from jpeg to any other framework, right? First of all, you should need some state based framework Meaning that for anything everything if you are if I were to find out the state of the application I should never go to the top, right? Obviously you could add some kind of uh your persistent JavaScript store or something of that sort in your existing jQuery code and make this happen But then it won't be persistent, right? You can't guarantee that this particular state and your actual DOM are always in sync So you wanted to look for some application of framework, which is state based like the primary way the Framework work is based on states Who wanted to be predictable and production good, right? So we thought that jQuery has more than 40,000 downloads and we are facing these kind of issues We don't did not want to take any other major chances with anything everything will come forward, right? so We are going to do a very brief analysis of all the textiles out there and find out which was better Obviously one very fast and lightweight because there's one of the reason we wanted to move back to jQuery and the Obviously normal JavaScript code because it was not fast and as I will keep building stuff, you know, getting slower and slower So you want to come like fast and obviously lightweight jQuery itself came around with 190 kb and with all different files that we were creating it was just a complete mess, right? And we never knew as a backend engineer, you know, we should build a bundle all those steps together because nobody in the jQuery forum actually taught us about that And obviously we wanted to be great looking EOS, right? With jQuery, this is something really simple, right? You can plug in play lots of libraries out there, which are really great looking and you know Gives a lot of features to you And the last thing was very important for us, right? We wanted something that is very easy to learn Because the problem that it pays, right? It's a fast moving startup and we had built a very solid framework or system Where everything was working on stage machine or messaging queues, right? For someone who is very new to the system Like let's just say we want to hire some very professional front-end engineer to make them understand the entire architecture or the text type or how the system works It would take at least a month or so before we can actually begin to proceed and create a new application So we wanted our existing people who are working on jQuery We had a very Okay, I want to understand here about JavaScript how it works to actually able to pick this framework up and then go forward So I think many of us still face this problem. There are too many choices, right? The most obvious thing there was Angular and then people there was Ember, Backbone, GSTJs, Knockout, React and whatnot, right? So we are overwhelmed by all these choices, right? We are like, okay, fine Again, let's take a step back and see, you know, like what what of the like this brings to us and you know, how we can, you know What benefits it gives us rather than just, you know going and figuring out the application just go out, right? So it started with Angular And it felt very simple, right? The first text Angular example that you saw in the And this Angular I'm talking about Angular 1, not Angular 4 We went to the Dublin school Yeah, it was a very famous website, you know JavaScript framework and then we went to Dublin school and found out that, you know, I could type in a simple text box and then I could see that the same thing is getting updated in my separate area of the talk, right? We were like, wow, this is wonderful. We realized one problem here We realized that any any any any sort of like if I could just go to the console and update this text By normal JavaScript, still the same thing would happen. We didn't want to Meet or no, we were not quite happy with that, right? Because again, it it didn't make sense like there could be multiple sources of truth over here people Anything and everything and change the state of the application and then something would happen We were not so sure And but like, I think we spent five minutes framework to be very frank, you know Like it was just some other language. We didn't think it was JavaScript Sorry, yeah, it's very serious. We don't want to you know, like we don't have any Anything on that but then yeah, it felt like that Backbone we heard about it. We saw again anything makes sense, right? He experienced of it. It was licensed to Knocked out. I assimilated the knockout And then, uh, sorry. Yeah, so one problem we had at that time We had big dreams. We thought, you know We could potentially be, you know, fighting against facebook or some other sort So it's not really comes with ps devices That uh, that was again some sort of topic for us What if we write the entire application someday facebook comes and say that you can't use react So we started seeing, you know, what what if that happens, right? Like what will happen to us and then again, do we need to react at the recognition again, uh, we saw that Obviously at that point of time you could understand that there is some kind of bundle and uh, you could But then all it was asked to put together and then ship that code We are using browserify at that point of time when we started with, uh, react So we found out that, uh, if you're using webpapers or something like that, uh, that is something called LISS and all right So we could use some of the library which works like react, but this Change a simple piece of code, uh, in our webpapers configuration and everything will start working, right? So inferno at that point of time was a big supporter for us. I am not so sure of anybody heard about inferno It's a react like architecture Framework, uh, it's not react. It's not so small obviously it's it has most of the api's that react offers, uh, but it's MIT license and what it was at that point of time It was uh, very small in size and it was uh, we could just we we did a small pc Where we built a react application like poc small and then we changed in a webpack, uh, the LISS to inferno on a starter working So we sort of get by let's take this chance if if uh, something happens, so we just move to uh, Inferno if it does require Hopefully that is not required anymore. Uh, react is MIT license now and we are very happy about it. Yeah All right, uh, so why react? Uh, which I've spoken about a lot on the previous slide, but then that was not the The profits of other frameworks was not the actual reason to choose react. Right. It was Mostly uh react was offering us a lot more than you know, what we could think of and it made sense to us, right He uh, primary things that uh, you know, uh, made us to decide for the act, right First of all the state based architecture, right? Uh, we initially love we just fell in love with this uh, concept Your state is the source of truth be your application or be your dog, right Anything and everything that your dog represents is some sort of state that is behind that Right. I could simply create an application or simple component, right? Uh, which says uh, in name I could simply pass a property to it and then it could just just display that name, right? So every time I update this particular, uh, variable my dog will get updated This means two things. First of all, I don't need to directly manipulate my dog as Manjula said, right Manipulating and you know working with Tom in the tedious process and sometimes, you know, you need to be very, you know Have a very good understanding how things work at top level So he act of sticking away that from us obviously, uh, and then second thing is that it was very predictable, right The only way the name of the particular component change if I pass as some kind of prop to it Let's just say later on that you will find out the name is getting changed Some some or other way and this is not what we are expecting I can single point you tell that someone is passing a wrong prop to it, right? And I could figure out what all components or what all Actions are triggered in a particular event and I can debug those which was very difficult and jQuery Like if uh, Angola, let's say, right, I could simply go into the console and write something else and then things will just start breaking I'll never know that somebody actually was so intelligent enough to go to the console and do this I would just spend two days finding out what I did wrong Right, so this was a very big win for us. Uh, we are something we are looking for something like that, uh, which is completely driven by states and Uh, you know, uh entire application state base where anything that happens in the application has to go through the state Uh, the data flow which uh, you know also help us the data flow acts It's it's one way data flow, right? The top will get updated only in the state changes, right? And I I as a javascript Come uh programmer. I can define what changes my state. I can put a limit to it I can simply say that okay if you want to change the state of this particular thing you can only do this via this Right, so anybody who is coding in this particular application I believe that most of you if you are already working on react or you know going to work in react and this is a Good opportunity for you to find out how things are working. Probably might not have only one depth, right? There are multiple depth walking on the same project. So react is we feel that's very good at that particular aspect I think many of us don't talk about it very openly But react is very good where there is multiple team or multiple people working on a particular project, right? Because it helps uh Shorten down your development cycle Reduces your bugs obviously and because of the one way data flow you have to be sure that whatever you do in your application Has some kind of implication or it is it is the way that things are happening, right? We could simply go back and find out. This is something that is working Obviously the apis By api they completely mean that the entire architecture, right? It's the life cycle methods It's the component component driven nature of react, right? And It makes sense to us obviously, right? The apis are so beautifully written and also the documentation at the end of time I think huge as beats reacts documentation at this point But then back when it started with react, right the documentation was just a place, right? We just have very little knowledge of javascript. We could actually start digging What was working for react and how things are working over there? So we found out the apis are very useful for us Very simple to write Our most of the things that was happening in the application was some sort of a jacks called the rest API understanding, right? So it was clearly mentioned in the document, right that if you want to do some kind of rest API calls Please do it in a component in mount, right? Like we didn't want to go to any other third party of people ask like, you know Why should I do this it was completely written in the documentation and all sort of things So if it made sense to us and all the life cycle methods were very useful for us to make the entire application So we decided to react, you know, and our entire application is running on take me right now take me Yes, how do you know how do you promote this entire application that it was it was So first of all we started creating small bocs, right by small bocs as mine, right? The first piece that we created was our simply the putter component The putter component simply said copyright article, right? The first thing we did was create this Like small component and then put it up there The one great thing about react is right You don't necessarily need your entire application to be written on react, right? It could use the way the Existing JavaScript framework, right? In this case, we just include the react and react of library as some simple cdn files And then we wrote a simple JavaScript code and then we just import it in the HTML itself how we used to do for a normal jQuery application, right? It started working for us. If I confident obviously We could we could think that okay small part of the application can shift to this react and then potentially at the end of the day You can say that okay, man, this is working for us and then we would completely shift to react We're starting stateless component Stateless components are pure function which is take some kind of property and display some kind of data, right? Till now, there is no performance benefits of stateless components, right? If you if you have to look at the react code, it still wraps around a class, right? Obviously the reacting is working on it to you know make its performance more than the normal component But then we it makes sense for us and we didn't want it to handle the entire Life-cycle method or the initial go and but we were to just try how the react is working, right? So this views in a stateless component together was very helpful for us to create this center component, right? And it was a very big achievement for us. We were we shipped this code in half a day's time and it was working like wow Yeah, and then we started putting small parts of the component right we decide, you know, which components are not so important for the In context to the entire application, even if it breaks, you can wait for half an hour to fix it Rather than something if you think like it is like if the product comes and bangs in our head, you know What what do you tell, right? We started small small parts of the code which are not not so Important for us and then we you know, when we were very confident when We were more knowledgeable about react. We actually migrated the entire application to react So the one thing I would like to tell over here is when we migrated the entire application of react We made sure that there is no jQuery in our application at all like We even though if you're using some sort of libraries additional libraries, we made sure that library doesn't have jQuery as a dependency, right? We wanted to create a carousel and react is click was one of the very, you know Popular library out there. We don't think we didn't use it because it doesn't use jQuery as of now So it didn't use it. So we were pretty sure that whatever we use We are not going to go back to the jQuery life side because if somebody says jQuery in our code There will be so prompted that you know, let's just do it in jQuery. We are not a react way We don't did not wanted to maintain two separate bits of code Some people are putting in react and some people are putting in jQuery So over the past two and a half years, we actually worked on multiple projects. We have more than five to six live react applications which are very heavily think we have the threes and Entities and sockets and whatnot and this is something that you learned over the past two or half year, which was best for us, right? Link and guidelines are the most important part of your front-end application. That's what you believe, right? We were seeing that few people were using normal functions people few people are using es6 error functions and it was just something best like, you know It was it was a two different way if even you found out the same developer is using two different piece of code a different point of time So you wanted to make for this doesn't happen. Uh, so you make uh, we created very strict years guideline We follow Airbnb and on top of that we have added few more restrictions we Believe that you should clear the smallest components possible, right? Very simply put either online or offline that red and green Like purple is one of our component It's just one piece of code which takes the color or the state Whether it's offline or offline and just renders the purple like it's just we have this small components in our system Like we believe this is the best way to go about it Because it makes sense. Uh, because you can reuse obviously the component later over time But suppose some error occurs in some part of in any of the application that it's very easy to find out where actually stuffs are going wrong Initially we needed jsx because again it was some kind of learning curve for us Uh, whether now it is the square we're quite okay with it. Uh, we like how jsx works and obviously the esx feature that comes along with uh Yeah, and then flat states, right? So, uh, we have seen plenty of libraries out there who just uses nested states, right? We make sure that our developers don't create any nested application state This should be as much flat as possible The reason being we want to use pure components over a simple component, right? If if you create a react esx style, right? You can extend the component or you can extend pure component, right? I'll just come back to the difference pure component has some sort of performance benefits So you have to leverage that and obviously if it's a flat state, it's very easy to manipulate, right? So we wanted to make sure the flat states, uh, whatever state you create an application should be as much flat as possible And because we'll use one library called as normalize Uh, uh, it said there, uh, this library is a library where like if you have a rest a rest a pair of schools Right, probably if you use any sort of rest a library that we use testify In our packet it it will probably they pick some kind of db on the deep active it probably it may happen That it has some foreign key references and the state is nested, right? We use normalize library on top of every rest a pair to make as much light as is possible, right? We use that and then we try to extend pure components over components, right? Pure component what it does, right? If you see should component update, right? So pure component what it does whenever the state changes, right? It does a shallow rendering check, right? shallow depth check It doesn't go deep enough to find out if both your states are same Instead it just overlooks and see if your primary set of keys are same and then if it's same then It's like no, I don't want it to render it again If it's deep enough you If your slave states on a flat and if you use pure component to run into a problem many problems I because it's just a shallow shallow depth check of your object and then find out whether it should be rendered a component or not So this flat states and pure component works together. Uh, uh, it gives us a good amount of performance improvement I Didn't show the numbers here, but it actually gave us five to six percent of performance improvement over how each component reenders, right? Who is vanilla flux, right? When we are, you know Started with our migrating output to this react. We didn't use any sort of state library, right? It was all about props, uh child parent hierarchy, right? Parent will pass props be it function be it data and then Child will work accordingly if it needs to act, uh, like we want to talk about two between two siblings the Callers always via the parent. Uh, one child will ask the parent, you know I want the other sibling to do something we are doing like that But you found out it was not so maintainable and then obviously if you start building a new features It would become very difficult for us. So you started looking out for uh, supporting libraries, right? The first thing that came to us was redux And the one thing that uh on redux it was most popular in 99 9s of code and it's just small, right? This was the most uh talked about thing about redux. Uh, it's a 99 lines of code and you can just Make it work in your application. It will start working. Okay, but we saw redux is a very deep learning curve, right? And we were not so familiar, uh, not not so comfortable with the one state, uh, architecture Uh, we wanted to have separate uh separation of concerns, right? My user store should only uh, think about what the user data is there, right? We should not bother about how the user is interacting with some kind of payment space, right? My user data should only talk about how the user data is related. What is the email writing also does it? So the very very lucky given this rich feature Obviously the flood architecture works best. Secondly, we saw that uh Almost all of our actions have been as I said before, right? While the STPF calls, right? So if you are going to go with redux, right? We had to use any uh middle words, right? It was thump at that time was most popular. So we saw that anyway, it is a nice inference call We are not getting much of benefit out of the pure reducer function. We just gives a Initial call back at the very beginning of the action So you went to add with Benelux and till now we are Benelux company. We don't use redux We are quite happy that we have made the choice and it actually has improved the performance I'm not so sure if you're using redux, not the correct way But the same application which is built-in redux and flux we could see 10 to 15 percent of performance improvement on flux as well as flux gives you a very uh good feature Called us how many events you can have in an application, right? You can number the limit of death, right? You can say I should not go beyond 100 of events uh in my application and it would actually give you a warning Well, you know built and then know you have crossed 100 events at an application. So it was very good for us This link uh lead to us create our very own starter kit, right? Obviously create reactance create uh when you start up But then we we thought that no whatever learnings we have and what works best for us Why not create our own starter kit, right? So it's uh we created our own starter kit, right? It gave us few uh things, right? It made sure that whatever you learned for the last 12 half years, right? The best practices are the libraries and the stack we could put together in a one single package.json And then it was it would start working for all of our projects at very simple good, right? If my flux is there ARB and BES links are there when the configuration is there Like you can just include zz and all sort of stuff at the initial goal itself and go Again it gave gave us defined ad structure, right? Because we were creating multiple ads at same point of time It was very easy for us to create the same aircraft structure And then different depth can work on different projects simultaneously because the architects have looked at us the same Obviously we created proven links which works best for us, right? We are error function supporter and all sort of things it works best for us And the best thing we found in our own starter kit is the build process, right? We use Jenkins uh As a build automation tool in our company We are heavily using Jenkins for our backend apps, but we could not use our frontend But with this own starter kit we created our own build script, right? Whenever you put something in your developer Uh a new code, right? It will start Right? Testing your application we will just and stumble Start testing your application if it's if it's done it will start creating your bundle if it's done It will obviously gz after all the stuff it will put in your s3 like we use AWS For our all our s3 storage all up So it actually put an s3 so this was a very good win for us, right? Previously we used to see uh like collaborate with different teams to find out whether your code is fine to go Okay, my code is fine to go. Let's put together. Let's release this made our life very simple, right? The simple build process has improved our productivity I guess like 100 percent This starter kit, right? We thought that you know we found out that you should keep up frontend application very simple, right? I don't want to Sound very hard from this, but it's very true that frontend is very polluted, right? For anything and everything you have hundred of libraries even though almost all of them work the similar way or other way Right, so we wanted to make it very simple, right? So this is a few things that we learned over the past few years Don't use it if you don't need it, right for the last for the first one one-half month of our React application that we didn't need any returns or flux any sort of architecture, right? In fact now also we have fewer apps doesn't use any returns or flux or make the react route or any sort of routing algorithm Because it just it doesn't make sense. We don't need to just don't use it Uh choose extensively over the ease of building, right? You may just import a library You just give the simple function, but then if you want to add on some picture to it Just you're just up you don't know how to do it, right? And that's why if you can do it just do it don't lend it, right? Like I don't remember the library name by just left bad or something like that We just opted out from mpm and all people and all started false. It is 11 piece of line of code Do you don't you think that could have just done it by ourselves, right? I did this somewhere of like I think uh yesterday I was traveling by the train I had this somewhere like no one out here this frontend is the future and I believe it is uh because most of our Like user base that you see are very concerned about how the yi or ux looks, right? So yi is something that you know, how how you know talk to your customer all sort of stuff, right? So you saw that frontend is the future and we are Think that it is true and some sort of other ways of basically coming through And if that is true, then we feel that react is the first fast forward to it, right? It won't have yet back react who was something else only like if you consider now view and all of the like this come up Well, it won't appear back when it started react. It was some other level of confidence or some other level of API That you could see and it was it was something of other level, right? Yeah, that's that's about it