Monolith to Micro-Frontends


Many companies worldwide are considering adopting Micro-Frontends to improve business agility and scale, however, there are many unknowns when it comes to what the migration path looks like in practice. In this talk, I will discuss the steps required to successfully migrate a monolithic React Application into a more modular decoupled frontend architecture.

22 min
21 Oct, 2022


Sign in or register to post your comment.

AI Generated Video Summary

Microfrontends are considered as a solution to the problems of exponential growth, code duplication, and unclear ownership in older applications. Transitioning from a monolith to microfrontends involves decoupling the system and exploring options like a modular monolith. Microfrontends enable independent deployments and runtime composition, but there is a discussion about the alternative of keeping an integrated application composed at runtime. Choosing a composition model and a router are crucial decisions in the technical plan. The Strangler pattern and the reverse Strangler pattern are used to gradually replace parts of the monolith with the new application.

1. Introduction to Microfrontends

Short description:

We're going to talk about how to transform monoliths to micro-frontends. React has been here for a long time and applications that are a bit old now start growing and breaking. The problems are usually about the organization and the complications that come with growth. Exponential growth, duplication of code, and unclear ownership are some of the issues. Microfrontends have been considered as a solution by many people and companies.

So, my name is Ruben and I'm a staff engineer at Postman. And the topic today is cool. We're going to talk about how to transform monoliths to micro-frontends.

Now, this is our React conference, right? Well, React has been here for a long time, right? Next year, React will be how old? Ten years old, right? So, recruiters will probably be like, oh, finally, we're going to be asking for ten years React experience.

React has been here for a long time. If you have applications that are a bit old now. Well, technically, not old, old, but in the long scheme of things of technology, they're probably getting on a bit. And the problem with that is applications get old and they start growing and growing and growing. And what's the problem with growth? Well, it probably starts to break at some point. And we'll probably be experiencing.

Now, if you think, if you've been working with React, think the problems you have right now, you probably will probably have a long session of people just complaining about the issues that you have. But mostly it's not about React itself, it's usually about the organization. It's about how as your company and the application grows, things start getting really more complicated and difficult to scale. So, you start getting things like exponential growth, like you have a lot of lines of code. You have more developers, you know, when you started that project it was only two or three. Now you have many groups of developers, especially for companies that are quite big.

CI takes a long time to complete. We all hate that. We want things to be quick. Duplication of code. There is no clear ownership. Who owns what? Et cetera, et cetera. So, we have a lot of problems. That dependency graph is the worst one. I hate it. Like we have a lot of dependencies and we don't know where they're coming from or what is using what. So, there are a lot of problems. You're probably familiar with this.

So, all of these problems have led a lot of people to think about microfrontends. Shall we use microfrontends to solve this problem? And people and a lot of companies are either implementing microfrontends or are trying to implement microfrontends.

2. Transitioning from Monolith to Microfrontends

Short description:

How do we go from a monolith to microfrontends? The main goal of going from the monolith to micro frontends is to remove coupling and accidental coupling. People want to go to micro frontends, but they don't understand why. If you want to go to a distributed architecture, if you want to solve those problems that you have with scaling a large monolithic application, you need to decouple it first.

And there's only one issue with that. How do we do it? Where do we start? I have this big problem, this monolith, this massive application. How do we go from a monolith to microfrontends?

