The Dark Side of Micro-Frontends

In the last 10 years, I embarked on this journey on how to make a distributed system on the front end. And the last five, I was working for AWS, so I had the pleasure to work with hundreds of teams worldwide, internal teams from Amazon, AWS, teams from New Zealand, Silicon Valley, from insurance, banks, e-commerce, you name it. And I have seen quite a lot of, let's say, bad implementation of micro-intents and successful implementation of micro-intents. And today, I want just to highlight the main issues that I've seen with micro-intents. It's not going to be a lecture on how micro-intents works end to end, but focusing on the main problems, because there are the parts that usually hurt the most.

Okay, let's see if it works. Yes. Okay, most of the time when I walk in a room with a customer, we do a bit of a whiteboarding session together. And maybe they already started to deploy something in production. What I see is something like that. They have a website and then just say, okay, listen, can you explain to me how it works? And then I tell them, oh yes, of course we can. So, we have the header, this is a micro-intent. Then we have another component, another micro-intent, another micro-intent, another micro-intent, another micro-intent, and so on until the end. Now, there is a fundamental problem here that is basically thinking that components and micro-intent are exactly the same thing. And secondly, thinking that runtime composition is the only way to do micro-intents. That is absolutely not.

Then we move to the next step. This is the real dark side of micro-intents, where after telling me how many components they have or many micro-intents they have in the same view, they start to say, oh yeah, because we are using modified iteration, but we are thinking about single SPA, but also we want a bit of next JS multi-zone, we are using multi-framework approach, or we are choosing one of those frameworks, or even no frameworks, we're using iframes, whatever it is. The problem is none of those are making successful micro-intents platform. So, stop it. That's the most important thing, the only takeaway that you have from this part.

Then, please, also don't blame the architecture, like I heard a bazillion times, that is not only for micro-intents, by the way, it's also for any distributed system, also microservices, I heard several times, if things are not working. Because you need to think about three dimensions when you are designing a distributed system, it's not only for micro-intents. You need to think about the architecture part, so investing time designing your system. You need to think about the engineering culture you want to have. If you have, I don't know, half or majority of junior developers, you cannot start immediately with the most advanced things that you find in engineering. And finally, you need to think about the team topology, so how you're structuring the teams. Because every single decision that you make in an architecture is going to affect, intentionally or not, the other two dimensions, and vice versa, by the way. So, when you see friction inside the system, it's a gift. It's not negative, it's a gift. Because it means that something doesn't work and you need to understand which dimension you're going to solve. Surprise! Vast majority of the time it's not architecture.

Okay, so I want to share with you the three most common mistakes I have seen in the last four years and how to overcome them. The first one is, what is a micro-intent? You have no idea how often I ask how micro is a micro-intent or how micro is a microservice, by the way. Is 100 lines of code a microservice or a micro-intent? But the answer is no. There are different characteristics. So let's try to come to consensus on this one. Let's take the most amazing... I'm not a designer, as you can see. Let's see the most amazing things that you can have or the most granular things that you can have in front of this component. So this button is exposing a bunch of properties. So you have the label, you have methods, you have an ID, you have a bunch of things. Think about that. Who is setting this information? The context of the button, right? So it's the container of the button that is instructing the button how to behave.

You should be enabled, you should be disabled, you should be something else. Therefore, the logic of the context is owned by the container of the button, not the button itself. Because what we are trying to do is something different than a micro-intent. While a micro-intent, majority of the time, works in this way. You have a micro-intent, it's called catalog, and contains everything that is needed or almost everything. You don't have to inject much. Why that? Because everything that is inside the micro-intent understands exactly how to behave. It doesn't need more context.

Why are we doing this? Because if you think about the difference between a component and a micro-intent, you remember that a component library in a design system, or wherever it is, is designed for reusability. Reusability, it's not me saying that, but someone more important than me, like Neil Ford, is a form of coupling. What you want to do with the components is reducing duplication and finally having UI consistency. This is the goal of components. That is not the goal of micro-intents. What you want to do with micro-intents is optimizing for independence. I want to reduce the external dependency, reduce, not eliminate, I know that already thinking about silos, reduce external dependencies of my teams in order to accelerate and reach the fast flow.

