Designing a Migration to Micro-Frontends

Okay, so in the last 10 years, I worked relentlessly on figuring out how we can have an architecture that is distributed on the front end. And trust me, it was a journey. So, I spent time implementing, I spent time designing Microfront Ends, I spent a lot of time collecting war stories on what worked, what didn't work, defining patterns, anti-patterns, defining the vocabulary of the architecture, defining what was in and out from specific contexts that you cannot even imagine. But today I'm extremely happy to say that the largest companies in the world are using this architecture.

Let's say the tools that currently are using the software, the apps that they're using in any kind of industry, retailers, or banks, insurances, entertainment, even in sports, all of them at some point they moved into Microfront Ends. And today I want to share with you a pavé path or a golden path that will enable you to do as well.

So, majority of the time, if my clicker works, okay, when I walk in a room with a team that wants to work with Microfront Ends, the conversation starts in this way. We have seen your work, we like it, so we want to move to Microfront Ends. But we already have a plan. This is our app and we just take all our components, we load them remotely, and oh, job done. My answer is usually this.

So, good luck with that, because that's not a Microfront End. What is a Microfront End though? So, majority of the time there is this confusion that components are Microfront Ends while they are not. Because a component has a specific implementation aspect. So, when you implement the component, as you can see here from this input to code, we have this nice button that exposes a bunch of properties, the ID, the label, the functionalities, and so on. So, what does it mean? That in reality, the container of the component is instructing the component to behave in a certain way. Microfront Ends doesn't work in that way. In a Microfront End, instead, we have a very small footprint of properties. You have basically just a Microfront End that knows how to behave in a specific context. Why that? Because the reality is simple. So, a component is designed for usability. You create a design system because you want to have the same look and feel everywhere. You want to reduce the duplication, and finally, you want to have UI consistency, right? Microfront End is not for that. Microfront End is optimized for independence. You want to reach the fast flow. You want to have independence between teams. You want to have a system that is capable to deploy multiple times per day for multiple teams and reaching thousands of deployments per month.

So, let's start with the migration journey. This is what I call the pivot path, and majority of the time, people start from this. Should I pick Multi-Federation, Single SPA, Next.js, Multizone, whatever? That's not the starting point. That's not how you design a distributed system front-end or back-end. So, usually, what you should ask yourself is, what do you want to achieve? Because distributed systems are different. So, in order to help you out with that, I spent the last nine months working on the Microfront Ends canvas. Yesterday, I announced it for the first time, and today I show it for the first time on a stage. This Microfront End canvas is coming from the idea of a software architecture canvas that I used a handful of times in the past on trying to figure out how to define a boundary of a system. This is exactly designed for Microfront Ends. It's completely open source. It's a credit commons. You can download it today and start to use it with your code assistant or in a workshop with your teams. Basically, it's focusing on the key aspects on how you design a boundary of a Microfront End. What are the boundaries validation? What are the organizational constraints? What are the dependencies, external dependencies specifically? What are the communication methodologies? The question that usually you should ask yourself before you write the first line of code.

It's all baked inside here, and there is a nice guide that describes how to use it. The second step is usually understanding what are the most common Microfront Ends architectures. I collected them for you, so you don't have to do that job. Usually, the majority of the time, either you do Microfront Ends on server-side rendering or client-side rendering, you start with an application shell or a UI composer. The responsibility of this piece of architecture is very simple. You load the website. It's the first thing loaded, either on the server or on the client. It handles the configuration, so finding information like which device you are rendering on. For instance, the country where the user is, and stuff like that. You have authentication, authorization, handle, centralized inside the application shell, composition, so how I can lazy load my Microfront Ends inside the UI, and routing at the first level of routing. I will show you in a second what I mean by that.

After that, you start to build your Microfront Ends. The most common implementation I've seen on-prem or on cloud is this one. Every team is building their own Microfront Ends, they ship static files into an object storage, possibly not containers, please, for many reasons, but in object storages are absolutely fine, or blob storage, where you put your static files, you put the CDN in front of it, and the application shell is just pulling these static files from there. CDN plays a fantastic role here, because it's not only for static analysis, for static assets, but also for security, routing, etc. Client-side, very simple, there is no rocket science behind that. Server-side rendering is way more complicated.