Okay. But, first, what are microfrontends? This is a joke. I'm not going to be explaining what a microfrontends is. Every single talk about microfrontends starts with that slide. If you're not familiar, you can watch some talks about what they are. I'm going to be focused a bit more on how to go there, rather than what they are. And I can touch on a couple of concepts. But that's the main goal of this... Actually, I'm going to tell you what's the main goal of this presentation. Do you want to know what's the main goal of this presentation? I'm going to make you smart. I'm going to make you look good. When you go to the next meeting, right, if you want to impress everybody in that room, right, I will show you. I will give you the key. Are you ready for the key? Once you're in that meeting, you just have to say, well, I think we need to find an opportunity to decouple these pieces. All right. Immediately. So that will make you sound like the smartest person in that room. So decoupling the pieces, and that's Ryan Florence, by the way. Great quote. That's not me. So coupling is a big problem. And, actually, the biggest than coupling is accidental coupling. That's the worst of all. So the main goal of, well, not this talk, but the main goal of going from the monolith to micro frontends is to remove coupling and accidental coupling. That is the main goal, right? How do we achieve that goal? Well, I will show you in a minute, but the thing I like to say, this is my quote, by the way, I think, so I came up with it. People want to go to micro frontends, but they don't understand why. And this is a really good enough reason. If you want to go to a distributed architecture, if you want to, you know, solve those problems that you have with scaling a large monolithic application, you need to decouple it first, otherwise, you will end up in a, you know, the worst place from when you started.

3. Decoupling and the Modular Monolith

Short description:

Before applying micro frontends, start with decoupling the system. Micro frontends aim to decouple the monolith and make sense of the dependency graph. However, it's important to consider other options and explore the steps in between. One approach is a modular monolith, which helps organize the application within the monolith.

And actually I have a talk about, you know, the risks of adopting micro frontends when you don't really need them. So before we can apply micro frontends, we should start with decoupling the system. And what's coupling? Well, there are many different types of coupling. But if you start noticing that things start changing together, you know, like code that changes together stays together, but if that code stays together, you start getting a lot of intertwined dependencies and things start just being really difficult to deploy independently or to have some sense of what the system is like.

So, before we go to distribute the system, before we go to microphone tense, I think if we make our goal to decouple our codebases, that would be a goal achieved. So, just remember, coupling. So, that's the main goal. The main goal of microphone tense is to decouple the monolith. To try to make sense of that dependency graph, I don't like having that big problem and try to decouple the monolith. There are many ways of achieving that goal of decoupling the monolith. Again, microphone tense is one of them. But, today, I will just challenge you. Please do try all of the other options.

Do not go and say, OK, microphone tense is the solution. There are many solutions. I came up with a graph, like a diagram, which I called the decoupled and distributed spectrum, which is a long place where you can go from one to the next to the next until you solve your problem. I will explain this graph briefly. So, we have the monolith, right? That's where we are right now. Some people have the monolith with backend and frontend still. But let's assume that we don't have that. Let's assume that backend is already split into microservices. We still have the monolith and the frontend application in the monolith. We're struggling because we cannot deploy, it's very difficult, all these problems that we discussed briefly. If I jump straight to micro frontends and I haven't explored all the steps in the middle, I'm just coming to this conclusion which might not be the solution for my problem.

Just remember, one of the main problems is decoupling. How do we decouple? Let's take it step by step. Let's try a modular monolith. This approach is also really good. Some companies are using it. And they have their application a little bit more organised within their monolith.

4. Transitioning to Microfrontends

Short description:

Modular monoliths provide some team ownership and boundaries within a monolithic application, but still have coupling and cannot be deployed independently. Integrated applications offer more flexibility, but are still deployed as a single unit. Microfrontends enable independent deployments and runtime composition, allowing for separate deployments of individual units. However, independent deployments may not always be the best solution, and there is a talk after this one discussing the alternative of keeping an integrated application composed at runtime. Now, let's focus on how to transition from a monolith to microfrontends with an action plan.

It's still a monolith, it's still deployed as one single unit, but they have some team ownership, they have some boundaries, they can make some sense of the application a bit better, and they still have some coupling, so we're still on the coupled scale rather than decoupled scale, but they cannot deploy independently. That is one of the major things with modular monoliths, you have to deploy the entire thing, and you still have a lot of coupling inside, so all the UI and libraries and everything is in there.

But for your company, for your use case, a modular monolith might be perfectly fine and might work and might solve a lot of your problems. So, do check it out if you want to. Take a look at a modular monolith.

And then the next step is, oh, what about integrated applications? Integrated applications are a bit more flexible than a modular monolith. There are many flavors and a lot of monorepo tools try to help you with an integrated application, which is basically you have multiple applications still inside one code base. It could be a monorepo. And they are deployed and composed at build time. So, you cannot deploy independently still. You can still deploy, but once you release the application, this is a key, it gets released as that one single unit still. So, that's the main difference.