If you don't know the concept of fast flow, I highly encourage you to read the book Accelerate. It is an outstanding book that introduces the idea of Dora metrics and also explains why successful companies are operating in a certain way. Micro-intents, therefore, are definitely different from components. You cannot structure the things that I show at the beginning of the first slide because there is just a distributed mess and not micro-intents. Therefore, how do we split, Luca? If you look into, I work with a lot of enterprises, but even in large enterprises, you start coarse grain. You don't start immediately fine grain because coarse grain is like having a chunk or tiny chunk of your system that is assigned to a team and you start to work on that and iterate on that because you have less complexity. It's easier to split.

If I'm telling you to take your website, think that you are four teams and try to assign domains inside those teams that are replicable in one view or group of views, you will be able to do that. It's faster to build and deploy because developers already know how to build a single-page application or a service-side rendering application, but just a chunk of that will be dedicated to them enough to not reach a high cognitive load. Also, it's easier to rollback. We are going to discuss rollback in a second.

Therefore, what is the heuristic that you should think about? There is this concept of software architecture is called about how granular you want to go. This is not only for micro-services, but also for others. There is this idea of integrators and disintegrators. A classic example is code volatility. How often are you going to change? There are areas of a system that you can identify very easily that require high effort at the beginning, and then you don't touch forever and ever. That you can aggregate very easily because yes, at the beginning it will be a bit of discomfort, but you don't have to split it up in 25 different thousand micro-front-ends because they are not bringing any value to you.

Sometimes it's security that is forcing you to do that, a data relationship or share code. An example, just to make it more concrete, think about payments. If you have a payments micro-service, sometimes I have seen teams that started to have a micro-front-end for PayPal, a micro-front-end for a credit card, a micro-front-end for gift card, and so on and so forth. But the reality is when you ask, how often do you change the credit card and PayPal, apart that when I have to update the SDK version, nothing more. So why are you creating multiple micro-front-ends? The reason is, you need to think about how you're going to intentionally break apart your system.

So why are you creating multiple micro-front-ends? The reason is, you need to think about how you're going to intentionally break apart your system. It's not that you just randomly say, okay, this is a component, this is a component, therefore I can load a runtime because it will fire back very quickly. The other thing is, usually with the micro-front-ends, what you have is an application shell. So the first thing that you load when you call the website with micro-front-ends is an application shell, if you do client-side rendering. Similarly also on the server-side, but it's living on the server.

And there are a few rules here, a few heuristics that I always try to push when I see certain implementation. I have seen implementation where the application shell is written in Angular, React, Solid, whatever. But the problem there is that in reality the application shell doesn't need to have a specific framework, potentially. You can be technology agnostic as much as possible. A good rule of thumb is, if I'm building an application shell that is loading, routing, composing micro-front-ends on the fly, and I can use for this project here, but also for the other projects, then you are designing a very good application shell.

Why that? Because you want to have a stable version of the application shell. The application shell lifecycle for developers should be a high rate of change at the beginning, and then you shouldn't even touch that anymore. Because you externalize a couple of things, like the routing, the mechanism of composing will always be the same, you will have just an initial configuration that you expose, and that's it. Therefore, if you are starting to look into the application shell, like I have a few customers that have done that, where I start to have application logic in the application shell, then suddenly you need to deploy your micro-front-end with your application shell.

And, surprise, this is not a problem of architecture. The other thing is that you need to think about is routing on application shell, and you need to discern the two aspects, global and local routing. The simplest way to implement the first implementation of your micro-front-end platform is looking into the first-level URL. So mysite.com slash catalog slash my account slash landing page, whatever it is. That is the first-level URL. That is a good way to split a micro-front-end. If you do at the routing level, you have a lot of benefits. I will show you in a second many others.

And then what you delegate is local routing inside the micro-front-end itself. It's obvious that if you start straight away with the horizontal split, as I call it, so you have multiple micro-front-ends in the same view, these become complicated. Usually a pattern that I recommend every time is creating a meta-shell, or basically a shell of a shell, that basically dedicates its existence on positioning the micro-front-ends inside a unique view. Why that? Because first of all, the application shell is capable to be completely independent, and it just loads one artifact, whatever it is. It's a meta-shell or a real micro-front-end, it doesn't matter. But secondly, the teams that are responsible for building these independent micro-front-ends, because the vast majority of the time, there are multiple teams working on that, will own that meta-shell without interacting with external dependencies.

