I'm Tommy Kay, head micro frontends department at Leaky and Frontend house and podcaster known from micro frontend house series on micro frontend house channels. Im going to take you into the journey through the world of the micro frontends. Let's start with the agenda. We are going to speak about software architecture. Monolith approach, distributed approaches, micro frontends. What? Why my winit. And at the end, we will quickly summarize everything what I was talking about. Are you ready? So let's do this. The software architecture is about the whole system. Fundamental organization, which includes components, relations between them, infrastructure, environment and set of rules and design patterns used to manage the system. Right. It gives the directions to the development teams of how to build, scale and maintain the whole system and make it meet the business expectations. Such set of the principles and tooling makes the required work more predictable and efficient as all of the team members know. Why, what and how? One of the examples from the software architecture area is a wellknown monolith approach. It issues that all of the requirements, solutions, functionalities and data are encapsulated under a single application. I believe most of us worked with applications like that. And good example are rabionrails apps. Okay, so basically rabionrails app encapsulate the frontend layer, the backend layer, the database layer, and it's everything closed under the single solution, right? Okay, cool. So let's discuss the pros and cons of the monolith approach. It encapsulates all the problems and solution under the single application. On complexity growth, it's hard to scale. Security of data storing and communication is much easier. It has a reduced palette of used technologies, lack of modularity and easy to start development. The other type of the architecture area is a distributed approach. Let's take a closer look on that. Okay, so let's assume we have a couple of different functionalities and integrations to cover. We can build a single backend application, the monolith one, or we can split the monolith into separate microservices. Each of the microservices will be responsible for the particular functionality like payments, authorization, payment, treatment process and stuff like that. To make the communication easier, we can connect all the dots under the communication hub. Let's call it gateway. The good example is Graphql federation that is mostly based off the distributed approach. The process conf 42 distributed architecture is high performance under a big traffic and it's really easy to scale. Increased response time depends on the number of the nodes to process the request. High complexity at the beginning of implementation. White palette of available technologies, hard to debug and analyze and hard to pros security for the whole system. Does it make sense? So let's move forward. Now it's the time to introduce the micro frontends. What are the micro frontend house? Mostly they are the adaptation of the distributed architecture for the web applications. Right? So the assumption is still the same. Create the small micro apps that resolve the particular problem, expose each of the solutions and use them wherever needed. One of the main wins is the really great modularisation and technology agnostic attempt as each of the module can be realized with the different technology and with the different teams. As we can see on the diagram, instead of creating the monolith app that would include all of the modules within its source, we did create a separately micro apps like schedule, video, call, user profile and notifications. Cool. So those apps are used inside the shell app and the shell app is basically our API gateway that I have presented in the distributed approach definition. Right? Cool. So the shell app connect all of our micro apps and expose the single entry two the end user. From the user perspective it will be just the single app. But under the hood there would be the combination of smaller blocks that are composed to get the main app. Each of the module can integrate with the microservices directly or indirectly, or with some single API or with any data source, any data provider we want to include inside our architecture, inside our platform. The shell app also can integrate with the data providers and then expose this data to the micro apps. Depends on the case. Let's take a look at more advanced usage. One of the options is to choose the distributed approach on both front end and backend. And yeah, you're probably right, it might look complex and certainly it is. It fits well when there are a lot of different functionalities, modules, views, widgets and business logic to be covered and scalability is one of the key requirements. We can easily add or remove modules and compose new apps within existing modules. Or add new modules. Two. Compose the new apps. Yeah, there are plenty of use cases and there are plenty of things that we can do with the microapps approach. What are the pros and cons for the micro frontends architecture? Each module is a separate self contained app with on ecosystem. The key is to provide the good communication between apps. Modularization makes it easy to scale. Shell apps is responsible for integrating all the apps. Each micro frontend has own API integration. Independent development teams can collaborate on the front end app easily performance optimization opportunities. As we saw on the diagram, creating the micro frontends architecture is complex and it may be hard to set up and start implementation. We can use one of the popular micro frontends frameworks like big single spa webpack five and module federation open components, et cetera, et cetera. There are a bunch of different tools that covers the micro frontends architecture and the micro frontends boilerplate. Two, let us start implementation much faster. Personally I did use bit and it makes the whole job perfect and I recommend to take a look on their documentation and also take a look into their tutorials like they explain everything, everything how to deal with the micro front end within your favorite technologies. Mostly I was working with the react and this tool makes the whole job and it was really really easy for me to implement a different app and connect them under the shell app. So yeah, I highly recommend to take a look and enjoy. But yeah, let's move forward now, it's time two, answer the question why we might need that. The huge plus is that the separate development teams can work on different areas of our platform, each specialized in a different technology. For the company, it means that the project teams can be composed of the mixed skills developers and help to better allocate the resources and employees. So for example, one of the team that specializes in the react can work on the schedule app that is realized with the react. The angular team can focus on the video call app and someone who is perfect in vanilla js can work on the Shell app with just compose all of our apps right? Another use case where the micro front end might be helpful is where there is a need to migrate from one technology to the another. Instead of doing a revolution and rewrite the apps from the scratch, the development teams can adopt the distributed approach and switch for example from angular to react step by step. So following the rule, make an evolution, not a revolution. It makes the whole migration easier and more predictable. And what's more important, teams can experiment with the product by exploring different technologies and solutions and pick the best one without rewriting the whole app, which as an outcome saves time and money. One of the benefits, thanks to the micro frontends'architecture is that we can easily compose the new apps by reuse of the currently existing modules or adding a new one. The same video call app can be reused in the patient or doctor app or in ambulance driver app, but the key is to expose the right communication interface to be able to inject the data and expose other handrails to lets us integrate with this micro app much easier. Now, let's assume that your client knows that he wants to build three different apps, but based on the similar branding and similar UI, right? So instead of creating the presentation layer for each of the apps, we can extract the reusable blocks and create a reusable package that can be utilized within our apps. Okay, we can add storybook or any other tool that you like to use to document our components library. And as an outcome, we receive a good foundation for something that's called design system. With the micro frontend, House can easily put all things into the order and manage the whole infrastructure in cleaner and more understandable way. We discussed the theory for the micro frontend. House discussed some examples, but as you can see in the presentation, some big players also trust in the micro frontends architecture. So those players are like Zalando, Microsoft, Leroamerlem, Starbucks. And I believe it's also worth for you to check it on your own. Choose the technology with the surgical precision. With the micro frontends architecture, you can easily build scalable apps that are composed from the independent modules. Pick the technology that responds to the business problem and gives the most optimized result. So that's it. Thank you for your attention. I hope that you have enjoyed the whole show and the knowledge I have shared with you will be useful and and see you next time. Bye.