Once again, in this case, we have the application shell that is living instead on the server. When the browser asks your website, the CDN is passing through the specific cluster of containers or serverless functions, and in this case, you basically route through the CDN, so you have multiple origins that are hitting different endpoints. It could be slash home, slash products, slash my account. Surprise, surprise, these can resemble the structure of your teams or domains inside your application. And therefore, I have a team that is dedicated for rendering the home, the products, etc. The application shell here is baked alongside the Microfront End itself. The beauty of this is that I can cache every single endpoint in different ways. I can decide that the home should have a TTL of time to live in the CDN of 10 seconds. At least it absorbs a bit of traffic. But my account or checkout might be longer, because it's very stable, it doesn't change very often. This is a technique I use a lot. For instance, websites that probably you have heard about, formula1.com is built in this way. Server-side rendering can also be on the next step, where I have a UI composer that is living inside a container, like slash home, and I have a bunch of static files that are loaded time to time.

Very common in large e-commerces that have worked in the past, and those are absolutely a great way to handle more complicated, but definitely enables you to have a fast feedback loop for developers when you want to release in production. So when you decide which one you want to go, you start to focus on the first microphone time. So you start with application shell and you have some heuristics. Heuristics are fantastic ways or mechanisms to have a north star to follow, in order to avoid screwing up big times in distributed systems. So in this case, your application shell should be technologically agnostic, potentially. Obviously, sometimes you want to use React end-to-end, but bear in mind you will have some struggle when you need to update to a major version across multiple microphone depths and the application shell. You take care about routing on the first level only. You are taking care about lazy loading with your favorite framework, single SPA, multi-federation, whatever it is. The majority of the time, if you design a proper application shell, it should be stable very quickly. In a matter of a few months, it's very unlikely you're going to touch it very often. And finally, it takes care about the initial configuration.

Second step, you start to build the first microphone, then not all of them, the first microphone then end-to-end. So you start to design, develop, testing, deploy, observe. Observability is mandatory. It's not, you know, you don't want to wake up at 3am in the morning on Saturday night because someone else has screwed up. You want to know which team is responsible for a specific microphone tend and making sure that it's owning that microphone then end-to-end. So now the problem is simple. We have the first microphone ten done. Okay, application shell done, microphone ten done. This is the new catalog. But we have the monolith where 100% of the traffic is there. What you want to do is generate value for your business and for your company and for yourself as well. They're risking the fact that you are working for two years on rewriting everything and not having anything in production. So in this case, what you do is start to think, okay, how can I move with an iterative migration? This stuff we have done on the back end with microservices for ages. So I don't get why we are not doing for microphone tends. So we said that CDN are powerful and all the architecture that I share with you, I have a CDN in front of that for a simple reason. CDN are not just there for caching. They also enable you security and also you have edge compute. And edge compute is fantastic because when you are hitting a website or loading a website, you pass through a CDN. Therefore, I can add a bit of latency, a few milliseconds, that enables me to route the request in whatever I want.

So I can say, perfect, if there is a catalog request on the endpoint, I will call the microphone tends part. I will serve the application shell with the first microphone tends. Everything else would be on the monolith. What's the benefit of that? Is that if I need to later on, I will show you to roll back, the only thing I need to change is the edge compute. I don't have to touch the code on anything else. That starts to be very appealing, right? Because even when I'm working on large organization in very sensitive applications, we are not going to have any problem on doing that.

But I can also do more. One thing that in microservices I use a lot is the concept of canary releases or bluegreen deployment. What I can do on the edge, nowadays many of the CDNs has a key value store available on the edge. So I can instruct that every time that they release my microphone tends, I want just to have 10% of traffic going there. So there is even further the problem. And the rest, 90% of the traffic goes to the legacy catalog. I don't have to do, like right now, big band deployment every single time. I don't get why we are not solving this problem on front end. This is already solved problem in several other areas of compute.