Between the three or four teams that are working on that, it will simplify drastically the deployment and the changes. If they do a good job, potentially they can do some interesting optimization, because maybe two micro-front-ends are calling the same API, but if they are owning the meta-shell, they can be delegated to the meta-shell to do this part and inject the result inside the micro-front-end. So you start to see that there are some capabilities that very often are not thought, because the complexity of micro-front-ends is not implementing React or using a specific state management. That is something we do day to day. The problem is we are going back to design and not just selecting libraries. That is a completely different beast.

So when you have local routing, you have something like that. Inside the micro-front-end, if you're using React Router, I have an example I will share later, you can do something like that. You just delegate, basically, to handle furniture slash table and I have a customer, for instance, there is an e-commerce here in the UK, that the first micro-front-end they deploy alongside their existing system was the mirror category of their e-commerce. The rest of the e-commerce was monolith. Then slowly but steadily, when they learned some stuff, they had to roll back a couple of times because they screw up some things, but then slowly but steadily, they started to deploy all the different micro-front-ends, one after the other. They augmented this, let's say, mirror one with I don't know, furniture and other stuff, and slowly but steadily, they created and deployed their micro-front-ends. This is a great strategy for selling even to your management that you don't need 18, 24 months of dark development or stealth mode development for building an entire system. You build one micro-front-end, one route, you iterate on that, and you grow with that. In the meantime that you're doing this end-to-end work, you will learn a ton because you are forced to go through all the process from the ideation, building, creating the observability, logging, deployment, and so on. Super important.

But also, when you are building micro-front-ends, it is one part that very often is messed up by people. If you look into the different examples from single SPA, multi-federation, etc., the majority of the time people are writing in the examples all the different micro-front-ends and remotes to load inside the configuration of Webpack or RSPack or whatever. That is a problem. It's not production-ready because everyone here is using a multi-environment approach. When you work with a multi-environment approach, you might have ephemeral environments sometimes if you're lucky and you don't have just three specific configurations. Even if you have three specific configurations, it's painful if you, let's say, write inside the Webpack configuration before you can leverage dynamic routing. What does it mean? Back four years ago, I created a working group. It was myself, it was Zach Jackson, the creator of multi-federation, it was Joel Danning, the creator of single SPA, and then there was Mateo Figues, that is the creator of Open Components. These three frameworks are the most used frameworks worldwide for building micro-front-ends. I said, listen guys, we need to find a solution for solving the problem of deployment and routing because it has to be something agnostic that we can use in every framework. The framework that we have today, but the framework we have also tomorrow. Before we came up with this schema that became available on GitHub publicly. This schema basically is a discovery schema, like we call it, that enables us to have a bunch of information related to the microphone tense. Because it's JSON, it can be generated wherever you want. You can have your CI, CD, the final task that is basically generating this schema or storing in a database, wherever you want. But the cool thing is, an application shell can load this stuff and directly from this schema generate the dynamic routing. So, it may be one user in, let's say, a specific application, maybe one user doesn't need to load the catalog because it doesn't have the permission and another does, but you can easily implement this JSON with a direct router. So, you just take this JSON, you parse it, you retrieve whatever information you need, and then you generate the routes dynamically. The beauty of that, if you're using, in this case, Moji Federation, that what you can do is when you have, let's say, a change of pages, you can lazy load leveraging the Moji Federation advanced API without writing everything inside the configuration for loading common dependencies, as well as loading a specific microphone tend. Very simple.

There is no magic here. It's extremely easy and it will basically load just a module. This is what with Moji Federation you can do in vanilla JavaScript. If you want to use the ASM, you can use single SPA and update and import maps. There are a bazillion ways to do that, but the concept is exactly the same.

And then, obviously, you will have a suspense where you inject... Oh, this is an interesting one. There is this nice thing that's called... Okay, I cannot see it. So, here there is this emitter. This is usually the way how you communicate between microphone tends. Very often, people think about the next topic that is the global state that we are going to discuss in a second.

