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 frontend. And trust me, it was a journey. So, I spent time implementing. I spent time designing microfrontends. I spent a lot of time collecting war stories on what worked, what didn't work, defining patterns, antipatterns, 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 microfrontends. And today, I want to share with you a PAVED 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 microfrontends, the conversation starts in this way. We have seen your work. We like it. So, we want to move to microfrontends. 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 microfrontend. What is a microfrontend, though? So, majority of the time, there is this confusion that components are microfrontends 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 of 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 components is instructing the component to behave in a certain way. Microfrontend doesn't work in that way. In a microfrontend, instead, we have a very small footprint of properties. You have basically just a microfrontend 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? And microfrontend is not for that. Microfrontend 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 from multiple teams and reaching thousands of developments, thousands of deployments per month. So, let's start with the migration journey. This is what I call the pavate path, and majority of the time, people start from this. Should I pick like 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.

In order to help you out with that, I spent the last nine months working on the Microfrontend canvas. Yesterday, I announced it for the first time, and today, I show it for the first time on a stage. This Microfrontend 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 Microfrontend. 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 also in a workshop with your teams. Basically, it's focusing on the key aspects on how you design a boundary of a Microfrontend. What are the boundaries of 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.

The second step is usually understanding what are the most common Microfrontend architectures. So, I collected them for you, so you don't have to do that job. Usually, the majority of the time, either you do Microfrontend on server-side rendering or client-side rendering, you start with an application shell or a UI composer. The responsibilities 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 a few 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 Microfrontend 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 Microfrontends. So, the most common implementation I've seen on prem or on cloud is this one. Every team is building their own Microfrontend. 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.

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. So, once again, in this case, we have the application shell that is living instead on the server. So, 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.

The beauty of this is 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, let's say, stable. It doesn't change very often. This is a technique I use a lot. For instance, a website 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.

For instance, a website 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 I 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. When you decide which one you want to go, you start to focus on the first microphone time. 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. In this case, your application shell should be technology 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 of the first level only. You are taking care about the lazy loading with your favorite framework, single SPA, module 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, not all of them, the first microphone 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 he's owning that microphone end to end. So now the problem is simple. We have the first microphone tend done, okay? Application shell done, microphone tend 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 starting to think, okay, how can I move with an iterative migration? This stuff we have done on on the backend 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 they share with you 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. And 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, I want to, if there is the 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 will 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 organizations 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 blue-green 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 I can risk 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 frontend. 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 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 microphone. 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. Okay, now we need to move from one microphone 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, backend API, which one should I use? If you have ephemeral data, like in this example, I move, maybe I have a catalog with all the products and then click to a specific product and then pass to another microphone. 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 ID.

If it's a deep link, the same thing will work like a charm. No problem at all. If you need to have authentication, cookies are the favorite way to 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 and preprod.mysite.com have access to this cookie, all the others don't. So you have a very nice scope. While local and session storage are great for data that can live inside the browser, and off you go. Backend APIs are 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.

Then we go into the interesting part. Global state. This is the biggest offender of all when you build microfrontends. Shall we use a global state when I have multiple microfrontends in the same view? That's the answer. We have a problem, guys, here. So the communication should be loosely coupled. What we want to have is having a way that enables me to communicate between microfrontends but without creating coupling. Therefore, if I mirror these things on the backend, most 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 frontend, 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 way the position of your specific microfrontend inside the DOM matters.

If someone intercepts that event that is bubbling to window and adds, accidentally or not, prevent even default, your event is gone. We'll never reach the other microfrontends. With event emitter, I'm just subscribing to something that I'm interested in. The event emitter doesn't care where you put your microfrontends. There is no reason not to use custom events. Event emitter is extremely simple and it will enable you to have a typed event if you want without any problem. Because everything boils down in 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 microfrontends. 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 of that URL, then basically you are leaking the domain to an application shell and you find yourself to deploy the microfrontend 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 like different categories, furnitures, mirrors, tables, wherever it is. I will be able to maintain inside the microfrontend evolving the way that I want as a team reducing the external dependency and ship as many times as I want. That's how you usually design this for this part. All of those, let's say, ideas and concepts, I captured them in this example using module federation that basically is available on GitHub. You can download it, you can start to play with that. It's usually module federation 2. 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 like 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 talked about prompt engineering, context engineering, but everything boils down to, I provide specs to the code assistant and that's it. Suddenly, we discovered 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 feedforward mechanisms, like information regarding how you should build your micro frontend, 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 enables to constrain, basically, 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 frontend skills. So, 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 frontends.