Now, finally we have arrived to microfrontends. So, what do you get if you apply microfrontends? If you don't stop at the integrated applications and monorepos. And the key is independent deployments. So, you will have independent deployments and runtime composition with microfrontends, which means that you don't have to deploy that single unit again at once. You can deploy those independent units separately. And that might be what you need. Or it might not be what you need. Correct? So, it might be that independent deployments actually are going to cause a lot of problems. And actually, there is a great talk just right after my talk by my good friend Alex. He's going to talk about exactly that, which is what if we don't go to independent deployments? What if we just keep an integrated application that is just composed of runtime. So, don't miss it. It's after this talk. But, I promised I was going to show you how to go from monolith to microfrontend. We have decided we need microfrontends. We need independent deployments. How do we do it? Right. So, we need an action plan. And this action plan is two things.

5. Technical Plan: Choosing a Composition Model

Short description:

We need a technical and an organizational plan. If you're deploying independently and composing things, you need to find a composition model. For a React single page application, client-side rendering with Webpack modus operation is a good choice. Modus operation allows for flexibility and reversible decisions, avoiding investment in the wrong technology.

We need a technical and an organizational plan. And I'm going to hopefully go through the technical. And at the end, we talk about the organizational.

So, the first thing is, if you're deploying independently and you are composing things, you need to find how you're going to do, you know, how you're going to put everything together. And this is a very common way of splitting microfrontends, which is, you know, vertically by, you know, the route, the router and the URL, or horizontally, like widgets and stuff. But there are many ways of doing this. You can do this at the edge. You can do it server-side. You can do client-side. You need to choose a composition model.

So, let's imagine we have a React application. Just to keep it simple, it's a single page application. It's not server-side rendered. I'm going to choose a composition model based on client-side rendering and I'm going to be using Webpack modus operation, which is a great tool and I'll tell you why I like it. But, basically, we're going to keep it simple. Server-side rendering composition is possible. It's just a bit harder. But, if you have a single page application, React application, and you want to choose a composition model, this is a good one to go for with Webpack modus operation.

I told you why I was going to say why I like modus operation. One major thing and it's very flexible. And one important thing in this journey of monolith microtransparency, you need to make sure you make decisions reversible. That you do the transition gradually. Modus operation allows you to have that flexibility. Because I'm importing an external module using modus operation, and now I'm importing, oh, it's the same slide. Actually, it's not the same slide. I'm importing a local module. If I decide the modus operation is not my thing and it's not working for me, well, it's really easy to switch back to build time composition and loading from MPM rather than from modus operation. So, making decisions that are reversible is very, very important. Because you don't want to go into a journey of, again, going to micro front ends and you realize halfway through that this is not for us. You have invested a lot into our technology and architecture that is going to be probably not very good for you.

6. Choosing a Router for Microfrontends

Short description:

Modus operation allows you to compose React components around time instead of build time. Choosing a router is a crucial decision when transitioning from a monolith to microfrontends. There are three options: a top-level router, a sub-app router, and a micro-frontend router. The top-level router is similar to a normal router, but it has more coupling and requires deploying the shell and new routes. Fine-tuning the coupling is essential in this architecture.

So that's why I like modus operation. Apart from that is to check it out, it's really good. It just allows you to compose your React components around time instead of build time. And it has a lot of features with dependency duplication, shared dependencies.

So, the next step is, right, we need to choose a router. Oh, I've switched back to say router, because root and route sound the same. But we're in London. So a router is the next decision that we have to make. Because the router is the orchestration. What are you going to show on the screen. This is a very important decision when you're moving from monolith to microfontanse. Because how are you going to show one app or the other.

