Module Federation Practice

Before talking about module federation, let's first understand how front-end modules are reused under multiple projects

Cross-project module reuse scheme

1. npm 包
Package management tools are indispensable for front-end applications. We can upload modules to npm packages and import them into required projects to reuse some common modules.

2. monorepo
monorepo It is a software development model that stores multiple project codes in one warehouse . All projects in monorepo are independent of each other, but different projects can refer to each other

3. git submodule
Git provides submodules for code reuse. Any git repo can reference other repos (submodules) for module reuse, and git commitid manage subproject versions in the main project. This brings about a problem. The version of sub-projects in multi-person collaboration is easy to cause conflicts. Every time you need to manually update the sub-module reference, sub-module version management is difficult to do.

4. 复制粘贴
The CV method  may be the solution with the lowest cost of reuse. GitHub has a statistic that half of the project codes it hosts are duplicated. Although copying and pasting can quickly realize code reuse, it is disastrous for future long-term maintenance, and the cost of code maintenance will become higher and higher

5.  It is the abbreviation of (Universal ModuleUMD
UMD  Definition)  . UMD integrates commonjs and amd specifications, and supports the export of global variables.  There are some defects in the scheme: the global variables exported by it are easy to cause conflicts, and if multiple UMD modules depend on each other, the loading order needs to be maintained manually, which is not very easy to  do
UMDtree shaking

Among the cross-project module reuse schemes we just mentioned, except for UMDthe scheme, the other four types, the biggest limitation is that after the project is upgraded, all the projects that depend on it need to be upgraded, compiled, and launched. One or two projects There may be no problem doing this, but if it is dozens of projects, it is too cumbersome

Is there a solution to upgrade the version of the reuse module, so that all projects that depend on it no longer need to be deployed and launched separately, and the upgraded module can be loaded into the online environment?

webpack5 provides module federation , which solves the above problems, allowing code to be directly shared between projects using CDN (remote modules), no longer needing to install npm packages locally, build and publish

Module Federation Overview

The following is the introduction of the official website:

Multiple independent builds can form an application. These independent builds do not depend on each other and can be developed and deployed independently. This is often called a micro frontend, but it is not limited to it.

There are several important concepts in module federation

Remote

As a module provider, export modules externally and be referenced by Host

Host

As a module consumer, you can dynamically load modules provided by Remote

Share

Remote and Host can share the same dependencies to avoid repeated packaging and reduce package size

The following picture can clearly see the relationship between the three72eb4700075dc483c9b54d3524536cde.png

how to use

webpack5 provides  ModuleFederationPlugin a plug-in to use module federation, the following is the configuration item of the plug-in

Remote configuration

new ModuleFederationPlugin({
    name: "component_app",
    filename: "remoteEntry.js",
    exposes: {
      "./Button":"./src/Button.jsx",
    },
    shared: ["react", "react-dom"]
})

name Is the module name, used to identify the module to ensure that other modules can correctly refer to the module

filename Used to specify the filename of the output module from which other projects load the exported module

exposes Used to specify the modules that need to be exported

shared It is used to specify the dependent modules that need to be shared. If both applications use the same dependency, you can use shared to share the dependency and reduce the package size

Host configuration

new ModuleFederationPlugin({
    name: "main_app",
    remotes: {
        "component-app":"remote_url"
    },
    shared: ["react", "react-dom"]
})

About Host, focus on  remotes configuration

It is used to specify which application needs to load the remote module from which  component-app is a module alias and   the address of the file  exported  remote_url by  Remotefilename

Introduce the shared module in the project  (take  the module exported  by RemoteButton above  as an example and use it in the Host  project). Since it is an asynchronous module, it needs to be referenced   byimport()

React.lazy(() => import('component-app/Button'))

If there are multiple projects, after each project is configured ,  the exported module  ButtonHost can be conveniently used  . In this way, if the Button  component is modified, we only need to package  the application where Button  is located   , re-export the latest  Button  module and publish it. In other projects The referenced  Button  module is the latest released code, and no longer needs to be built and released separatelyRemoteRemote

advantage

1. Simple and flexible configuration
2. Support independent deployment and go online
3. Load modules at runtime and share dependencies to reduce the size of application packages
4. Compared with  externals 以及 dllmodule federation, it can better achieve on-demand hot swap

shortcoming

1. It must be used.  webpack5
2. The module federation runtime has made a lot of changes to the runtime, and the things to be done at runtime will also increase a lot, which will have a certain negative impact on the runtime performance of our pages.
3. Since it is shared at runtime, then Version management of remote modules should also be considered

reference link

In the community, webpack4 supports module federation (https://github.com/module-federation/webpack-4)
which breaks away from the webpack technology stack and supports module federation (https://github.com/tnfe/hel)

- END -

About Qi Wu Troupe

Qi Wu Troupe is the largest front-end team of 360 Group, and participates in the work of W3C and ECMA members (TC39) on behalf of the group. Qi Wu Troupe attaches great importance to talent training. There are various development directions such as engineers, lecturers, translators, business interface people, and team leaders for employees to choose from, and supplemented by providing corresponding technical, professional, general, and leadership training. course. Qi Dance Troupe welcomes all kinds of outstanding talents to pay attention to and join Qi Dance Troupe with an open and talent-seeking attitude.

65030c7edfe4907641d993a2e5cd67ef.png

Guess you like

Origin blog.csdn.net/qiwoo_weekly/article/details/131587761