Why do you need a micro front end

The micro front end is to divide different functions into multiple sub-applications according to different dimensions, and load these sub-applications through the main application. The core of the micro front end is to dismantle, dismantle and then reassemble.

Why use it

  • Different teams develop the same application stack: Vue, React, Angular
  • We hope that each team can develop and deploy independently
  • The project also has old application code

Divide an application into several sub-applications and package the sub-applications into lib packages. When the path is switched, different subapplications are loaded. In this way, each sub-application is independent and the technology stack is not limited, thus solving the problem of front-end collaborative development.

How to land micro front end

Think of the front page as the operating system. In 2018, single-SPA was born, but there is no style isolation, no JS sandbox mechanism, just route hijacking and application loading. The principle is to hear the call of the main application and mount the child application to the main application div.

How to solve these problems:

  1. Style isolation between sub-applications, dynamic style sheets, and removing old application styles and adding new ones when switching between applications
  2. Main and sub-app style isolation, convention item prefixes, csS-Modules package to generate non-conflicting selector names (mainstream), shadow DOM real isolation (Qiankun), declare a shadow element via DOM API, Document.getelementbyid (‘shadow’).attachShadow ({mode:’closed’}), but cannot mount shadow elements on the body.
  3. Js sandbox to create a clean environment for sub-applications to use (different applications will cause pollution by mounting different properties on the window). When switching applications, you can choose to discard properties and restore properties
  4. Snapshot sandbox, take one from a year ago, take another, save the difference and go back one year
  5. If there are multiple sub-applications, use ES6 proxy. Proxy sandbox can realize multi-application sandbox and handle different applications with different proxies

Qiankun birth

The package, based on single-SPA, provides an OUT-OF-the-box API (single-SPA, Sanbox, import-HTml-Entry) that is technology independent and easy to access (as simple as iframe), supports style isolation, Summary: Child applications can be built independently, dynamically loaded at runtime, fully decouple the master child application, technology stack independent, by protocol access (child applications must be bootstrap, mount, unmount methods everywhere)

Why not iframe

If iframe is used, when the sub-application in iframe switches routes, the user refreshes the page, and the switched routes in iframe cannot be maintained. Browser native support can naturally solve the CSS and Js pollution problem. But the problems were obvious: reloading every time, taking up extra memory, poor experience, no SEO support, and the need to customize our application management and communication mechanisms.

Why not NG reverse proxy

It is very simple to implement, and can be independently developed and deployed, but it is more like the aggregation of multiple front-end applications, we just put these different front-end applications together, the front and back end is not completely separated, the user experience is not good

Why not Webpack multi-entry

Webpack Multientry is a multi-page application

Application of communication

  • Data transmission is based on URL, but message transmission ability is weak
  • Communication based on customEvent, Windows native API
  • Communication between props master sub-applications
  • Use global variables, redux for communication

The public relies on

  • CDN-externals
  • Webpack federated module

qiankun

Use case configuration can refer to qiankun’s official website. Some pits are also listed on the website

The main application requests forwarding

In practice, it is found that the master application will forward the requests of the child application. If the master application, the child application, and the back-end API are all in the same domain name, this problem is not solved naturally. The primary application and sub-application reside in the same domain name of the company. If the domain name is not the same, you need to forward the request from the primary application to the Node of the sub-application.