Intro
These days, building a web application is highly complicated. Modern applications have to handle a lot of complex logic and features and are far more complex than building websites in the past. Developers often have to work in large codebases. They use many technologies, and different teams of programmers are involved in the project.
Today’s web applications have introduced a lot of challenges to be faced and have forced developers to think more about scalable architecture. So how to handle with these challenges?
One of the solutions is called Micro Frontends.
Micro* Architecture
For a long time, the Frontend architecture was mainly dominated by monolith. Over time, the Backend architecture slightly changes the focus on separation responsibility leading to the architecture
of Microservices.
Source: https://micro-frontends.org/
These concepts divide the business logic into smaller independent pieces that can be used independently, but together they form one whole. These ideas come into the front-end layer which introduce the Micro Frontend term.
This approach is a highly scalable solution, and it opens up opportunities for more independent teams, the deployment process and even conventions.
Today, many large technology companies are taking the best of Micro Frontend architecture and adapting it to their own needs. Netflix is a great example here because they have created their own framework – Lattice.
Source: https://micro-frontends.org/
The term Micro Frontend was first mentioned in ThoughtWorks Technology Radar in 2016 and as always it has some advantages and pitfalls. As one of the advantages of Micro Frontends, we can mention that it is a good technique for a scalable front-end architecture in a large codebase that can be easily extended with the project.
On the other hand, the common concerns of adopting in the project are the conceptual complexity, technical implementation (CI, pipelines, module loaders, SPA etc.), or the high cost at the start of rewriting from monolith architecture.
Now, however, we have a new tool that completely changes the possibilities of using this architecture – Webpack Module Federation.
Webpack Module Federation
This new feature is available in Webpack 5. Zack Jackson invented and prototyped the feature. Module federation allows you to run code in runtime on both the client and server and its equivalent to Apollo GraphQL Federation.
It is important to note that this system is designed so that each completely standalone build/app can be in its own repository, deployed independently, and run as its own independent SPA.
Source: https://medium.com/swlh/webpack-5-module-federation-a-game-changer-to-javascript-architecture-bcdd30e02669
const path = require('path');
const HtmlWebpackPlugin = require("html-webpack-plugin");
const { ModuleFederationPlugin } = require("webpack").container;
const deps = require("./package.json").dependencies;
module.exports = {
// other webpack configs ...
plugins: [
new ModuleFederationPlugin({
name: "app_one",
filename: "remoteEntry.js",
remotes: {
"mf-component": "component@http://localhost:3001/remoteEntry.js"
},
exposes: {
"./Nav": "./src/Nav.jsx"
},
shared: {
...deps,
react: {
singleton: true,
requiredVersion: packages.react,
},
"react-dom": {
singleton: true,
requiredVersion: packages["react-dom"],
},
},
}),
new HtmlWebpackPlugin({
template: "./public/index.html",
}),
]
}
The above example shows the basic implementation in the Webpack config file. Module Federation is a high level plugin and is configured under the plugins array.
Field Description
| name | This is the name of the application. Never have conflicting names; always make sure every federated app has a unique name. |
| filename | This is the filename to use for the remote entry file. The remote entry file is a manifest of all of the exposed modules and the shared libraries. |
| remotes | These are the remotes that this application will consume. |
| exposes | These are the files that this application will expose as remotes to other applications. |
| shared | These are libraries the application will share with other applications. |
Source: Practical Module Federation book, s. 20/166
The primary purpose of Module Federation is to share code and dependencies between two different application codebases and the main advantages are:
- sharing code – Module Federation allows the application to dynamically load code from another one.
- framework agnostic – Module Federation can be used with any platform that uses JavaScript (Browser, Node, Electron) and with any UI framework, e.g. React or Vue.
- feature architecture – adopting Module Federation allows to create an end-to-end feature architecture
- any JavaScript – Module Federation can share any type of code running on JavaScript. It can be components, primitive values, hooks, business logic, etc.
And similar to the case of Micro Frontends, Module Federation have some disadvantages. The most common issues mentioned by people who use it is the complexity of managing many Module Federated applications, not suitable for smaller size codebases or runtime code loading issues.
Outro
Even Micro Frontend architecture isn’t new. A Module Federation feature brings some new fresh air and force to rethink creating frontend architecture. As I’ve mentioned earlier these concept works great in large scale application so that companies like Netflix, Reddit, Amazon, and Epic Games already use a Module Federation.
However, since the modern web application is relatively high complicated, adding Module Federation could be a complex task.
Like any new technology, it will face many problems in the beginning until it evolves into a more mature solution. However, looking at the author’s effort to try the Module Federation with different technologies, the concept looks very promising.
So will Module Federation be the future of Front-end architecture? In my opinion, yes. As with Microservices and Micro Frontends, the Module Federation will have its own space in architecture patterns. Especially in large-scale codebases, the effort put in at the beginning of its implementation will pay off in the long run during the project.
And maybe, over time, Module Federation will replace the Monolith ecosystem even in the smaller codebases.
Additional Resources:
https://module-federation.myshopify.com/products/practical-module-federation
https://betterprogramming.pub/the-future-of-micro-frontends-2f527f97d506
https://medium.com/swlh/webpack-5-module-federation-a-game-changer-to-javascript-architecture-bcdd30e02669
https://github.com/module-federation/module-federation-examples