Federated Microfrontends at Scale

Hey, folks, let's talk about micro-frontends, the federated kind. I was already introduced, but, you know, my name's Daniel. I've been doing frontend stuff for around 10 years and I currently work as a lead engineer at Personio. You can find me there just in case what I say is interesting. And I'm here today to tell you a little story. It's a story about change, it's a story about evolution, but it's mostly about how we are running 60-plus micro-frontends owned by dozens of teams and keeping our sanity while doing it, most of the time.

So, yeah. The story begins, of course, with change and the thing that's changing in this case is Personio's frontend architecture, which in its eight years of existence has gone through three different moments. So, the first one was PHP monolith, very simple stuff, monolith got requests, handled requests, gave stuff to client. Then, Personio's labor of micro-frontends, still very much depending on the monolith for data and as a rendering vehicle, and finally, what we call federated micro-frontend setup which is the main point of today's talk. Don't worry about the size of the graphs, we'll see them bigger later. And let's start first with the, well, before that, when we talk about change, I find that the most important things to say about change is why the change was needed, right? Because that also many times informs why we ended up where we got ended up at. So start with the first moment, how Personia came to existence and why we had to go away from it. Like I said, most people would call this legacy. I call it vintage, because it's appreciated over time, you know, it's a thing that makes money. I don't like the word legacy, it's still loaded. But it's a monolith PHP Laravel application, it does absolutely everything, and the people who built Personia started the project, it got popular, kept adding features on top of it, and we kept adding features on top of it. And you know, you look back a couple of years later, and your project, which started out pretty well, suddenly looks like this. It's a mythical beast, very powerful, but also very janky. And that's what happened to Personia, you know, the company grew faster than its architectural concepts could. In the front-end specifically, it looked like this. We had jQuery coexisting with Laravel and React, and deploying anything took one and a half hours or two hours, if you were lucky, and so something had to change.

So it changed through distribution. Now, if you were around in the front-end scene in 2019, the busiest of buzzwords was micro-front-ends. That's what Personia did. They built micro-front-ends, and our flavor of micro-front-ends looked something like this. We had separate apps in separate repositories under a single framework that was React. At build time, these applications would ship assets to file storage in AWS S3 bucket, and they would also sync their latest build with an internal service called Artifact Service. This thing kept a map of application to assets, kind of like this. Then, when the monolith got a request, it would ask the Artifact Service, hey, what assets should I render here, pass them over to the client, then those would be downloaded, JavaScript would do its thing, and a standalone React application would be rendered and mounted on the user's browsers.

So, to give you a visual of how this looked, this is Persona's dashboard, and we went from this, the monolith doing absolutely everything, to something like this, where we had two separate applications, two separate microfrontends, they were standalone, they didn't share anything. And this was really good. We solved part of the issues, which was people couldn't work independently, we had a mess, everything mixed together, and deploying was painful. But it was also not so great, you know? Sharing things like state, common dependencies, everything was very hard, it required a lot of coordination, and after a while we decided it was really not worthwhile, the effort, to share the stuff, so every application had everything in it, and it was very inefficient. Also, we were deprecating the monolith, so the rendering vehicle was going to go away, which is probably the main reason why we had to build something different, right?

That is the third moment, which I call orchestration. And this third moment had two objectives. One of them was to render through something different than the monolith, because remember it was going away, and the other one was to keep the good bits while improving on the limitations, so the good bits included the team's independence, and how they could build and release separately. The limitations was what I mentioned before, it was very inefficient, hard to share stuff, and so on. And it looked like this. This is a very not-so-detailed version of it, we'll go into detail in a second. But we have an NX monorepo, and then we have our microfrontends being exposed as federated modules, consumed by an application we call the frontend orchestrator, and that application renders stuff and sends it over to the client.

