Overview of the Micro Front End (Application Split)

Micro-frontends are microservices-like architectures that apply the concepts of microservices to the browser, transforming Web applications from single monolithic applications into multiple small front-end applications.

The emergence of micro front end is mainly to solve the following pain points:

  1. SPA pages are huge and difficult to maintain, so decoupling and splitting should be carried out. Each part should be maintained and deployed separately to improve efficiency.
  2. Because of the system history, the micro front end can be very compatible with the old and new systems;

There is a key question here, how can multiple application projects share some resources, which might have been in the form of NPM packages in the past, but this approach is certainly inadequate

  1. The NPM package update process is cumbersome and complex
  2. Slow build speed. (Multiple introductions of vendors)
  3. NPM iterations require too many changes

NPM:

Front end:

Micro front end can be seen in the article:zhuanlan.zhihu.com/p/78362028 zhuanlan.zhihu.com/p/95085796

Common micro front end schemes:

According to the not ifame:www.yuque.com/kuitos/gky7…

web component:

Problems to be solved by the micro front end:

Route switching distribution:

The key is to establish the mapping between sub-applications and routes; PushState, history.replaceState, and popState provided by H5 are used to capture route changes. After capturing the corresponding child application, render the page to a node;

Isolation of major microapplications:

The isolation here mainly refers to the isolation of JS execution environment and CSS style between the microapplication and the main application.

CSS style isolation: When the main application and micro-application render on the same screen, some styles may pollute each other. If you want to completely isolate CSS pollution, you can use CSS Module or namespace to give each micro-application Module a specific prefix to ensure that it will not interfere with each other. You can use postCSS plug-in of Webpack. Add specific prefixes at packaging time. CSS isolation between microapplications is very simple, marking all the link and style content of the application each time the application loads. After the application is uninstalled, synchronize the corresponding Link and style on the uninstallation page. Js isolation: adopt sandbox mechanism;

Communication problems;

Recommended solutions

heaven and earth

The qiankun official The official demo accessible qiankun.umijs.org/zh/guide

The downside of this single spa is that it’s not as good as emP

Module federation for EMP decentralized mode

Let’s look at the optimization points of Webpackage 5.
  1. Persistent cache

In Webpack 4, we use cache-loader to cache some loaders with high performance overhead, or use hard-source-webpack-plugin to provide some intermediate cache for modules. After Webpack5, a built-in caching capability (caching modules and chunks) was integrated for us by default. You can speed up the secondary build by doing the following.

cache: {
    type: 'filesystem'.// Default cache is node_modules/.cache/webpack
    Cache. cacheDirectory is available only when cache.type is set to filesystem.
    // cacheDirectory:path.resolve(__dirname,'node_modules/.cac/webpack'),
    buildDependencies : { 
    // 2. Add your configuration to buildDependency to invalidate the cache when the configuration changes
    config : [ __filename ] 
  
    // 3. If you have other builds that depend on you can add them here
    // Note that webpack, loader, and all modules referenced from your configuration are added automatically}}Copy the code
  1. Better tree – shaking

(Optimization. InnerGraph) Analyze the import/export relationship of the module, which is started by default in production mode. Commonjs tracking

  1. Module federal

Module is the basic concept and principle of watching this: blog.csdn.net/sendudu/art…

Github.com/efoxTeam/em…

Problems solved:

  1. Hot plug. NPM used to send packages, now directly reference code;
  2. Public dependency; Shared;

Two aspects of module federation are shown here: exposed modules and shared modules.

The container exposes the module asynchronously. You need to have the container load/download the modules you want to use, and then use them from the container. Asynchronous exposure allows builds to place each exposed module and its dependencies in a separate file. This way, only used modules need to be loaded, but containers can still bundle modules. Also, in general, the chunking technique of WebPack is used here, which allows us to keep requests and total downloads low, resulting in good Web performance.

The container’s host needs exposed remote modules that can handle asynchronous loading.

On the other hand, shared modules. Containers and applications can place shared modules in the share scope along with version information. They can also use shared modules in shared scope and version requirement checks. Share scope Deduplication is performed on the shared module. This mode provides the highest available version of the shared module.

How about emP with module federation: I think it is using module federation to do micro front-end architecture, see this article; Juejin. Cn/post / 689494…

Here is another diagram: is this the case with the NPM form used in the previous group

But to become an EMP:

WIP: Esbuild

The reason for this is that a friend of mine told me that the esBuild package is extremely good but has nothing to do with the micro front end

Look at this ~ vite is juejin.cn/post/696733…

[1]juejin.cn/post/698398… [2] blog.csdn.net/sendudu/art… [3] juejin. Cn/post / 691149…