Module Federation — What, Why, How?
You may heard about the current buzz words “Module Federation”, “Micro frontend” and if you’re new to Module Federation, you can review this story, since I’ll be elaborating this concept in most easiest yet effective and simple way, like the way I like, the “Straight talk no rubbish”. I’ll be discussing:
- What is Module Federation?
- Why it exists?
- How it can be achieved?
WHAT: Module Federation is a JavaScript architecture coined by Zack Jackson that gives us a method of sharing code between frontend applications at runtime. The main idea is to subdivide a big application into tiny parts.
Initially when I was absorbing this idea, it sounds familiar with npm i.e. Node package manager, that is the most common way of sharing JavaScript code, so I searched about their differences, their pros and cons and I found that:
- The NPM package doesn’t have a rendering code.
- It increases the size of the application as you add more and more packages and increases deployment time as well.
- Version changes is a big challenge in this approach.
But, the client or customer may or may not be interested in having micro frontend app for his/her product, rather client will demand for single consolidated app, so we can say it’ll be abstraction for end user, and will presented to the user as single page application.
Micro frontend is the core concept behind Module federation, we can say that Module Federation is built using micro frontends.
They can be:
- Run on different ports.
- Different folders, different origins, different repos.
- They have different versions having different technologies; like some are built in Angular, some on React, some on Vue etc.
WHY: It may be useful in many scenarios like:
- It will contain smaller and more optimized bundle size, it provides an overall better developer and user experience as a result of shared components and dependencies that can be lazy loaded whenever we want.
- It would be beneficial to divide, when product is too huge to handle, having different modules with different concepts within it.
- One of the great advantage is the ability for teams of developers scattered into different locations, working on particular product to be able to pick a technology stack of their own choice without fear of incompatibility with the other code.
They are divided into one shell and remote applications. Shell is basically main-frame application responsible for pieces of small applications to be pulled on demand.
We can break huge application by splitting it by:
PAGE: breaking different pages running at the same time, because that may cause crash of application in older devices.
FUNCTIONALITY: breaking multiple heavy features having different concepts into multiple applications.
SECTION: breaking applications by section, with different apps sharing the same section or components.
HOW: Using Angular 12 and Webpack 5
Pre requisites:
•Angular CLI: >= 11.2.8
•Node: >= 15.4.0
•Webpack: >= 5.4.0
The Angular Architects module-federation package: package that is used to implement module federation which basically creates a simple API to request modules or we can say micro frontends apps, and pull them into our shell application.
ng add @angular-architects/module-federation — project shell — port 5000
We need to run this command in the shell and remote applications with correct project name and unique port.
The above command does few changes under the hood and adds a webpack.config file for configurations related to module federation. This is in addition to the angular configurations.
We can have shared packages or common modules as well, so that we don’t have duplicates and version mismatch packages. But the main part is providing a name, filename & exposing the module. The mapping is done by the filename, in this case remoteEntry.js which is a small file that gets created during runtime. In Shell application we define the keys with which to access the remoteEntry files so that Angular will know from where to lazy load the module.
These applications are all bi-directional hosts. which means Any application that’s loaded first, becomes a host — as you change routes , federated modules will be loaded respectively.
Here to get the module we basically use a helper method from the package we added earlier called loadRemoteModule where we pass the proper remoteName, remoteEntry and exposedModule which we used in the webpack.config.js file of remote applications.
I saw this example which seems to be most relevant with this concept, which depicts that there’s 4 module which can be broken into particular applications, based on different features within it, developed on different languages.
CONCLUSION:
So what we can conclude from this story is, whether you should or should not adopt micro-frontends depends on the kind of project you are building, because this approach will not be the best for small applications or businesses. A micro-frontend architectural approach is best when working on a large project with distributed teams.
For proof of concept: See my created example portraying this concept.
Steps to setup:
- Run npm install: to install dependencies.
- Run Micro Frontend 1 application:
ng serve mfe1 -o
- Run Micro Frontend 2 application:
ng serve mfe2 -o
- Run shell application:
ng serve shell -o
(where o flags says to open application in default browser).