Let's talk about the first aspect of this, which is federation. In political terms, this thing is about provinces, you know, the most partly independent with a central government. In our world, in JavaScript, it is very similar. You have partially serve-governing or partially stand-alone things that can be consumed by a central controller. So we have two main aspects, right? We have the modules, which are exposed by a system, any system, and anything can be a module. And these are consumed by a host. And also modules can be hosts themselves. Now, if you look at this, you might ask yourself, well, what makes it different from a regular NPM install? You know, I also consume modules when I import a module from NPM, and it's a very small thing, but it is also very big. Which is that the consumption of the modules happens at runtime. So the host doesn't need to know what the module is when it's being built, it only needs to know where it lives. And then it'll fetch it and consume it at runtime. And this allows us to do something that's very powerful, which is separate module releases from a release or a rebuild of the main host. When we're talking about micro frontends and wanting to keep independency, well, this is a must.

Okay, so that's very fun. You know, you have hosts, you have modules. Modules can be hosts, but you still need something central to consume them, which is why we need a central but lean controller. The word lean has a bit of accent on it because, well, we really want the frontend orchestrator, which is how we call our central controller, to be really dumb. You know, we wanted to do two things. One of those two things is it needs to be a router so it can map URLs to modules.

And the other one is it needs to be able to consume federated modules, so it needs to be a host. All right? Basically, these two things. It's a federated module host and router. And we use Next.js for that. And the reason why Next is so tiny and in a corner, it's not that Next is not great. Next is great and we love it. But it's because our setup doesn't depend on any specific next features, right? Any framework or in-house build system that can consume federated modules and act as a router would have worked the same way.

So, we have federated modules. We have the thing that's gonna consume them. But remember, we also had existing micro-frontends that now need to become federated modules, need to be exposed so the new thing can consume them, fetch them, render them, do all the good things we wanna do with them. And the way we came up with to accomplish this is through the creation of standards, through some standardization. And this we do through Monorepo, and NX Monorepo, in fact. You might have seen their booth outside. They're pretty cool. Kind of recommend.

And it's all about generating code. Now, whenever a new microfrontend is created or when a microfrontend is being migrated, an existing one is being migrated into the Monorepo, we generate these two things. A frontend folder. Very boring, it's just all of the frontend business logic lives there. We don't care about that, not today. And an integration library. And this is where the fun bits happen. Because this automatically generates a component that can be consumed by any other microfrontend in the Monorepo or by the frontend orchestrator, you know, the main host, as a federated module. This is where it all happens. And it's rather simple. It looks like this. You have some props so that the federated module knows where its remote exposed modules live. Then we expose memwise component that, you know, this federated module component you see there, that's some internal stuff we built and I can't quite show you what it how it looks like, but we can talk about what it does later. It's a bit too much detail for the 20 minutes that I get. But you know, come find me if you're interested in what it does.

But short story is it knows where to fetch the federated module and how to render it. And so, you know, Nx is great because making generators is very easy, and adapting them is also very easy. And it has saved us a whole bunch of work with just how simple it makes generating code. But also because remember, we wanted to keep the independence of teams, the Nx affected commands are awesome for our case.

It is what allows people to build inside a monorepo with 60 plus applications and still only run a pipeline for their changes. So it's kind of like this, you know, with a setup where you have a library A that's consumed by application A and C, but not application B, changes made to the library A will result in a pipeline only for application A and C. So only application A and C will run their tests, will be rebuilt and will be redeployed. So yay for NX Effective. There's also some pipeline trickery in there to make these things dynamic, but that's out of scope.

So, you know, NX Effective gives us what I call co-located independence, gives you the benefit of being in the same codebase, like in the same repository, but still independent that every application is its own thing and works at its own pace and is owned by its own team. Cool, so let's bring these three pieces together and let's look at the initial graph in a little bit more detail. We have the NX monorepo, right, this thing has shared libraries, it has tooling, a lot of tooling, and it has the integration glue that connects Microfrontends to the orchestrator. Then we have the frontend applications themselves, which in turn have their frontend business logic and expose an integration library, which is then consumed by the frontend orchestrator as a federated module and rendered to the client, right? Very simple design-wise, let's look at it. It's very, it doesn't have a lot of pieces, right? But like with most simple things, the devil really is in the details.

