This is my first article on getting started

What is a micro front end

The concept of a micro front end is similar to that of a microservice: take a large whole and break it down into small pieces with clear dependencies.

advantage

  1. Loose coupling and good scalability. The code base is smaller, more cohesive, and more maintainable. Code bases in microfront-end architectures tend to be smaller and easier to develop. By defining clear application boundaries, the complexity of unreasonable implicit coupling between modules is avoided.
  2. Incremental upgrades, updates, and even rewrites of some of the front-end features are possible. Old and new code can coexist harmoniously. Smooth transitions to intermediate releases and continuous delivery of new features when refactoring gradually. Low-risk local replacement of product functionality.
  3. Independent deployment. Narrow the scope of change and reduce the associated risks.

Implementation scheme

The key problem

How can multiple bundles integrate sub-applications, how can they isolate each other and affect common resources, how can they reuse sub-applications, how can they communicate with each other, how can they test the multi-bundle integration container application + each sub-application set

Container applications:

  1. Render common page elements such as headers and footers
  2. Addresses crosscutting concerns such as authentication and navigation
  3. Integrate each micro front end into one page and control the rendering area and timing of the micro front end

Integration mode:

  1. Server side integration: such as SSR assembly template. The key is to ensure that each part of the template can be published independently, with each sub-service responsible for rendering and serving the corresponding micro front, and the master service making requests to each sub-service. Each sub-service is responsible for rendering and serving the corresponding micro front end, and the main service makes requests to each sub-service
  2. Build time integration: such as Code Splitting. A common approach is to publish separate NPM packages that work together as dependencies for the main application. The biggest problem is that it causes coupling during the release phase. Any change in a child application requires a complete recompile, which means a new version is released for a small change in the product. Therefore, this approach is not recommended
  3. Runtime integration: Iframe, JS, Web Components, etc. The iframe.
    1. Iframe is undoubtedly the simplest, and naturally supports style isolation as well as global variable isolation, but performance and communication costs are high. Routing control, history stack management, deep linking, responsive layout, etc., are all complicated.
    2. Js: such as the preceding route
    3. Web Components. Encapsulate each subapplication as a custom HTML element (rather than a rendering function in the front-end routing scheme) to get the style isolation and other benefits of Shadow DOM

Resource reuse:

The recommended approach is to allow a degree of redundancy up front, with individual bundles creating components in their own codebase until a relatively clear component API is in place before creating common components that can be reused.