This is a very simple approach. The beauty of this is that I can also set some parameters. 10% of traffic, only in Switzerland, only on Chrome. This is something I've done in 2017. And what I've seen is that we move from four deployments per month to 25 per team. It means hundreds of deployments per month with real data that are flowing from users to your teams. The rollback strategy is trivial. Oh, there is a problem. It's not a big issue. We just change in a data point inside the key value store and suddenly all the traffic goes back into my system. I just need to have observability available to take that call. This is the first micro frontend. There is no rocket science here. As you have seen, I didn't even touch the code because in reality, you already know how to code it. The problem is how you're going to create the whole architecture for using and leveraging micro frontends properly.

Now the second one is interesting. There are a few things that we need to think about. Now we need to move from one micro frontend to another one, but I need to share some data. How can I share them? There are different approaches, obviously, different techniques that you can use. I listed a few of them here. Query strings, cookie, local session storage, back-end API. Which one should I use? If you have ephemeral data, like in this example, I move, maybe I have, like, a catalog with all the products, and then click to a specific product, and then pass to another micro frontend, the ID can be passed in a query string. It's accessible through JavaScript from any level that you have. It's a global API that you can reach very easily. It's just by convention, you say search inside the ID. If it's a deep link, the same thing will work like a char, no problem at all. If you need to have authentication, cookies is the favorite way to do handle that because it will enable you even to scope the amount of subdomains that you can use because the cookie you can say www.preprod.mysite.com have access to this cookie, or the others don't. So, you have a very nice scope. While local and special storage are great for data that can live inside the browser, and off you go. Back-end APIs is usually used when you want to store some preferences. Maybe you have a dashboard for observability that you're building, and you have multiple widgets, and I create as a user a specific configuration of my widgets so I can store them there.

And then we go into the interesting part. Global state. This is the biggest offender of all when you build micro-frontends. Shall we use a global state when I have multiple micro-frontends in the same view? That's the answer. We have a problem, guys, here. The communication should be loosely coupled. What we want to have is having a way that enables me to communicate between micro-frontends but without creating coupling. And therefore, if I mirror these things on the back-end, majority of the time, what you think about is asynchronous communication and ends up in messaging. It could be a message, it could be an event, it could be whatever. In front-end, what we are mirroring these things is custom events, event emitter, or reactive streams. Between the three, the most used one I've seen is custom events. Rarely reactive streams. But what I suggest is event emitter because custom events are bounded to your DOM. The position of your specific micro-frontend inside the DOM matters.

If someone intercepts that event that is bubbling to window and adds, accidentally or not, prevent event default, your event is gone. We'll never reach the other micro-frontends. With event emitter, I'm just subscribing to something that I'm interested in. The event emitter doesn't care where you put your micro-frontend. So there is no reason not to use custom events. Event emitter is extremely simple and it will enable you to have typed events if you want without any problem. Because everything boils down to this concept that we often forget, encapsulation.

Very often when we think about encapsulation, we don't immediately think that methods and data need to live inside the same shippable artifact. Because if not, you are leaking your domain outside and then you create coupling. The last thing that I want to share with you is global versus local routing. That is another important concept of micro-frontends. So a global router is usually focusing on the first level URL. So slash home slash catalog. That is the role of the application shell. That's the only thing that application shell should know. Because then if you start to provide more, let's say, cardinality inside that URL, then basically you are leaking the domain to an application shell and you find yourself to deploy the micro-frontend and the application shell every single time. That's not the way how it should work.

What you want to have is local routing. When I load catalog, everything that is inside catalog, I have different categories, furnitures, mirrors, tables, whatever it is, I will be able to maintain inside the micro-frontend, evolving the way that I want as a team, reducing the external dependency in ship as many times as I want. That's how you usually design this part. All of those, let's say, ideas and concepts, I capture them in this example using module federation. That basically is available on GitHub. It's completely, you can download it, you can start to play with that. It's usually module federation too. Obviously the exact same thing could be done with any framework of you want. I choose just module federation because at the moment I've seen a surge of requests around module federation, so I try to address that first. The question is, can AI help us? It took me nine months to get a proper answer because I wasn't fully sure how far I can go with that. How many of you have heard about harness engineering? A few of you. The idea is very simple. So far we talk about prompt engineering, context engineering, but everything boils down on I provide specs to the code assistant and that's it.