So I have three options for you. The first one is a top level router, which is basically just a normal router. Just think about just react router on your single page application. That's exactly the same. There is no difference. It will be doing all day composition for you. It still acts as a one application and it's basically just react router. Not many difference. The only difference is those applications are loaded around time rather than build time. The benefits, well simple, it's the same what you've been doing so far. So you probably be familiar with it. It's just a normal router. But we have a lot of coupling there. And this is where you need to fine tune how much coupling you're going to tolerate in your new architecture. So the context is shared. It's one react application. You have to deploy the shell to deploy new routes because you have to basically someone has to tell what the routes are. So you have to deploy two things, still does coupling.

7. Distributive Multi-Router

Short description:

For my use case, I like the option of sharing context and deploying my shell application. Another option is the distributive multi-router, where each application has its own router and can deploy its own routes independently. However, this model is very complex and requires communication between routers. Only one router can use the browser history, while the rest use memory history and synchronization methods. Despite the complexity, this model offers a completely decoupled system.

So this one is good. For my use case, I like this one. I don't have a problem with sharing context and deploying my shell application. This works for me. If this doesn't work for you, then there is another option, which is what I call the distributive multi-router. I'm going to be switching back and forth.

So this one, the difference is there is no one router. There are multiple ones. So the top one, React Router, yes, fine. And then all of these ones can be 5, 4 or whatever you want to use there. Every single application will have their own router. And this is great. Each application is its own unit. They can basically deploy their own routes as they wish. They don't have to depend on anybody else to define and deploy new routes. And they're actually individual React apps. They do React on render separately. So they're not sharing anything, or the tree or anything at all. They are absolutely completely independent apps.

The problem I have with this model is it's very complex. I don't know if anybody has done in production. I know there are a lot of material out there. It's very complex. You need to communicate between the routers. Only one router is allowed to use the browser history. The rest will have to do memory history and synchronization method. It's very complex. But you get absolutely 100% decoupled system. So if you are looking for absolutely 100% there is not coupling at all, not even the React instances that are shared, then this is probably a model that you might consider. But that is also a couple of caveats.

8. React Router and Shared Context

Short description:

If I want some features from React router 6, which are great, by the way, they won't work because there is no shared context. For my main application, I have a router that is just a normal React router, single sharing context and I control it. But there is an application outside of this context that needs to be completely separate. You can mix them, but there is certain coupling on some of the parts here.

If I want some features from React router 6, which are great, by the way, they won't work because there is no shared context. And the final one, the one I have chosen for this architecture is, okay, what about a mix of both? For my main application I have a router that is just a normal React router, single sharing context and I control it. But there is an application outside of this context that needs to be completely separate. There is another team. The company acquired a new startup and they are coming on board, they can use a separate router. You can mix them. You still have some benefits, same as the first one. It is future proof. If React router goes away, just change it. Backward compatible. You can use React router 3, 4, and React router 6 or if you are into multiple frameworks, which you know I'm not very fan of. But this is complex. Communication is still hard. And there is certain coupling on some of the parts here.

9. Strangler and Reverse Strangler Patterns

Short description:

We can't do a big bang migration, so we'll use the Strangler pattern or the reverse Strangler pattern. The Strangler pattern involves gradually replacing parts of the monolith with the new application. The reverse Strangler pattern involves putting all the monolith code into the new application and gradually removing legacy code. Micro front-ends aim to solve organizational issues, not just technical ones.

Why don't you go quick. Right. So what is the strategy? How are we going to achieve this? Now, the only thing that is guaranteed in a big bang rewrite is a big bang. So we can't do a big bang migration. And if you are trying to do a big bang migration, consider your choices. I don't recommend it.

How are we going to avoid the big bang migration? Okay. We are going to use a really common pattern. It's called the Strangler pattern. I have talked about this before. It's basically your monolith will start loading little bits of the application, the new application, which are in blue here, until you replace them all. And this works. I like the Strangler pattern. It's great. You can even do widgets, like you just have in this URL that finance calculator is fine. It's just a new application. But today I will show you just a different approach. The Strangler pattern is great. You know why it's great? Much better. Well, maybe not much better, but an option is the reverse Strangler pattern, where I'm going to put all of the code that is in the monolith, all the stuff that is in there into my new, shiny application. And I'm going to start doing something what I call shrinking the monolith, which is basically start taking those pieces of legacy code and then removing them, converting them into a brand-new application. So this is what we're going to do. This is my option for this monolithic 2.0 front-end recommendation, reversing the shrinking the monolith.