So remember the integration library? That seems small, but the usage of federated modules and all the tooling that we have inside the monorepo to make this federated module seamlessly integrate with other microfrontends or with the frontend orchestrator allows us to have a single runtime, even though we are building and deploying independently. And a single runtime, especially when you come from not having a single runtime like we did, you know, every application has its own runtime, is a fun time. It's great. It lets you do two very important things. A single instance of providers that will then share state and share, well, whatever you put into the provider, really, with other microfrontends, and it lets you very seamlessly share code, both for internal libraries and common dependencies, right? Thanks to Ferrited modules and all the glue we have, we can load stuff only once. So, to give you a very crude example, all our design system components, even though they were reused by most microfrontends, before they were loaded every single time a microfrontend was on the screen, sometimes multiple times per page because everyone uses the typography component. Now that is loaded a single time, whenever a page is loaded and then it is shared through module federation with any other microfrontend that requires it.

So, this is what like an entry point looked like. You see all of this boilerplate-y looking things, all of this providers, query client providers, sentry providers, all of this global stuff. It's even missing from the picture a lot of setup like setting up our internationalization library, setting up some request thing we have internally. Now it looks like this. You expose your app, your entry point, and that's it, because everything else moved over to the orchestrator's app component, remember we used Next. This is shared across every single page inside the Next application. That's the beauty of having a single runtime, it lets you do stuff like this. We had two goals, initially, how did we do with this thing we came up with? Let's compare. I moved backwards.

No, I didn't. This was just to remember the goals. Render to something different than the monolith, and improve the limitations while keeping the good bits.

We had monolith and micro front-ends on the left, and on the right. First one is team independence. Are teams still as independent as they were when the applications lived in separate repositories? The answer is yes. Thanks to Nx and some of what we did with our pipelines to make them dynamic, teams still build and deploy independently of one another many times per day, and without conflicts.

Do we have a central controller? Yes, we do. In both cases, there is no difference there. But is it lean? Is it fast? Does it do not a lot of things? In the case of the monolith, it did absolutely everything. It held the data, it rendered, it fetched stuff. It did everything. In the new frontend orchestrator, it does nothing. It's a router that's also a module host and that's it.

Can we share dependencies and common code easily? Now we can. Because we are in a single runtime. This one, we didn't really set out to improve this, but we've noticed that the pages that are now being served through the frontend orchestrator have seen a 30% improvement in their web vitals. Which when you think about it, since they don't have to remount everything, it makes sense because we're sharing dependencies as well. Like I said, it wasn't an initial goal, but you'd love to see it.

Now, for some non-technical lessons learned of being in the team that both designed and built this project. You should really have a real use case. If you're doing something like this, have a real use case in mind immediately. I mean, we had a real use case, but have built with the idea that you'll be pushing something to production as fast as possible. Like, choose a page that's not very visited and just put it out there. It might not work great, doesn't matter. Put it out there. We didn't have that. We ended up trying it out for the first time in production with the dashboard, the most visited page. And Personium, some might say it was brave, but it was also reckless, and also cost us a lot of headaches. So, you know, don't do it.

Push to production as fast as possible in a small place. The hardest part of building new software systems is people, and I'm not talking about individuals, right? I'm talking about organizations, so something that I didn't mention before is that we wanted this two new pieces to work kind of like as an internal open source system, you know? Like, we would be the group of maintainers. People would collaborate. We would, you know, contribute, collaborate with them. It would be great, you know? It would be glorious. That didn't work. We had no critical infrastructure system that worked like this, and it turns out that the reverse con way where you first build a system and then expect your company's organizational structures to adapt to the existing system, doesn't work. So, you know, this might sound great, but now we have a team that owns the things, and there's crystal clear ideas of who you need to contact if something breaks or who is in charge of developing it, and it works better, you know? Organization Personia wasn't ready for an idea like this, and we wasted a lot of time trying to make it work.

