 Hello everyone. So it's great to be here because my first talk was regarding the micro front end architecture and I'm here to talk about monolithic. So it's a kind of 180 degree flip. Okay. So thank you. Thank you, Nidhi, for being here. So how many of you are working on monolithic architecture or the project which are having some legacy code and dependency? Ah, it's great. Okay. So talk is not a problem for me. The problem is that my talk is before the lunch. Okay. So I can imagine most of the people are thinking about Dal, Tadka and all those stuff. So please relax. I will not take more than 40 minutes. Okay. So what is monolithic architecture? And the tagline that we are having is new react child in daddy's code because most of the time, the engineers which are in 20s or 19s, 18s ages, the code that they are writing is somehow coming from 95, 98, 99. So that time might be people like daddy who are writing that code CC plus plus. But right now we are talking about, okay, we need to write react might be some people say that angular view JavaScript. So it's a complete change of generation, not in terms of heridity, but in terms of core legacy also. So let's start this journey. Okay. One more disclaimer. So please don't be set like an ideal people. You can shout like once more, once more. I can acknowledge that. Okay. So what's the requirement for doing all the stuff? The first thing is that the complex structure of the existing code base we are having. So a hell lot of files, a lot of folders, and it's very complex. Even to understand, forget about writing a code. The number two is no reusable code because when we talk about monolithic architecture, reusability is something which comes at a trade off decision because if you are trying to reuse a code, you need to think of a separate build structure folder structure and all those stuffs. And the third and the most important is to prone to break unexpected area because right now we are having all those test driven development. But when we talk about five years back or 10 years back, you are not aware about that. You are changing a single line of code. How this will going to impact your code. So that is the problem we are having. So it's the objective of my presentation that I will be covering how we can integrate with the existing code. So whatever I am proposing in terms of react, how we can integrate react, how we can integrate react with the existing project, how we can do handshake between the two separate projects because two project working on two different planet, how we can make a handshake between all those two. How we can integrate the code with fallback strategy. Most of the time when you guys are creating a new project, because company says that either do a revamping of the project or either create a separate project with a fallback. So fallback is again a key criteria over here that we will be discussing. So this is the current ecosystem. So if you can see that python, c-sharp, c++, java.net and javascript plus typescript and here and there, Ruby and go, all those different languages are there and the projects are mostly based on these languages. So how these languages will adopt react as a child. So that is something interesting that we will be talking about. So what are the challenges? We say that while integrating react, what are the challenges we will be having? So tightly coupled architecture like c-sharp and java, all those languages having tightly coupled. So it's very difficult to push any third party code or you can say that separate code into the existing code base. Then monolithic project structure because the structure of the monolithic says that you are not dealing with changing your DLL packages and all those stuff, especially the folder structure, whatever the project that you are having, you are not allowed to include a separate package. And the build process because separate languages are having different build process. Some use nugget, some use mevan and they have their own different process. But when we talk about javascript and all those things, we do have react, webpack, gult, grunt and all those stuffs. These are the some known product. So Microsoft Word, Microsoft Powerpoint, Outlook and some old CMS. So I can relate that when I was in college, I used to write the MS Word. That time I think react was not there and MSPPT also. So a snapshot of the existing project in Microsoft, this is a Word web online we are talking about and the same for PPPT also. So now let's talk about solution, what we are proposing and how we can achieve that. The first point is you need to create a react application. I will not talk about how you can create the scalable and the best react application because you guys already know. So the first point is separate react application which is working in a separate zone. The second point is webpack building. Again, advantage of webpack building I am suggesting is that you can do a code split and you can also manage your asset at your own. Because when you talk about your asset management like image and all those things, you can always put a check that if the image is not heavy, then do a base 64, otherwise call it from a domain or a CDN. Then a separate build process so that we are not saying that we are having a dependency on the existing build process. We are having a separate build process so that we can do whatever we want to do with a react application. So this is the design pattern we are suggesting and binding agent for us. So in day to day life we are following this practice when we talk about when a person visits to a restaurant and says that waiter give me some butter chicken and plus two tandoori roti. Now this is the command. We are giving a command to the waiter. The waiter doesn't do anything but what waiter is doing, waiter is passing the command to the kitchen. Kitchen says that there is a mapping between the command. Yellow dal, roti says that tandoori roti and he starts preparing all those things. Once the command is being executed, he again gives the same thing to the waiter say that serve. Now this thing act as a callback for us. So it's a general pattern when we talk about we are giving a command to a single person and the person is acknowledging that command. So why command pattern is useful? When you people need to cater the request of history, then it is useful because always you will be having logs and history request. Callback functionality as I told you, once the waiter is delivering food on your table, it's a callback. Request needed to be handled at a various times. Most of the time you observe that there is a separate boiler plate or you can say that separate process. First one is a waiter, second one is a manager and now you will be having all those digital devices where the person needs to be entered, your order in your system. And the last one is invoker should be decoupled so that every single person is working as a standalone process. No one is dependent upon the previous one or the later one so that we are not having any coupling regarding the process. So this is a structure of command pattern. The first one is a receiver, receiver actions via command. So that is a waiter which receives the command. The another one is a command that is a skeleton in the fundamental we are having which binds an action to a receiver because command is Maidal. And the third one is an invoker which invokes. Invoker is nothing, you can say that kitchen over here which handles the command and do a callback whenever they are executed. And lastly we do have client. Client manages interaction between receiver and invoker. A very uber level flow diagram we are having where initially we do have a client. Client is interacting with the invoker and client is also interacting with the receiver because client can have access of both the things. And once the invoker is having a data then we do have a command pattern over here. The command pattern says that whatever the set of commands you are having it will manage all those commands and give a concrete result against that particular command. Say that it's a sort of config management we are having for command. So let's take an example of Microsoft Word we are having. So whatever the flow diagram that I showed you, let's try to put in a real-world environment. I do have an existing project and I do have a React app because we recently created a wonderful React app. First talk about the existing project. We do have a command pattern class file. Once the class file is there we are compiling that class file into a JavaScript. If you guys are using C sharp and all those things there is a compiler which are there. You can simply compile your file to a JavaScript and then export that JavaScript under a namespace. So you are done with that. Now you have all those command pattern and they are all exported. Now talk about the React application. So whatever you have exported as a namespace you are inheriting those names as a handshake.js. You can change the name. So once the handshake.js is there they have the listeners which listens the command and binding with the project. So flow goes like CP is giving JavaScript and JavaScript is resulting in handshake.js and handshake.js is having listeners and binding with the React application. So any command which is flowing from the existing project will be acknowledged by this binding project. Suppose when I say show alert automatically binding says that we need to show the alert. It's time to show the alert. So creating new application is not the whole idea. We also need to modify the existing project. So first thing we need to do is that as I told you expose a command pattern. Expose properties to the action manager because when we talk about the React application props needs to be flow from unidirectional top to bottom and our top is the legacy code we are having. Pass all existing component as a fallback because when we are talking about we will be creating a new React application. I'm not saying that throw away the existing code. No, because that is a goal just for you because in today's context whenever you are trying to revamp your application. You always need to have a fallback strategy from this pattern. We can say that things are working for me fine. But I want to modify in somehow due to some problem might be in i6, i7 or some other browser related problem. We can fall back our existing code so that if somehow React will not able to render the user will not be blocked. Again some more modification expose common JS. Now create a factory pattern. So again this is the best practices where you have created a factory pattern. That factory pattern will collaborate with your React application. You will not directly calling that React application method. You need to create a pattern which will be integrated like you can say that UI surface is a factory pattern we have created. Keep the code under flight which talks about we need to render the component or not. Again you need to maintain a flight which says that this is the time to render the React component or this is not the time to render the non-react component. Just like AB testing we used to do. You can easily switch on and switch off your new application. So what are the challenges that we will be facing while doing the migration? The first one is automation because whenever you are having automation suits and testing it is very difficult to test two separate application into different zones. So that is the biggest problem we are having. Then config management as I talk about the command pattern so we also need to maintain that whatever the commands we are sharing needs to be same. The other one is debugging because while development the problem people a developer used to face that I am getting this error but I am not sure where I will be getting this line of code. Either it is in the new project or either it is in the old one. And the last and the important one is the consistency. You always need to thought of is it consistent enough so that we can push it because you are always benchmarking with your existing project that is running in the market. So a sample code we are having so this is a JavaScript command pattern just like a task executor we are having where you will be having a task list and a executor. User can simply push the command in the command handler and once the command has been there it will start executing this. This is a C sharp way of implementing command pattern where you will be having a class which is a modify and another public class which is a set command. Where you can simply set the command and start executing. So this is very basic example we are having for calculator just like a calculator we are using in a day to day life where you can see that plus two plus five minus five. It's nothing it's the command we are passing to the calculator which says that if you see over here I am saying that calculator dot execute new command hundred new then subtract command multiple command divide command. End number of command without even thinking that how it will handle because I'm sure react is having a asynchronous it will handle everything as asynchronous way so it will not going to hamper or block my existing UI. If I see over here the code so this is a task executor I have created and some small command which is add subtract and a base class which is a command. So when I run this it says that the first command was add hundred subtract 24 multiply six then I say undo two which says that river the existing command because it's very pretty much common that you gave the wrong command and undo multiply six. Now the resultant in 76 here we are not calculating every single time the command is executing we are checking that is the set of command is being received or not. If there is a you can say that debouncing kind of mechanism we have implemented with talks about OK now I have the time to execute all those command now then only I am executing this. So as I told you build process is very crucial over here so we are doing a benchmarking the first one is a react application another one is a existing project so for react application we are saying that export build packet under a new get. So I'm taking reference of C sharp that's why I'm saying you get new get is nothing it's a shareable folder we are having while doing a build then you can create chunks which can be injected on demand that we can achieve with the help of webpack code splitting. Then you need to create a sim link to the existing project because importance of sim link is that every time you do not need to import your code into the existing project because your project is taking a reference of this link and then that link is existing as a sim link. If you are done with your react application automatically your JavaScript has been injected without even required a build process or a code deployment when we talk about the existing project again so it goes like you are exporting in react we are reading in from new get slice the file while building so whatever the JavaScript we have created we need to inject the JavaScript in our existing folder and then fetch the react project while building. So whatever the dependencies that we are having that factory pattern that we'll be using we need to fetch each and every dependency from the react pattern that we have exposed from here. So again a very level of flow diagram we are having where we do have a react application and that is associated with the cloud build and once the build is been succeeded we are passing that folder to the blob blob or S3 you can take reference. And now when we talk about the existing project then we do have a old project over there and that old project is having a separate build system and that build system is taking reference to the naked so nugget is nothing again a shareable code base shareable. Folder we are having which is having access to the react folder and access to this old one build process and whatever we are doing is that we are clubbing the both of the data over here and passing to the client. So what we achieved from this thing so earlier I showed you this is word web online this is PowerPoint if you see very closely so headers are same. So it's just a matter of giving some different text file home insert everything is same and the category of drop down font everything is same earlier what we were having we were having two different code bases handling each and everything at their own level. But when we talk about a product which is global then this pattern is pretty much useful because we have achieved the same header for both the product like word and PowerPoint and that is hosted at a separate blob. So once the user is making changing to any header automatically it will start reflecting without even thinking of it will going to impact me here and there. So this is the biggest achievement we have done so far. So when we are saying that we have achieved that much of thing now let's talk about how we can benchmark all those things. So these are the factor we are having so frequency of release is the first one earlier without having these kind of structure we are saying that we need to release once in a week. Now we can say that twice is a week is also acceptable thing because now you do not need to go into that long life cycle because you do have a two separate project and two separate build bug per release again. Earlier it was very few because the regression that was required was on a higher side. Now we can say that we can easily manage one or two bugs in a week because the regression is on a lower side build time again. This is the major criteria we are having the build time was 45 minutes earlier because while building a complete project you are building the client you are building the micro services and you are clubbing both of them and shipping it. Now when we are saying that a client is goes out only we are left with the services. So build time reduced to 10 minutes and we are saying that once we are building we are only building the delta part because when we talk about unit testing and all those things the story book check is not required if you are not testing the client. Again few more metrics as I told you regression error earlier we were having few now we can say that we are not completely goes out with the regression. On some good day we will not be having any regression error but in a week we used to have one or two. Now when we talk about the confidence as I told you people used to build this application says that are we able to launch this or not. Now we are saying that the confidence is on a higher side because when we are saying that we are changing a single line of code by saying that including a single button. Our confidence is very high because we have not even touch the back end code and we are not building that code we are only touching the front end code which is having a fallback of the existing code base. So the confidence goes on a very higher side which says that on any given day we will not be having a blank page or a broken interaction with the user. Now testing again important thing to have. So earlier as I told you everything needs to be tested. Now only the delta part when I say everything if you are making a change in a single HTML line or your CSS file doesn't matter your system will never came to know that you have made a CSS change. It will start processing the complete client again build the back end and ship it to you. But when we right now we are saying that we are only processing the delta part now here the delta is the client. If you are making a change to the client then you are building with the help of a webpack and you do not need to touch your back end part or you can say that the old project you are having because everything has been pushed through a simling. So that's not the only thing we have done and whatever we have achieved is the best to have. So always there is a roadmap we are having. We are saying that the challenges that we are facing is improvement to make it more scalable when we talk about creating a separate react application creating a new project which will handle each and everything. Then that is not something that we require because if we are giving a fallback strategy of our existing code that is something which is not the last target for us. And the another problem we are having is automation because when we need to do automation we need to do a tight check on both of the project. So we guys are working on these two parameters where we can say that how we can make this system more scalable so that we do not need to inject the folder from here to there. And whatever we are doing is more you can say that broadcast it to other project of Microsoft that we are having and plus automation how we can make the automation suit more scalable how we can test each and everything from here to there. And what are the best practices we can definitely inherit. So that was the only thing I wanted to explain that's it. And this is my Twitter handler and LinkedIn. Thank you from my side.