What’s With Micro Frontends

♪♪♪ Hello, everyone. Welcome to this lightning talk. First of all, thank you JS Nation for this space. It's really great to be here. My name is Natalia Rocha. I'm from Ecuador, a small, beautiful country where politics has more bugs than legacy code. I work at Stack Builders as a software developer, and I also play the guitar.

But let's get into the topic, micro-frontends. So I have the feeling that this topic, when it is mentioned, it creates a lot of buzz and discussion. So let's talk a little bit about it and what role module federation plays in their implementation.

So simply put, micro-frontend is an architecture that breaks down a large frontend like this one into smaller pieces that are independently deployable. Here's the key, independently deployable. It's probably the core idea of micro-frontends. But why the buzz? Because this approach is gaining a lot of traction because it can improve scalability, team autonomy, and code maintenance. So instead of waiting for one team to finish the feature to be able to deploy the entire app, each model is isolated, flexible, and it can be rolled out independently.

So we have two primary ways to implement micro-frontends, build time and run time. Build time, where models are compiled together at build time, libraries for example, and run time, where models are loaded independently during run time. Module federation is an example of this implementation, which is great for dynamic real-time updates across teams.

So are micro-frontends new? Let's see. Has anyone used iframes before? Yeah? Has anyone used libraries before? Yeah? So maybe you have implemented a micro-frontend architecture. But when would you call a library or an iframe a micro-frontend? Because on a daily basis, we all use libraries to add functionalities, utilities, even entire frameworks to our applications. So I like to think that the architecture or mental model that you define for your project and the use case of how you intend to separate the application into a library or an iframe or a federated model is what makes it a micro-frontend. For example, on a movie theater application, teams separately develop a seat beaker and user profile models. So this gives them the possibility to work independently, having the chance to move faster, for better or worse. Right?

Now let's jump a little bit into implementation. Module federation is one way to implement this architecture. So it allows you to expose modules like functions, components, hooks, and use them as remotes that will be loaded on run time. It was introduced on Webpack 5. Zach Jackson, the creator, should be around here. And the 2.0 version was released this year.

A real use case that we had, which I would like to call the strangle pattern, allowed us to build a new application user features from another app that was slated for deprecation. So this helped us to move independently while retaining the option to swap apps in the future. And that is the use case where we found it really valuable.

But we did face several challenges. We used TypeScript. So as models are loaded on run time from a manifest, how do we get type safety on development? Well, we removed the TypeScript. No, just kidding. We extracted the types. And also module federation 2.0 introduced the possibility to extract the types from the federated models. It does it automatically. And now they can be part of the assets that are exposed on the manifest. So when you declare a model as remote, the plug-in automatically downloads the types and you can use them as a fallback path and you will have all the TypeScript benefits on your project.

Also tests. How do you test something that is consuming at run time? It can become challenging. So, the same. We deleted the tests. There are several approaches that we can use for this. And, for example, the testing responsibilities should be kept for each micro front-end, avoiding overlap, and also keeping them as decoupled as possible to make your life easier. Also having A-B testing, which is something kind of that we did. For example, having a module that has only the basic stuff that is needed to test cross-functionality and have another one that is full feature for Prov. The developer tools that module federation 2.0 included and also the manifest updates help a lot here because you can load different manifests immediately to change and try several approaches with no time.

Also there is this concept of full site federation where you can actually see the application as a whole. For example, when you were developing only the seed picker, it is uncomfortable to only see that experience. So what you do is export the host as well and create a circular dependency so you are able to see the whole application. So you can test the functionality of the whole app. We also face more challenges. For example, performance, styling, stage management, and others. So I'm going to be doing a full talk about this on the remote date. I'd invite you to join if you can.

But for today, to wrap up, I would like to leave you with this message. Should you jump into micro frontends immediately? If the challenges of scalability and independent deployments resonate to you, I think it is worth exploring. And it is also pretty useful to find the use case or the solution that you need in all these different approaches that micro frontends give you. Also, while finding the micro frontend approach to use, you will find that everything is a trade-off. And you will have to choose the one that benefits you the most. This is a phrase that came up a lot in our team discussions. And by the way, I would like to give a huge shout out to my team, the range vendors. I can't thank them enough for all their shared knowledge and professionalism. And that's pretty much it. I hope that you keep enjoying the conference, and see you around.