Module Federation: Divide, Conquer, Share!

We're using front-end features built by different teams sometimes can become challenging depending on the chosen approach. For example, if we use a library, what about versioning and maintenance? If we use a monolith, what about the pipelines and the build times? We can find a pragmatic solution with the model federation for 10 times not only for sharing the features but also for dividing and conquering.

So let's go. Hello there. My name is Nathalie Rochan. I'm a tech lead at Static Builders. I am really glad to be part of JS Nation US and basically have the chance to share some experiences and concepts with you. So, let's start first with micro frontends. And model federation is just one approach of many to implement micro frontends. But why in the first place you would consider implementing micro frontends, right? It could be for many reasons. For example, your team has grown, your application has grown in a way that maintenance requires separate teams or just it makes sense to have our project divided in different parts so that it can be more maintainable. And it is also self-contained and independently deployable, which is one of the main features or the key feature of a micro frontend. Right.

So we can divide the micro frontend techniques, implementation techniques, in two types. The first one would be built-in and the other one would be runtimes. Right. So built-in means that micro frontends are kept in separate models, but they are still available at compile time. So they must be redeployed for a change to be effective. One example of this can be NPM packages or libraries where you actually have to bump the version and redeploy your application so that the change is affected. Right. On the other hand, it means that these are consumed at runtime, as the name says. When you deploy something, for example, using model federation, which is a way to achieve runtime dependencies, ECMAScript or System.js are another. The host or consumer applications don't need to bump the version or be redeployed to have this change. Once a producer application makes the change, immediately you can see a life change in the host applications because this is consumed at runtime in the browser. OK. So here we start to see that both options have their trade-offs. Right. More like trade-offs, things that you might want to consider when choosing them. So for example, on build-time, let's say that you have four micro frontends. Right.

And one of them released a new version. Depending on how these interact, let's say that two micro frontends need to update. So how would you make sure that both are using the same version? Let's say that one team actually got the Slack message saying, hey, we bumped the version or an alert or anything. They remembered it, but the other team didn't. So you could end up with different versions for the user, which kind of diminishes the experience of one application only. But you can enforce this using different tools. But we start adding complexity to enforce this, as you can see. Instead, runtime, for example, with micro frontends, with model federation, for example, you solve the issue because everyone will have the same version as soon as the other team deploys. Right. But what happens if they introduce a break-in change? What happens if some applications were tightly coupled? Right. So the application could break. In this case, we might want to ensure that we have total decoupling or that we have backward compatibility, or we might end up in the adding version again. Right. So as you can see, both have their tradeoffs. Here are also some other techniques that you can do, you can use for micro frontends, like web components, system.js, even iframes, monorepos with NX frameworks like single spot or bit. But we are going to be focusing on model federation. So let's see how it works.

Model federation was introduced in Webpack 5 and this year the 2.0 version was released. The way it works is by enabling the plugin in the build tool. In this case, we are using Webpack. But in the 2.0 version, it decouples the runtime from the build tools, increasing the flexibility of model loading. So as you can see here, we define which are our remote dependencies and the elements that we want to expose. We can expose anything from a component to a function provider. For our use case, we use something called or something that we can call the strangle pattern. So we can use models from an application developed by other teams. This is because the application that the other team was developing, we already knew that it was kind of going to be deprecated, but we needed a way to actually start using it fast and that we can complete our host application. So what we did is to use model federation to basically import hooks, import some providers that we needed to obtain information from the other app, and also the main component that we used to complete our application. So in this case, I'm going to represent our use case with a movie theater application where the seat beaker and the user profile were being developed by other teams. So as you can see, we are exposing the components from both. And on the host application, we consume them.

So then we have two producer applications and one consumer. And as you can see, the application is just important, the URL of the manifest, right? And once you have updates that are made from the producers, let's make, for example, an update on the seat beaker. We don't have to redeploy the updates on the host application. The manifest already has everything that you need to consume the latest version. Right? So this manifest is the one that contains all the information and the assets that are going to be used from our host application. And this is what we use to import and basically complete our host application.

So what happens if this goes down or the URL dies for some reason? We have to make sure that these assets are being served in something like on high level availability like a CDN industry bucket or industry bucket so that we can make sure that we don't have downtime or at least diminish it as much as possible. And this is one of the drawbacks of Model Federation that the app is not complete at build time, so we might have errors on runtime in the browser. But we need to make sure that we implement these high availability options that we serve the assets and we make sure that they are healthy. And if the case of something happens, we fail gracefully with error boundaries in the worst case.