The beauty of this discovery service that we call frontend discovery service is very simple. So, you have an application shell that is calling through a CDN, an endpoint that is a frontend discovery service, return the JSON, and you have seen the logic that it's going to handle. And then, when it's done, you can start to retrieve the different microphone tends either from, let's say, an endpoint if you're using server-side rendering for the microphone tends or if it's a static JSON you can retrieve from there.

But this is a very common pattern they have seen very successfully implemented. And I can tell you more. Nowadays, you can use the frontend discovery even on the edge. Every single cloud provider, as well as CDN provider, are offering a capability to store some data on the edge as well as having compute on the edge. And therefore, these kind of things can be easily done through a CDN that will not add much latency and will be super performant and scalable because usually there are more point of parentheses of a CDN compared to the region inside a cloud provider.

Therefore, definitely something to look at. And last but not least, that is super cool, you can start to implement something that is called canary releases, a problem solved 15 years ago by microservices. But for some reason in frontend, we forget about that, that if you have, let's say, the possibility to route things on the edge, then you can say, perfect, I deploy a new catalog. I have 10 percent of traffic going there. I can test it. I can even select because all the CDN allows you to select to retrieve information like location of the request as well as the browser request.

And in my previous job before joining AWS, we have a solution running on the edge that enables us to say, I want to deploy a micro-frontend only in Switzerland, only five percent of the traffic, only on Chrome. And that enabled, that moved the needle on deployment, therefore the fast flow approach I was describing before, from deploying two times or three times per month to 25 times per day per team. And that's where you want to be because there is no in-distributed system change advisory board that can tell you if one change will help you or not, unfortunately. So thanks to that, the rollback strategy I was telling before is not, oh, I need to deploy something else.

No, I need to change the configuration and automatically all the traffic goes back to where it was. And that is a great place to be because you create a safe net for developers. If you're interested to know more about that, I created a Moncho Federation example where there is a tiny e-commerce where you can see here the implementation. This is with Moncho Federation 2.0. This is the latest one that went GA a few months ago.

Okay, so last thing, global state. You have no idea how often I heard about this. Why, Luca, cannot we have a global state that we can orchestrate everything? This is bad. This is really bad. I've seen a customer that done that, has spent six months refactoring to move it away. Because when you want to communicate, usually use this free construct. Custom events, event emitter, reactive streams.

My best suggestion I can give you is use event emitter where possible, and the reactive streams, if you are in a company that knows how to use reactive streams, I can guarantee you that it's not a walk in the park. I wrote a book on this topic, so I know very well the problem. Then you have data sharing, that is the other thing that you need to think about. Communication is one thing, but then you need also to send some data. Usually you divide in important data and ephemeral data.

Like an id of a product, you can use a query. You pass this information for a query, it's ephemeral, you don't have to store anywhere. Very easy to pick it up. By convention, everyone will pick up from query string done. But then if you have session or other things, you can use cookies. Maybe you have a personalization of a UI, you can use a back-end API, and so on. There are already solutions that are well done, but you need to understand what is your context.

You need to spend time to understand what you need to express. Why am I saying the global state doesn't work? Because you are basically breaking the idea of encapsulation. I know many people are saying, oh yeah, but I know perfectly all the patterns. But the reality is encapsulation, what it says, is that you need to have data and methods that are shielded away from the rest of the world. So you have a bunch of events that are coming there. That is how you design real microphone tents.

If you start to have data that is shared across systems, it's exactly the same thing in microservices. You're having a database that is shared across 10 microservices. And then what happens when you change the scheme of the database? Oh, I need to test again, everything, coordinating multiple teams, and maybe are in different time zones, and blah, blah, blah, blah, blah. That is not a problem in architecture. It's a poor design. Another approach, if you don't want to use, let's say, the horizontal split that is more complex, is using BFF. So back-end for front-end.

Another approach, if you don't want to use, let's say, the horizontal split that is more complex, is using BFF. So back-end for front-end. If you have a single team doing the front-end, you have multiple, let's say, API that you need to aggregate. You don't have to delegate the UI to the other teams. You can easily consume these APIs on the back-end for front-end where you have all the data there. And every time that there is a request, you either fetch fresh data or you cache the data, as we have seen in the previous talk.

Now, the bonus tip of this session is this one. Governance for the win. Very often, where people screw up is that they forget about governance. Distributed systems, the only way to know what's going on is having governance applied, because otherwise, I can guarantee you, if you are a super developer, principle architect, wherever, you cannot be in every room every single time. Therefore, what you use is fitness functions that are an architectural approach for testing your application. The book is Building Evolution Architecture, highly recommended.