Suddenly we discover that it's not exactly the code that they wanted to have. In this research from Birgitta Böckler, that is a distinguished engineer in ThoughtWorks, there is this idea that I'm fostering for a while of guides and sensors. I need to provide feed forward mechanisms, like information regarding how you should build your micro front end, how you should code your context and so on, but at the same time I want to provide sensors, linters, static analysis, architecture testing, fitness functions that enable to constrain the beast, that is our code assistant, to provide the code that we want, not the code that he wants or he thinks that we want.

Therefore today I also want to announce micro front end skills. This is let's say trying to collect all the work that they have done in the last 10 years regarding how to design boundaries, that is by far the most difficult part. Once again, it's open source, it's available on GitHub and enables you, if you put inside the project, to design proper micro front ends. There is also a comparison that I have done with using that without and not using micro front end skills and showing the difference on the classic issues that I have seen over and over and over again. So hopefully I don't have to have a call with your company.

In summary, micro front ends are not a silver bullet, but they can help a lot in specific situations, including when you have let's say multiple teams or you are a SaaS company that you have multiple customers and you want to have a part of your system that wants to be updated more regularly and others not. I have seen successful implementing micro front ends in a large spectrum of companies from 15 people to hundreds of people. The context is key, and even more with AI, because what we are currently supposed to understand even further, considering we have time, we don't have to write all the code, we just need to check it, is getting closer to product, getting closer to the business, getting closer to what we really need to express. Therefore, designing a software shouldn't be a luxury anymore, it should be your day-to-day.

And I want to close with one of my favorite sentences in software. Grow your software, don't build it. This is from Frederick Rook, one of the fathers of computer science. The reason being is because if you have the mindset you're growing a system, it means that you are nurturing, you are working with that, you are not building a system. I build a house and I left it there. I grow a kit. That's the mindset we need to have. Thanks for having me, I hope you enjoyed the session.

So I think maybe we'll get into just like the code logistics of it all because I think some people are even on the path of, haven't made a micro front-end yet, I have a monolith, but then the logistics of a mono-repo. So I'm guessing it's likely you could use a mono-repo with multiple micro front-ends inside of it but can you maybe talk to the logistics of how do you manage all these micro front-ends in your organization. I've seen a successful implementation of micro front-ends on mono-repos and poly-repos. I don't think the repo strategy will change the outcome. The reality is that you are just defining what your engineering culture would look like.

With a mono-repo, you are basically enabling everyone to see what others are doing. If you have senior engineers that are capable to understand that they shouldn't start to cut some corners in micro front-ends and sharing things between micro front-ends, then you are in good shape. You also have the possibility to use that for having a faster discovery and people onboarding way faster. On the other side, you basically force people to work by contracts. That is usually one thing that you want to have because in a poly-repo, the discoverability is not as sleek as in mono-repo and therefore if I want to talk with your team, I might need to ask you, how can I interact with you?

That makes sense. It seems like a lot of the solutions are just organizational solutions like communication and getting teams to talk. I think this is slightly related but are micro front-ends a good idea in the era of coding agents? Wouldn't a single repository be better for an agent to work in than multiple independent components located in different repositories? I think it's funny that you could replace the word coding agent with developer. It's just someone else that has access to the code base. Do you think it's in the case of agents, is it better for a mono-repo or single repo? Once again, definitely mono-repo for agents is way more helpful because they can scan better than us and you can create some guardrails to avoid cheating. I would say that at the moment I would recommend mono-repos more than poly-repo for agents if you delegate the coding to them.

How do we make clear to management that reusability is not always the ultimate goal or that it's more of a goal on a different level of the component or design system ecosystem? That's a good challenge. Usually, when you talk with directors, VPs, or C-suites, the thing that they do understand better than the technical part is their wallet. So if you touch their wallet and you explain what is the real gain of doing this stuff instead of saying something like, oh, we need to think about usability, accessibility, and stuff like that, say, you know, there are regulations that are enforcing us to do that. Otherwise, we are going to have a fine of X amount of millions. This is something that in my experience usually works pretty well.