There is also a comparison they have done with using that without and not using micro frontend skills and showing the difference on the classic issues that they have seen over and over and over again. So, hopefully, I don't have to have a call with your company. So, in summary, micro frontends 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. Others not. I have seen successfully implementing micro frontends 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're not building a system. I build a house and I left it there. I grow a kid. That's the mindset that we need to have. Thanks for having me, I hope that 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 frontend yet, I have a monolith. But then the logistics of like a mono repo. So I'm guessing it's likely you could use a mono repo with multiple micro frontends inside of it, but can you maybe talk to the logistics of how do you manage all these micro frontends in your organization? I've seen a successful implementation of micro frontends on mono repos and poly repos. I don't think the repo strategy will change the outcome. The reality is 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. And if you have let's say senior engineers that are capable to understand that they shouldn't start to cut some corners in micro frontends and sharing things between micro frontends, then you are in good shape. You also have the possibility to use that for having, let's say, a faster discovery and people on-boarding 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, okay, how can I interact with you? And maybe by design, something that you want to have inside your system. 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 frontends 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. So do you think in the case of agents, is it better for a mono repo or a 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. So I would say that at the moment, I would recommend mono repos more than poly repo for agents if you delegate basically the coding to them. That makes sense.

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. That makes sense.

That makes sense. Shift the conversation. It's about the money. Definitely. I mean, this is a little bit Kruncherian, but 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 Kwik 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. 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 code base. 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 code base with millions of lines of code. It's by far easier to split up one million slices 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. It's kind of, let the structure of your organization match the structure of your code or how you decide to build these out.

The communication structure, yeah. That makes sense. The next one, they're asking for some tips. What are tips for creating a scalable shared domain model if your domain model is from a large enterprise organization? It depends. I think we need to reassess what is shared, because very often what I have seen in many implementations, especially on Microsoft Teams but also on the back end, 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 a small amount 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 R than anything. When you have an API out there that basically everyone can use it, you never know how a developer is going to use that specific data point. And when you change, if you're not aware of that, you're going to cause more R's than benefit, because you're introducing a breaking change. And another thing that you never discussed with is basically blowing 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 Microfrontends 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 are using. If you use import maps, you have the possibility to have scopes that basically are creating a scope creep around a specific Microfrontend. Similar with MojFederation, you can do something like that. In the example that I shared, you can find exactly that example where you go in my account that you have two Microfrontends, 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 Microfrontends on server-side rendering because if you're not... There are, let's say, frameworks that 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.

This last question here, are there any frameworks you've come across for event emitting or data bus or data sharing to communicate between Microfrontends? 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 event 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. We have a little bit more time so let me grab another one.

What are the questions we can ask to determine if something is a component and not a Microfrontend? How do you handle smart components to a piece of UI service integration? A piece of UI service integration? Okay, so in that case, I would say be careful in that scenario. If you want something very granular that has, let's say, a bit of interaction with the server, that is not a problem. It depends on how much it leaks outside because if then the container needs to instruct this smart component to behave in a certain way, that cannot be shipped independently. Every time that you change the content, you need to ship the smart component and the container. The beauty of Microfrontend is that we are avoiding that by design in order to reduce the external dependencies and accelerate the deployment so you are completely independent in that part. Hence why, in a situation like that, I would argue try to figure out if a Microfrontend suits you better than just a smart component because you might risk to have a lot of smart components and a lot of coupling happening in a single view and then you cannot blame the architecture if that doesn't work. Fantastic. That's all the time we have but thank you so much. Thank you.