I told you there were two parts. You know, the technical part, which I briefly discussed, and then the organizational plan. Micro front-ends are trying to solve an organizational issue. Scaling, people, teams, etc. So it's not just technical. You can't just go to your decision-makers and say, okay, we're going to use all this, Composition, module federation. In fact, most of the problems are in the organization.

10. Vision, Strategy, and Commitment

Short description:

When considering micro front-ends, it's important to think about the vision and strategy. Establish a sense of urgency to ensure commitment. Bring people on board by emphasizing the shared vision and being open to new approaches. Reversible decisions are crucial due to the ever-changing nature of things.

So things that you need to think about are vision and strategy. So why do we want to do this? Please make sure that you ask this question every single time if you're thinking about micro front-ends. Why are we using this? What are we trying to achieve? And that is the vision. Your vision will be why do we need micro front-ends and why do we want to use micro front-ends? Why is that going to give us? So that's the vision. And the strategy is okay, how are we going to do this? How are we going to achieve that vision of introducing micro front-ends to the organization? So that is the first one.

The second one is establish a sense of urgency. You know, let's do micro front-ends next quarter. Let's do micro front-ends next year. You know, there is a problem. And I have seen this a lot. There is a big issue. Oh everything is on fire. Oh, I think micro front-ends would be good. Then the fire is out and everything goes back to normal and then, you know, the idea about micro front-ends is probably amongst a lot of really good ideas. So if you're bringing this to your organization is just make sure that you say, okay, if we're going to do it, we need to make sure that we do it. Bring people on board. How do you convince your boss or your technical leaders? That's a challenging question. Try to bring people on board. Try to say, okay, we are trying to achieve the same vision and we can disagree on how we're going to get there. That's fine. But we can just try to, you know, be friends and bring them on board.

And finally, be open to new approaches. Things change all the time and this is why it's very important to have reversible decisions because things change all the time and you need to be open to changing your decision and making sure that it works for your organisation. With that, it's just the end. That's the conclusion of our time. But if you have any questions, again, my name is Ruben Casas. If you have any questions, follow me on Twitter and give me a ping. I will be more than happy to answer them.

Check out more articles and videos

We constantly think of articles and videos that might spark Git people interest / skill us up or help building a stellar career

Remix Conf Europe 2022Remix Conf Europe 2022
23 min
Scaling Up with Remix and Micro Frontends
Do you have a large product built by many teams? Are you struggling to release often? Did your frontend turn into a massive unmaintainable monolith? If, like me, you’ve answered yes to any of those questions, this talk is for you! I’ll show you exactly how you can build a micro frontend architecture with Remix to solve those challenges.
TechLead Conference 2023TechLead Conference 2023
35 min
A Framework for Managing Technical Debt
Let’s face it: technical debt is inevitable and rewriting your code every 6 months is not an option. Refactoring is a complex topic that doesn't have a one-size-fits-all solution. Frontend applications are particularly sensitive because of frequent requirements and user flows changes. New abstractions, updated patterns and cleaning up those old functions - it all sounds great on paper, but it often fails in practice: todos accumulate, tickets end up rotting in the backlog and legacy code crops up in every corner of your codebase. So a process of continuous refactoring is the only weapon you have against tech debt.
In the past three years, I’ve been exploring different strategies and processes for refactoring code. In this talk I will describe the key components of a framework for tackling refactoring and I will share some of the learnings accumulated along the way. Hopefully, this will help you in your quest of improving the code quality of your codebases.
React Summit 2023React Summit 2023
24 min
Debugging JS
As developers, we spend much of our time debugging apps - often code we didn't even write. Sadly, few developers have ever been taught how to approach debugging - it's something most of us learn through painful experience.  The good news is you _can_ learn how to debug effectively, and there's several key techniques and tools you can use for debugging JS and React apps.
React Summit 2023React Summit 2023
32 min
How Not to Build a Video Game
In this talk we'll delve into the art of creating something meaningful and fulfilling. Through the lens of my own journey of rediscovering my passion for coding and building a video game from the ground up with JavaScript and React, we will explore the trade-offs between easy solutions and fast performance. You will gain valuable insights into rapid prototyping, test infrastructure, and a range of CSS tricks that can be applied to both game development and your day-to-day work.
React Summit 2023React Summit 2023
24 min
Video Editing in the Browser
Video editing is a booming market with influencers being all the rage with Reels, TikTok, Youtube. Did you know that browsers now have all the APIs to do video editing in the browser? In this talk I'm going to give you a primer on how video encoding works and how to make it work within the browser. Spoiler, it's not trivial!