In what situations do you recommend not moving to micro-frontends? If you are a small team and you're just getting started and you have, let's say, a project that maybe you want to find the market fits, go with the monolith. There are amazing frameworks nowadays, if I think about Next, Astro, and Quik or many others that are providing you an extremely incredible tool for creating very fast and express yourself very fast in what you want to have. And you can test the market fast. Micro-frontends are used, especially in enterprises, because you start to have multiple teams, either inside the organization or outside the organization, that needs to contribute on the same codebase. The bottleneck when you have a monolith that has all your code is that you can squeeze so many developers into that or so many agents. But then at some point, you need to deal with the complexity of handling a large codebase with millions of lines of code. It's by far easier to split up one million lines of code in multiple artifacts that are maybe 10,000 codes each, because it's easier for our cognitive load and also easier to maintain in the long run.

And you can test the market fast. Micro-frontends are used, especially in enterprises, because you start to have multiple teams, either inside the organization or outside the organization, that needs to contribute on the same codebase. The bottleneck when you have a monolith that has all your code is that you can squeeze so many developers into that or so many agents. But then at some point, you need to deal with the complexity of handling a large codebase with millions of lines of code. It's by far easier to split up one million lines of code in multiple artifacts that are maybe 10,000 codes each, because it's easier for our cognitive load and also easier to maintain in the long run.

I like it. It's kind of let the structure of your organization match the structure of your code or how you kind of decide to build these out. The communication structure, yeah. That makes sense. The next one, they're asking for some tips. So what are tips for creating a scalable shared domain model if your domain model is from a large enterprise organization? That, it depends. I think we need to reassess what is shared, because very often what I have seen in many implementations, especially on Microfrontend, but also on the backend, people tend to think that what should be shared is huge. But the reality is, you really need to understand what is valuable across the entire system.

So the analysis that you need to make is pretty large overall to understand what we really need to share across all the teams and what should be shared across small amounts of teams. And when it's a small amount of teams, then you don't have to share globally, because it's going to create more harm than anything. When you have an API out there that basically everyone can use it, you never know how a developer we are going to use that specific data points. And when you change, if you're not aware of that, you're going to cause more harm than benefit because you're introducing a breaking change.

And another thing that you never discuss with is basically blew up the entire system. So it's very important that you are quite religious in the way how you are tackling this kind of shared modeling distributed system, because it can go, let's say, south very quickly. Definitely.

This next question, how does... Well, I lost it. Sorry. We'll go to this one. How do you deal with shared vendors like React? Have micro frontends decided their own packages or leave it to the shell and deal with big bang updates? I could imagine having multiple versions of a library or multiple versions of React could conflict. So you have any tips for managing that? Yeah, so you have different options. Depends from the framework you're using. If you use import maps, you have the possibility to have scopes that basically is creating scope creep around specific micro frontends. Similar with much federation, you can do something like that. In the example that I shared, you can find exactly that example where you go in my account and you have two micro frontends, one using React 17, the other using React 18, that they can live together and they can work without any problem. In general, you need to be careful when you do micro frontends on server-side rendering because if you're not... There are, let's say, frameworks are not so, let's say, manageable. There is more work that you need to do on your side in order to identify which dependency you want to use and maintain that. But for client-side rendering, it's definitely way easier.

Okay. This last question here. Are there any frameworks you've come across for event emitting or data bus or data sharing to communicate between micro frontends? You mentioned it being a challenge, kind of, choose your strategy. Is there anything really established or something maybe we should reach for first? Usually, what I've seen more often are the normal libraries that you can find on npm for emitters. The challenge there when you decide to go with an emitter, for instance, is just the contract. So majority of the time, people are starting to create, let's say, either a repository or a library where you have in TypeScript all the different events, contracts, and people can have, let's say, hinting on what they should express inside the system and trying to avoid to have a number over a string or whatever because TypeScript enables you to do that. I see.