And as you can see here, once we import them and consume them, the application itself, I mean on the host, it is pretty normal to use it. The difference is that these are coming in runtime and as you can see the browser is rendering them as normal HTML. And also something really important to notice and that was also implemented in our use case is that both applications, even the host one and the consumer one had their own business logic and they were independent. Right? We didn't share the backend at all. And this is pretty important in microfrontends because we try to ensure the coupling and independence in the deployment. So having a backend or a BFF that is specific for each microfrontend is important to ensure independence. Now, let's talk about some features and things to take into account, for example, types. If we think about the manifest that we were seeing before, these are being consumed in runtime. Right? But what happens for type safety? Because we actually need it, right? To be able to see, I mean to have type safety itself, auto complete features and stuff. If this is runtime, we cannot do it because we don't know what are the types from the other team. Right? We just have a URL. So what we did in our team is to extract the types and create a script to extract the types from the other project and import it in ours. But this is because we had actually access to that repository and we were able to do it. But something that was implemented in Model Operation 2.0 is that we now have this TypeScript plugin and the Enhanced plugin that allow us to actually do sort of the same, right? Once we expose something in our model, the plugin automatically recognizes what we are exposing, extract the types, saves them in a folder, and now it is served as an asset for the host application to be able to download it, right? So when the host actually goes ahead and says, hey, I want this remote on my application, the plugin automatically recognizes and try to download that folder. Once the folder is downloaded, it automatically extract it. But we had to do some setup, as you can see here in our TypeScript config, to use it as fallback path, right? So if any of the types for any element in the project are not found in the local project itself, it looks for the types in that folder that was downloaded. And that is the way that we get auto-complete features and type safety for the federated models. Now, I want to talk about this concept that is called the full federated sites. Because when we were developing our application, the other team actually didn't have access to see how their application would work in our host application. I mean, they could have downloaded our application and actually start the service, see how it works, or wait for us to deploy the application and go to the dev environment to see it, right? But they couldn't actually see it on the development cycle.

Like, for example, for the Boolean, something that was mounting inside another component or we started having those sort of issues, right? Also, something that happened to us is that since that application had a lot of complex setup for the backend and really, really complicated needs for it to be started, we weren't actually able to kind of use them both at the same time, right? So what we ended up doing is to create this federated model that was used as fallback. It had really basic functionality that helped us to see how our application would work as a whole, I mean, completed with the information obtained from the other app, right? So but again, it was pretty much like we actually didn't know how that application would work with the host one. So there is where this concept of full-federated sites could have been useful for us at that time, because this creates sort of like a circular dependency between applications so that the host one not only becomes a consumer but also a producer. So as you can see here, for example, in the theater application, the home app, it's going to expose itself, right? And when we go to the application, we can consume also the host application and we can create a second script to be able to start our application with the host one, right? So that gives us a really fast development cycle and it will be pretty easy to see how they both interact when, for example, they need to, they have something coupled or some state or something that actually needs to interact with each other. It will be easier to test and even easy to test or use for end-to-end tests.

Also, I wanted to talk about some things for example, performance. And I think it's important to take into account several factors that we have when we import components from a federating model. For example, the first one is that it is really important to use dynamic imports to reduce initial bundle size and also be able to import and load these models only when they are needed, right? Also, the waterstrap applications to give webpack the opportunity to process the rest of the imports before executing the app and avoiding race condition. The most important one I think is dependency sharing because not specifying shared packages can result in duplications and slow down the experience. And not defining versions between shared libraries can also cause errors between the applications. And if there are libraries with internal state, we have to make sure to make them as singletons to ensure that we have only one instance running, right? And that is where also comes debugging because when you start having performance issues due to shared dependencies, we can use tools like Medusa where we can have a better understanding of how our microfounders are connected and especially what dependencies we are using and which needs their attention. For example, here it is telling us that a specific dependency can be declared as shared. And also something really cool that was introduced in Model Federation 2.0 is that the Chrome tools now, for the Chrome tools we have now a plugin, a Model Federation plugin that we can install and see how our application is connected and how our models are being consumed. So that is pretty cool for debugging because if something fails, you can see also what other applications can be affected, right?

Also for styling, what we did to keep our application coherent is to use the same UI kit and that allows us to reuse built components, avoiding customization, right? As much as possible. So if we needed to change something, we change it in the UI kit library. That way we avoided presenting the user something like Comic Sans in one page and Times New Roman on the other. Right. Also, routing is really important to take into account. In our application, what we did is to use the concept of a shell application. That actually is pretty much the host. And the sole purpose of it is to orchestrate the microfront, right? So the routing only works inside the host application. When we can actually import the models with lazy loading, render them with necessary and basically handle the routing as we needed. Other options you can use also can be like frameworks, for example, Single SPA. Single SPA allows you to mount and unmount components to improve performance and load them in specific places or specific routes, right? Finally, stage management. We had a really tightly coupled applications. So stage management was used basically from the producer application because we actually needed to get the state from there. We used hooks, which made it kind of easier to do. But I would say that if you actually want to go all the way, and if we probably would have been using models, not only because of the strangled pattern, but different use cases, there are also things like, for example, we could have used like probe drilling, pool solve, query parameters, local storage, anything that could have avoided to basically couple the applications. And we always need to try to basically decouple them.

And we always need to try to basically decouple them. We could have even tried to create a specific federated model for a state and use them in order to decouple them. That is also something to take into account.

And to give you some conclusions, I guess that when designing which approach to use when you intend to grow your application, you will find out that kind of everything is a tradeoff. Everything has its consequences and we have to accept the ones that benefit us the most and affects us the least according to our project, our teams, our applications. In our use case, I think that module federation was really useful, as mentioned, for the strangling pattern. And that actually helped us to build the application, the host one that was going to be there for the longer run, right, for the future, until we migrate the other one.

Now, if we ask ourselves if we should start directly with Microfrontends and any of its implementation, I think it's important to ask ourselves if we actually have the problems that Microfrontend solves. For example, we mentioned that the key feature is to have independently the place, right, for different parts of the system. So this means that our product has grown and a lot of the things that we are seeing on maintenance and stuff guides us to separate the problem into smaller pieces. So that is where I think that we can start thinking about it. And yeah, I think that is pretty much it. Thank you very much for joining me and I hope that you enjoyed it. Thank you.