Workshops on related topic

JSNation Live 2021JSNation Live 2021
113 min
Micro Frontends with Module Federation and React
Did you ever work in a monolithic Next.js app? I did and scaling a large React app so that many teams can work simultaneously is not easy. With micro frontends you can break up a frontend monolith into smaller pieces so that each team can build and deploy independently. In this workshop you'll learn how to build large React apps that scale using micro frontends.

React Summit Remote Edition 2021React Summit Remote Edition 2021
87 min
Building a Shopify App with React & Node
Workshop Free
Shopify merchants have a diverse set of needs, and developers have a unique opportunity to meet those needs building apps. Building an app can be tough work but Shopify has created a set of tools and resources to help you build out a seamless app experience as quickly as possible. Get hands on experience building an embedded Shopify app using the Shopify App CLI, Polaris and Shopify App Bridge.
We’ll show you how to create an app that accesses information from a development store and can run in your local environment.

GraphQL Galaxy 2021GraphQL Galaxy 2021
165 min
Hard GraphQL Problems at Shopify
Workshop Free
At Shopify scale, we solve some pretty hard problems. In this workshop, five different speakers will outline some of the challenges we’ve faced, and how we’ve overcome them.
Table of contents:
1 - The infamous "N+1" problem: Jonathan Baker - Let's talk about what it is, why it is a problem, and how Shopify handles it at scale across several GraphQL APIs.
2 - Contextualizing GraphQL APIs: Alex Ackerman - How and why we decided to use directives. I’ll share what directives are, which directives are available out of the box, and how to create custom directives.
3 - Faster GraphQL queries for mobile clients: Theo Ben Hassen - As your mobile app grows, so will your GraphQL queries. In this talk, I will go over diverse strategies to make your queries faster and more effective.
4 - Building tomorrow’s product today: Greg MacWilliam - How Shopify adopts future features in today’s code.
5 - Managing large APIs effectively: Rebecca Friedman - We have thousands of developers at Shopify. Let’s take a look at how we’re ensuring the quality and consistency of our GraphQL APIs with so many contributors.

JSNation 2022JSNation 2022
41 min
Build a chat room with Appwrite and React
Workshop Free
API's/Backends are difficult and we need websockets. You will be using VS Code as your editor, Parcel.js, Chakra-ui, React, React Icons, and Appwrite. By the end of this workshop, you will have the knowledge to build a real-time app using Appwrite and zero API development. Follow along and you'll have an awesome chat app to show off!
JSNation 2023JSNation 2023
57 min
0 To Auth In An Hour For Your JavaScript App
Workshop Free
Passwordless authentication may seem complex, but it is simple to add it to any app using the right tool.
We will enhance a full-stack JS application (Node.js backend + Vanilla JS frontend) to authenticate users with One Time Passwords (email) and OAuth, including:
- User authentication – Managing user interactions, returning session / refresh JWTs
- Session management and validation – Storing the session securely for subsequent client requests, validating / refreshing sessions
At the end of the workshop, we will also touch on another approach to code authentication using frontend Descope Flows (drag-and-drop workflows), while keeping only session validation in the backend. With this, we will also show how easy it is to enable biometrics and other passwordless authentication methods.