Cyrillo Heimart
💻 Software Engineer ▪ Front-end @ Restaurants on iFood
Hello everyone, I came here to share a little of my view on module federation. Firstly, this is an opinion article that has the sole and exclusive intention of demonstrating the advantages of incorporating a micro-frontend architecture with Module Federation. I clarify that the architecture demonstrated in this article is intended to exemplify the behavior of the technology.
Also, so as not to confuse you, every time I refer to MFE, it means I'm talking about micro-frontend, ok?
Motivation
As many know or are about to discover, the MFE architecture, despite being present on the market since 2011 (perhaps even before that), has now become very popular and more and more companies are incorporating it. As a result, several doubts arose among the community about the advantages and disadvantages of migrating from conventional architecture to MFE architecture using Module Federation. Because of this, I came to share a little of my experience involving technology with you.
But what is this Module Federation?
Module Federation, as the name suggests, is a federation of modules. But duh, you already knew that. Now seriously, Module Federation is a plugin that came with WebPack 5 to facilitate and bring advantages to the MFEs architecture, it solved one of the main disadvantages in relation to the conventional architecture and I will comment after talking a little about the pros and cons of the architecture below, so stay there!
Advantages and disadvantages of micro-frontends-based architecture
Here, I will bring some advantages and disadvantages of using an MFEs architecture, regardless of technology and implementation. Obviously I won't list all the points, but I tried to bring out the main ones that you should consider when starting or migrating your architecture.
Benefits
- It is possible to split (separate) your entire application into several different projects or codebases, separating responsibilities, and allowing teams that work on the same product to have more independence in their activities.
- It also makes it possible for MFEs to be shared between applications, for example: The same login with its business rules can be shared between several applications, thus ensuring that they all respect a single source, not having to reinvent the wheel with each new project that come to emerge.
- The separation into several projects makes implementing new features, bug fixes and project maintenance much easier due to the decoupling in relation to a conventional monolithic project.
- It also facilitates understanding, because in the case of people who do not have the context of the project, they can understand much smaller code than in monolithic applications.
- Publishing an MFE raises awareness among all applications that consume it, without the need to publish other applications.
- We can publish the MFEs completely separately, making the build and release time much shorter.
Disadvantages
Obviously not everything is made of chocolate and I also need to bring you the main problems involving micro-frontend.
- Some implementations of MFEs may cause duplication of dependencies between projects, thus causing each of the MFEs to require their own dependencies to be implemented. I encourage you to think about an application with dozens of MFEs using the same dependency. Each MFE would have its dependency installed, causing the performance of your application to suffer.
- Some forms of implementation add a lot of complexity to the project.
Why migrate to Module Federation?
Well, as promised, here it goes!!!
Module federation came to remedy the main disadvantage we have in MFE architectures, which is… Tararan, PERFORMANCE. As I showed you in the topic above, in conventional architecture each MFE has its own dependencies and they are not reused, meaning that every time we call an MFE on screen, it comes with all its baggage to be able to be used (you have already seen the big problem, right?)..
Module Federation, in turn, shares dependencies between MFEs, making it up to the developer to decide what will be shared between them. So instead of having the same dependency several times, they all share the same source.
Dependencies are shared through a shared layer by the webpack, called __webpack_share_scopes__ — Yes, it is possible to print to the console! =)
Did you understand? No? Let's go to the blackboard!
Did you notice where the little arrows are pointing? But why that?
Simply Module Federation shares the dependencies in the order in which the MFEs are placed on screen, so in the case of cyrillover@10.0.1, the Login MFE, was the first to share the dependency, and in the case of caps-lock@2.0.1 was the MFE of Registration.
They also noticed that the dependence caps Lock Do you have different versions? Sharing requiring the version is the responsibility of the developer, so we must be very careful about what we share and how. Furthermore, if the developer decides not to share the dependency, it will not be reused, as in the case of pay-day@2.0.0 that even though they have the same version, it is not shared.
Did you understand?
But does MFE only share dependencies?
The most interesting thing is to stop thinking about MFE as a separate application, but rather as a remote repository of components, because now we only search MFE for the components we want to present. So an MFE can provide several components that are used between the two applications. Let me know how it goes.
Then two applications can share MFE login components. In this case, if Hero is changed by MFE, the applications that consume it will be sensitized.
Should I use Module Federation in every application?
Nananinanão, a gigantic NO!
Application architecture tends to be unique, that is, it serves a purpose! So we shouldn't repeat architecture simply because we like it a lot. We must build the architecture according to the purpose we want to serve. So take the advantages and disadvantages into consideration when building the architecture, as it will guide you to the success or failure of what you are building!
Thanks
This was my first article here.
I would like to thank you for taking the time to read a little about what I wrote!! And I hope it was useful!!
Sources
Module Federation
A hug, see you next time Rex`s.
