Table of Contents[Hide][Show]
- So, what is a module federation?
- Why module federation?
- Module federation core components
Module Federation core features+−
- Excellent web performance
- Effective development
- The ability to self-heal and redundancy
- Effective handling of common dependencies
- Instead of having to re-deploy consumers, deploy independent code.
- When running, import code from other builds.
- Enhanced developer experience while preserving client experience
- Micro-frontends operate in a monolithic fashion.
- Conclusion
The concept of micro frontends applies microservices to frontend development.
The idea is to break the application or website up into smaller, independently developed pieces that are then connected during runtime, as opposed to creating them as a single, cohesive monolith.
The method enables you to create other components of the application using other technologies and with independent teams.
The idea is to reduce the maintenance expenses related to a typical monolith by segmenting development in this way.
By allowing them to concentrate on a particular area of an application as a coherent team, it also makes new forms of cooperation between backend and frontend devs possible.
For instance, you might have a team that is solely responsible for the search capability or another aspect of a key product that is crucial to a business.
Thanks to the module federation, you have enough functionality to handle the workflow that the micro frontend approach mandates.
This post will take a deep look at the architecture of the module federation, as well as its main features and application patterns.
So, what is a module federation?
Javascript’s module federation design makes use of reused parts in many applications.
It’s fairly basic jargon, but I’ve just simply made it seem that way to appear breezy.
As we are all familiar with sharing components within a React application, Module Federation effectively accomplishes the same goal in practice, with the exception that it dynamically exposes application modules for consumption by other applications.
Module Federation seeks to overcome the problem of module sharing in a distributed system by delivering those key shared elements as macro or micro as desired.
This is accomplished by having them removed from your apps and the build workflow.
Why module federation?
Here are some factors that module federation can handle easily:
- Externals and DLLs (Dynamic Link Libraries) were all we occasionally had for sharing functionality between apps. All of which made scaling code sharing extremely challenging.
- NPM is sluggish.
- When two separate programs share crucial code, they must be dynamic and flexible.
In order for standalone apps to be totally in their own repository, deploy separately, and operate as their own independent SPA, Module Federation was created.
Module federation core components
Before diving deeper, briefly discussing a few new concepts that module federation brings is important.
- Host: When a page loads, the build or module initialized initially is called a host. A provider can be thought of as a host.
- Remote: A remote is a different construct that uses a portion of the host. They are also referred to as customers.
- Bi-directional host: a Webpack build that functions as both a remote that other hosts consume and a host that consumes remotes.
- Vendor federation: enables declaratively shared runtime sharing of npm module dependencies for a host or remote, regardless of the location from which they are loaded. One of the major performance problems with micro frontends is resolved in this way.
Patterns of Federated Application
Evergreen Design System
One of the most basic forms of federated applications is an “evergreen remote,” which is a shared remote like a “Design System” or “Component library” that is independently distributed and updated for all users.
Without each app team needing to spend time on revisions, this might be helpful in ensuring that all online sites adhere to the most recent corporate identity.
In order to design and put into place the limits and procedures necessary to guarantee secure, ongoing updates, this might be a useful place for businesses to start when considering a federated application architecture.
Following are some use-cases where independently deployed shared remotes might be a suitable fit:
- Design systems
- Application shells
- Component libraries
- Consumers
- Shared toolkits
- Alternative distribution models for widgets used by internal or external
Multi-SPA Module Sharing
Reuse already-exported features, such as components, in different standalone single-page apps. Benefits include:
- Consumers receive automated updates
- Domain expertise remains on the team that is in charge of it.
- Streamlines the deployment procedure because separate module releases are not necessary.
Shell driven federation
The shell-driven federation includes:
- When creating a new product version, the Product team does not wait for the Checkout team to complete their job.
- When switching remotes, there is no page reload.
- When necessary, Shell offers slow remote loading and (top-level) routing.
- Routing across remotes is made possible via vendor federation, which enables the reuse of frequently used npm packages.
- Shell offers the framework and other common dependencies that are reused by the lazy loaded remotes.
Multi-shell federation
Similar to the shell-driven federation described above, but used different shells.
It contains:
- a number of shells
- White-labeling
- Not all remotes are required by Shell B or have independent implementations.
Module Federation core features
Excellent web performance
The issue with the normal NPM module composition is that as the number of dependents rises, the application’s size generally grows.
In order to avoid loading bundles when your application loads and only load them when necessary, Module Federation offers you the ability to lazily load bundles.
This prevents the need to download modules before they are actually required, which improves site speed.
Effective development
Each project can be produced and delivered in isolation and can be carried out by various teams because Module Federation encourages you to organize your application into discrete projects so that you can build and deploy them separately (and hence in parallel).
The ability to self-heal and redundancy
Shared dependencies allow Module Federation to keep track of all of your program’s dependencies in one place.
This way, even when an application doesn’t declare a dependence or when there are network problems, it still knows what it needs and can handle downloading it as needed.
Effective handling of common dependencies
Additionally, Module Federation offers superior dependency management, effectively resolving vendor and third-party requirements so that your application will never load more than one version of a library.
Instead of having to re-deploy consumers, deploy independent code.
The developer is highly interested in having evergreen functionality. Once exposed dependent functionality has changed, it won’t be necessary to reinstall the consumers anymore.
I must admit that this is a highly potent feature in and of itself, one that will need careful examination to prevent unexpected outcomes.
When running, import code from other builds.
When adopting the NPM package model, we might consider apps that use Module Federation akin to APIs rather than sharing code and thinking of “library.”
In the same manner that they can also receive functionality from other apps, web applications can now provide the functionality to other applications.
Enhanced developer experience while preserving client experience
Any JavaScript developer will be quite comfortable with Module Federation because it is a Webpack plugin that is accessible as of Webpack version 5.
This is actually rather strong and intriguing if we give it some thought.
By utilizing third-party Webpack loaders, consider all the components that Webpack bundles, including scripts, assets, styles, pictures, markdowns, and more.
By using Module Federation, all of these can be shared and federated.
Micro-frontends operate in a monolithic fashion.
It’s quite easy to add shared functionality to your application; just import the bundle as normal or use synchronous loading.
Alternatively, asynchronous loading can be used to only load dependencies when necessary by utilizing lazy loading.
Conclusion
In this post, we’ve discussed Module Federation as a fantastic choice for developing your micro-frontend application.
Letting apps exchange and consume functionality at runtime encourages scalability by enabling various teams to work on independent applications.
When the common functionality changes, you won’t need to design and deploy your consumers since it supports evergreen functionality.
Your program will function like a monolith after it has been set up, which is fantastic.
Shareable dependencies are used to reduce the size of apps. Since many developers are already familiar with the Webpack environment, the developer experience is excellent.
Leave a Reply