An example is budget size. How can I make sure the micro-front ends are not having a megabyte to load? Very easily. So you create, basically, every time that you open a PR, you create a githook and you immediately retrieve, download, or clone the project, build the project on the fly, as I was doing back in the days in a lambda function, and then check that it was inside a certain tree shield. And that works like a charm, because you can pick up immediately if the developers screw up the tree shaking configuration or forget about the library that they are using.

You can also test architectural decisions. If you say on the share library folder, I want to have the header and the footer and the seats. With TS-Arc, you can test and say inside this folder, I want to see x, y, z. And this is a test that you can run every time that someone is updating that specific folder.

Dependency management is crucial. Very often, you need, you have a design system. You want to update across multiple micro-frontends. That is easy. It's called dependable. It's there for ages. You just set it up and then every night, even if it's an external library or internal library, it will go and open a PR for every change that you need to make. You don't have to be present and AI can automate all of this.

I want to close up with probably my favorite quote from Frederick Brooke, one of the creators or the writers behind There is No Silver Bullet, White Paper, that you need to grow your software. Don't build it. Because growth enters the mindset of a distributed system that today is one thing, but the business will evolve, your system will evolve. And therefore, you need to adapt your system to the new reality, while if you are building, the mindset is I design something, I build it, I forget. That is not how we want to build our software.

That is not how we want to build our software. If you enjoy and want to drill down more on microphone tens, I have a free newsletter that you can find there. And the second edition of my book is out from last week worldwide on building microphone tens. That's all I got. Hope that you enjoy and enjoy the party.

Is there a light side to microphone tens? A light side. There is a dark side. There is a light side. The light side is when they work, where you start to see, let's say, the business that see the real value of the implementation. Because you start to deploy very often, you can do more tests in production, you can accelerate the new features that they have in their head, and stuff like that. So at the end of the day, we are writing code for the idea of generating a value for our users and our company. It's not a playground for developers. That's at least how I think.

Fair. I definitely agree a lot with that. I think a lot of the times we build code for ourselves, and that's not like we're supposed to be building it for people. It's not that code quality doesn't matter. It's like other things sometimes matter more, like being able to deploy faster, being able to iterate, being able to ship features, to help people. Yeah. Now, getting out of track, and we don't have two minutes and 48 seconds. When do you think it's a good idea to use monorepos versus separate repos for micro-frontends? It's amazing because this question I have at least once every single talk I do in the last five years. So both of them work, both of them don't work. And why that? Because in reality, what you are describing in selection of monorepo and polyrepo is the behavior of your engineers. Most of the time, if you think about the monorepo, you are basically forcing people to use trunk-based development. Not everyone is used to do that properly. And if you break master, good luck. And if you have a lot of junior people are not familiar on having this fast speed feedback loop, you might have more troubles than benefits. While if you do polyrepo, what you are basically, let's say, designing is the fact that teams have less discoverability, and you force them to work by contracts. That it might be what you want, or it might not.

That it might be what you want, or it might not. But I think I've seen, let's say, implementation with monorepo moving to polyrepo and vice versa. And I've seen them failing, and I've seen them succeeding. The reality is it's not a technology choice. It's how you want your engineers working together and which engineer culture you want inside your system.

Do you think it's also a good idea to sometimes have a little bit of both? Like things that are kind of connected are in the same repo? I proposed one idea in my book five years ago that was domain repo. Yeah, exactly. Something like that. That's way better put than what I said. Exactly. So the domain repo is this idea that you have, let's say, a monorepo, but you have, let's say, multiple domains. And therefore, you have a monorepo per domain. I like that a lot. Yeah.

How do you feel about micro frontends via web components? Seeing that many times, I have to say in the last three years, not many people are using, apart from, let's say, leveraging the shadow root. That is a good way for encapsulating and scoping the content inside. The problem you have with that, though, is that if you have a different version of React, at the end of the day, you are shipping a lot of code that is pretty much useless. While if you do an extra effort to look into single SPA, module federation, native federation, and all the other places that are handling this properly, you are not going to load too much code, basically, inside your system.