And finally, when you're building something new, your early adopters are the best adopters. They'll love you, they'll hate you, but most importantly, they'll let you know what works and what definitely doesn't, right? So find early adopters and treasure them. They're the best.

Now, some of you might be in similar positions, and might be thinking, eh, that sounds interesting, maybe I should try that. You know, the answer's always, it's pretty simple, it's a maybe, you know, it depends. Our situation was rather special. We had multiple teams that needed to release on demand, and they needed to make this releases available to clients immediately. We already had experience with microfrontends, so we knew how to run a federated, no not federated, distributed frontend system. We were deprecating our existing delivery mechanism, so we were forced to build something new. And we had some in-house experience building a similar system. I believe in what we built, but if some of those things weren't there, we might have fixed it in place, instead of building something different. If your position looks anything like ours, it doesn't have to look exactly like ours, but anything like ours, then maybe considering this idea, this architectural pattern of federated microfrontends might be worth looking into for you.

That's the end of the story, but before we go to the Q&A, I want to give a shout out to the faces on this slide. They were the original team that worked with me on this. Very cool people. Yeah, just wanted to put their faces out there. And thank you for coming. Thank you for listening. Great talk. Thank you so much.

We have a lot of questions. We will not be able to get to all the questions, so if you have specific questions that you see in Sli.do, please do upvote them, and we can get to those first. All right. So, first question. Does your setup rely on NX-specific functionality, or could you use an alternative like TurboRepo? We could use an alternative. What we need from NX is generating code easily and affected command, you know. I haven't really looked into TurboRepo, but if TurboRepo can do something like this that will allow monorepo applications to still feel independent and work independently, then it would also work. Great, yeah. I haven't tried it either, so it's, you know, go try.

What about versioning your MicroFrontEnd? What if common modules differ in between those versions? How would you handle this in your final host application? Right. Right now, our strategy to solve that is to not allow it. So that's another bit that NX does for you. It has a single root package JSON. So you only have a single version of dependencies across the whole monorepo. It makes updating sometimes painful, but it solves some of the issues in this case.

Another thing that we have is that we have strict versioning in our federated modules, which means that when a dependency comes in and it's served to a MicroFrontEnd as a federated module, we know that everyone will get the same version. For our own internal versioning things, we, at the moment, don't really have that. New releases are always the latest release. We serve a single remote entry file without hashing, but we are introducing a hash for the version. Remember the artefact service that I mentioned? We have a new version of that, that will keep the reference to which one is the latest entry file, and we'll serve that to the orchestrator when it's requested.

Yeah, that makes sense. I'll kind of highlight one question that was asked here that wasn't at the top, which is, you have a monorepo, and that allows you to make single point decisions, like you just mentioned, pinning versions. But do you have any technological diversity in the stack? Are people using maybe different libraries, frameworks, architectural patterns, or is it somewhat homogenous? Not quite homogenous, but it is close. We only use React. That's already a huge advantage, because that lets us simplify the tooling that creates authoritative modules, we just had to deal with one framework. And we provide some things out of the box that are what we expect people to use, like React Query, for example. That is our state server management mechanism. But still, teams can make decisions on specifics of what they use. So, for example, if a microfrontend really needs some state management for it, apart from server state, they can bring in Redux or Jotai or whatever they want. So, it is homogenous on the big pieces, not so much on the smaller ones.

Nice. So, there's a question here that's been upvoted tons. We tried the same solution, but we got stuck at SSR. How are you guys working with SSR and Federated Modules? Yeah, that's a good one. We're not. We don't have the need to do that right now. And I know that is an important point. Federated Modules are not really well set up yet for server-side rendering, or at least they weren't the last time we checked. Things might have evolved in the meantime, and they will definitely evolve eventually to support for that.

