Uh, my name is Pasupuleti. And today I'm going to talk about harnessing micro fringes for building scalable, reliable and secure application. In today's fast paced digital environment building scalable, reliable, and secure platforms for complex work applications is crucial. And as these applications continue to grow in complexity, traditional monolithic architectures often struggle to keep up, leading to slower development cycles. scalability challenges, and a higher risk of system wide failures. Microfrontends, to this topic, offers a solution to this problem by breaking down these monolithic applications into spawner self contained units, with each unit having its own independent life cycle. This modular approach not only simplifies the development and maintenance, but also enhances the scalability of the system. Enabling teams to work on more autonomously and efficiently. Today we'll deep dive into these micro frontends, where we'll understand this core principles, exploring their advantages, and discovering how they will empower us to build a scalable, reliable, and maintainable web applications. Next slide. Firstly, let's start about start with what are the challenges of the existing web applications with monolithic architecture that are out there. If you see on this slide, on the right hand side, you'll see a monolithic architecture based application where you have the frontend layer, the web application layer, and the integration layer, which is typically your GraphQL layer, and the service layer, typically your Node. js. Java, Springboard application or any Python or Rust based application that's out there. In a monolithic application, what happens is all these three layers are combined into one particular application and are distributed and scaled and deployed across. at this picture, let's try to understand the limitations of this traditional monolithic architecture. Particularly, as these kind of applications continue to grow in complexity, And the challenges that we highlight below will show why we need to move towards Microfrontends. Why is it necessary? So the first one is tightly coupled code bases and scaling issues In monolithic architecture, the front end, back end, and the integration layers are often interwoven into one single codebase. This tight coupling makes it difficult to scale the individual components. For example, if the back end API layer, for example, here, the Node. js or the Spring Boot application, if you start to see more application load towards the back end, because there are more number of requests, or there is more complex logic that the server needs to do, you We'll have to, what you typically do is you deploy more instances of this application. But in this case, you can't deploy just the backend API layer independently. You will have to deploy the entire application because there's no other ways. This approach is inefficient, not just inefficient, but it also is risky as it introduces unnecessary complexity and the potential points of failure. During deployment. The second issue with this monolithic architecture is the slow development and the deployment cycles. For example, imagine this case that you're onboarding a new team member for him or her, the understanding of monolithic system can be daunting because they need to get a complete grasp of the entire application before they start contributing effectively with slow Here, productivity also breaks down the team's velocity. Additionally, the complex nature of the codebase means that changes in one area, for example, in the UI layer, often requires comprehensive testing across the entire application. For instance, let's say you want to deploy a small UI update. You can't do it in isolation. You'll have to test the entire application from print and grab the integration layer in the backend layer before you go ahead and deploy. So this delays the time to market for any feature. The third main issue with monolithic architecture is the cascading failures. For example, in a monolithic architecture, a small change or a small bug in one part of the application can cause unexpected issues elsewhere. For example, if you If there is a minor bug in the authentication module, there is a very good chance it could affect the user dashboard somewhere else. So this leads to cascading often gets very difficult to find out where exactly is the root cause for this problem. And the lack of modularity increases this wide risk of system outages and makes troubleshooting often difficult. The next main issue with monolithic architecture is the lack of flexibility of technology. So what happens with monolithic architecture is you often lock yourself into this specified technologies or framework across the application. And this can be limiting because, for example, let's say for part of your application, you want to use a different technology or a different version of a given library, that gets very difficult. Because you are like tied up to given technology framework and version across the app. in this architecture. The next one more issue that you tend to see in this architecture is team coordination challenges. So as team continues to grow, coordinating development between different teams, like within the team, this monolithic architecture becomes very difficult. Teams working on different features usually often step on Each of the stores leading to much complex bottlenecks and CICD pipelines, and then overall a slow progress. This lack of ownership and modularity can hinder a team's autonomy and reduce the developer velocity. So based on these challenges, it's clear that we need a more modular and flexible and scalable approach to build modern web applications. Like a for instance, comes to the rescue. Microfinance address these issues by enabling teams to develop, test and deploy independent front end modules, leading to faster delivery, reduced risk and enhanced scalability. On to the next slide, the power of microfinance. So microfinance are a game changer. When it comes to building scalable, reliable, and maintainable web applications, their effectiveness lies in a core set of principles that define how we approach the modern development. If you see, for example, in the picture over there at the right, the same monolithic application that you have seen in the previous slide can be broken down into three different applications. For example, let's see. Let's take the example of, say, Amazon, which is again Amazon. Uses micro front ends in its application, so there could be an independent instead of the entire Amazon application being built as one big application and deploying it. They do is like just the cart experience that you see is a separate team. They might use react on the front end and they might use Java at the back. Similarly, the main page, the amazon. com web page that you see. There could be a different team that could be working on it. And similarly, the payment team. Similarly, search is being, like, that's another thing that's working out of there. micro frontends, what happens is this gives teams to work on different parts of the application independently and deploy and make changes over there. micro frontends, what you get? You get independent scalability and deployability. One of the greatest strengths of micro frontends is their, like I was saying, the ability to operate independently. Wherein, each micro frontend can be developed, tested, and deployed separately. Allow teams to, release new features without impacting others applications. It seems how it feels, it seems like a very well choreographed dance where each team moves in sync with other without stepping on each other's toes, resulting in a faster, smoother, and more frequent deployments across. Secondly, one more thing in microfrontends are smaller codebases for faster development. So, to be breaking down of this huge monolithic application into smaller manageable pieces, microfrontends reduce the complexity of the overall codebase. This approach enables us for faster development, as teams can focus only on their specific microfrontend without team needing to understand or test the overall system. for making a deployment. This means that you can ship newer features very fast and improve the significant time to market, time to sync, eventually improve. The next thing is the, the advantage for micro front end is the resilience and fault tolerance. One of the core features that micro front end offers is complete decoupling. So basically, by decoupling different parts of the application, Microfront can inherently build this resilience and fault tolerance. If one component fails, let's say your cart fails or your search fails, it doesn't bring down the entire Amazon. com website. Let's say your payment is having some issue, you can still browse for the product, you can still add products to the cart, whereas you might not be able to check out, but all the other functionalities will go through. And, uh, this reducing the system risk of the overall total system downtime and enhances the overall system robustness technology agnosticism. Like I'm saying previously, with Microshinton, the individual teams can choose the best tool for their job. like Amazon homepage might think, oh, there's just too many re renders and everything that's happening on my web page, let me use React. Whereas probably. The payment team might think, hey, okay, for my application, what I'm trying to do, I can, I would rather use Vue. js. So this technology agnostic approach allows teams to leverage their expertise or even it also depends on the team composition. Let's say, most of the team members on the particular project or the team knows Vue. js more than React. js or even Angular. js and they could go ahead and build that particular application in the technology by choice or they're most comfortable with. There's no Tying up of like you have to use only this particular technology, this particular version, etcetera. Next thing is finally gives you scalability at every level. It's not just at the application. It gives scalability across the entire process. So microfinance does not offer scalability, not in terms of technology, but also in terms of team structure. For example, as your application team grows. You can scale your teams, each focusing on different micro front ends without risking of creating this monolithic. What will add? This distributed approach of development allows your organization to grow more organically, accommodating larger teams and building more complex applications without sacrificing the performance or the agility that you get in smaller teams. Next slide. So what do we need to keep in mind when developing this microfrontend? What are the best practices? What are the architecture patterns? And what are the challenges that you usually see or have to keep in mind when building such microfrontend applications? So the first choice you tend to make is do you want to split your monolithic application either vertically or horizontally? So what I mean by vertically is, for example, Let's say in the example of, Amazon itself, let's say breaking it now, like for example, let's say any e-commerce website, so for example, maybe it shows you a list of products that they have. One page. One page like allows you to check out which contains the card, and the third thing manages the payment. One way. Splitting it vertically would mean that you would, the entire homepage will be owned by one team the entire. Card page will be owned by one team, the entire payment team will open. So they'll own both their front end and their back end services. Horizontal splitting would be, for example, would be like, a team will own the entire UI, a team will own the entire API. But typically, the vertical splitting is more common. you see more often across the industry, let's say, at IKEA or Spotify, where individual teams will maintain both their front end UI layer and the back end layer for part, part of the functionality. Amazon. com, the home page will be on both the UI and API workability. The carting UI and API will be owned by one team and the payment UI and API will be owned by one team. So that's like vertical splitting. That's more, that's an architecture pattern or how they've chosen it. Similarly, you also have to like, keep in mind that you need to establish clear communication and contract boundaries. Ensure well defined APIs. for communication between micro friend trends and this avoid state coupling between them. This also allows to iterate independently as long as they adhere to this con contracts. So one, the challenge that is there in Micro friend is caused microfinance communication and status. So previous need thought, the entire application is one application. In monolithic application, the entire application is one. So it's easier for components, one component to talk to each other, the others, the other and all that. Now, since with micro frontends, all of them are separate, are separated, are different applications. You need to be careful or be cognizant of the fact that it's not pretty straightforward how the components can talk to each other. So that's why we need to use well defined API and use event driven architectures to manage the interaction between these microfrontends. I would say probably look up tools like, let's say, Event Puzzles, Global State Managers, or even like top tier microspack and microservice to help this communication between these two, these microfrontends. Another challenge or thing to keep in mind is maintain consistency of user experience. so because there are different teams working on different parts of the UI, you also need to make sure you also want to make sure that all these experiences that we are building are cohesive and they all feel like they belong to the same web application, the same page. So an idea how we could solve this problem is You need to establish a comprehensive design system and enforce UI UX guidelines across all the micro front end applications that you're building, or even shared library user conference can also help maintain this consistency. So it feels to the user that, okay, although this given web page, like amazon. com is being powered by, let's say, 10 different micro front ends, but it feels like one website to the user. It doesn't feel like, okay. The search doesn't look different. The homepage doesn't look different. The cart based doesn't look different at all. Everything together looks like amazon. com. It does not feel like each of these pages. Each page is different or being built by different, teams. The last one is security consoles. So because now all these applications are being built by different teams and different developers, Ensuring consistent security practices across the entire application is important. So we need to develop a unified strategy that includes secure communication, consistent authentication, and authorization practices. And each of these micro frontends should adhere to the same security standards to avoid any vulnerability across the slides. Finally, in summary, what are these micro frontends? micro frontends help down, break down large monolithic web applications into smaller independent users, allowing for modularity and scalability. what are its key benefits? Main benefits are independent scalability. Teams can develop, test and deploy these micro frontends independently, leading to faster release cycles and better scalability. Faster deployment cycles, because now that you have smaller code base, results in quicker development and deployment cycles, enabling rapid future updates. Reliability. in one micro frontend, like I was saying, will not affect the entire application, enhancing the overall system reliability and security. Technology agnosticism. teams can use different technologies for different micro frontends, promoting flexibility and innovation. Teams can work in technologies that they're most comfortable in and they're stronger. So what are the best practices and challenges that you need to keep in mind while designing this application are, you need to choose the right architecture pattern. Like I was saying, you either choose the vertical splits or the horizontal, how you, or the horizontal splits. So how you want to break down your overall monolithic application into parts. So you also need to establish this clear communication, where to define the CPI contracts and maintain it. The shared libraries for all the applications to use ensure consistency. That's a huge thing because For the customer or the user, whoever is coming to our web page, we need to make sure that they don't get a feed that they call for the kind of given page. It looks like four different web applications are stitched together on one page and they feel or look or work differently. So that should not happen. Few real world examples of like really huge companies that have embraced this methodology and are using as of today, for example, a few of them could be Spotify, Amazon, I key, tens of a few examples that are out there that have been using and I've been spearheading, this technology. So what are my final thoughts? So micro front ends offer a powerful approach to building scalable. maintainable web applications, but require careful planning and execution. Embrace the modularity, leverage the best practices, and address the challenges proactively to maximize the benefits of microfrontends. Thank you all. Thank you so much for taking the time to join me today to go over this microfrontend based architecture based presentation. Thank you all.