Our application depends very much on data being up-to-date in real time, because it's HR data. It's very important that things are up-to-date. So we don't really SSR things a lot. Yeah. I actually noticed that you're using React Query, is that correct? Yes. Or something like that. So you have probably a shared cache, so is that how you sort of deduplicate requests, make sure that every package doesn't actually data-fetch unnecessarily? Yeah, exactly. And that's the layer that allows us to be more efficient with our async requests.

Yeah, that's really cool. So here's the question that we kind of already touched on, but I think it needs a little bit more explaining. How do you deal with roll-out breaking changes in the federated modules, which all need independent deployments? Right. Yeah. We have, like I said, this tool that we are rolling out now, that's the new version of the Artifact Service, makes it very simple to roll back. It has an interface that we can use to say, hey, this one broke, mark it as unstable and return the last one. So it's solved with tooling, basically.

Well this leads to our next question. Did you use any existing module federation library or did you implement your own? And if you did your own, what do you think of some of the off-the-shelf solutions out there? Right. I think one of my teammates, colleagues, would be the best one to answer this question. But if I remember correctly, and Rob, sorry if I'm wrong, we ended up rolling our own, but it looks very similar to something existing. It was more like we tweaked little bits of it to adapt to our specific use case, considering a fork of what was out there for the next federated modules plugin, I believe. And what do I consider? I mean, they're all great. If you can use them, use them. It doesn't make sense to roll your own for something that's been already solved. We just didn't quite work for what we wanted.

Nice. How do you handle when one team breaks the stuff of another team through a shared library? Is there some kind of shaming ritual to put them in a corner, make them wear a funny hat, point at them? No, but I wish we had. No, I mean, we are very strict in the libraries themselves. Libraries that are shared with different microfrontends, they require 100% code coverage. I'm not saying that makes it safer. But it usually at least makes people think more about their changes.

And they need to be reviewed also by the team that's using it. Because we use a very detailed code owners file. And then while building the merge requests that will push that to production, it needs it requires an approval from every team that consumes it. So that's how we've covered ourselves from that scenario. Not to say it doesn't happen, right? But when it happens, we jump on it as a team as well. As a group of people from different sites to resolve it. No shaming.

Yeah, that makes sense. Actually, I'll highlight one other question from here, which I can't find right now. But it was about... So I'm assuming you also use some type script so you get type safety throughout the packages But how about things like code completions and the command-click thing inside VS Code, for example? Do those work when you're federating at runtime?

They do, yeah, because we have this integration package that I showed you, the integration library. That is consumed as it would any other regular import, right? The thing that it does at runtime is inside of it. Every application, every microfrontend is developed individually. It all has type-safety. It's all in TypeScript. It's type-safe. And it gets consumed by the frontend orchestrator that's also type-safe, and the async side that might break happens under the hood, and no one really touches it. So that's how we cover ourselves from that. Nice.

We have time for one more question. Kind of touched on this already, but I think this is something worth exploring a little further. How do you share common contexts between microfrontends? So I'm supposing this is runtime context, so things like data. You mentioned React Query. But could you say a few more words about how is that whole thing orchestrated? How do teams who are building one particular functionality, how do they know what data is available? What is going to be primed in the cache? Does it matter, etc., etc.?

Yeah, it does matter, and that is one point that we haven't fully solved. We have an idea, and it works already. We have what we call data libraries. So teams provide common data libraries that use, under the hood, they use React Query. They expose hooks so we can share the same query keys, and therefore access the same cache when different teams use it. But because we're migrating existing microfrontends that are standalone, they are not yet quite all there. But when they get there, we will not have the problem of knowing what's available because inside the monorepo itself, it will tell you what you can fetch safely by accessing a cache if it exists. Nice, that's really cool, actually. Awesome.

One final question for me. What is your favorite Serif typeface? Meriwether. Nice. Well, thank you so much, and I'll let you go. Good job on the talk. Thank you.