What is a micro front end

define

Microfront-end is a microservice-like architecture that applies the concept of microservices to the browser side.

In simple terms, a large front-end service is split into n smaller services that are aggregated at run time.

Each small service can be developed, run, and deployed independently.

The core value of

Its core values are as follows:

  • Technology has nothing to do
  • Independent development, independent deployment
  • The incremental upgrade
  • Independent operation, multiple applications do not affect each other

Note: The micro front end makes sense when it is based on the architecture with the front and back ends separated.

Why the micro front end

When you encounter the following scenario:

    1. Maintaining a large front-end project that is built, packaged, released, and deployed inefficiently
    1. With multiple teams maintaining a large project, code versioning and consolidation become difficult
    1. Historical projects use old technology stacks, old systems cannot be discarded, new technologies cannot be used, and there is no energy to reconstruct the entire application
    1. React, React-Router, ANTD, and custom component libraries. How to control the unified version more friendly?
    1. In a large project (for example, there are 20 services at the front end), public resources need to be updated. How can we update only one service without updating, packaging and launching every service
    1. Browser side, more front-end services, how to better achieve communication?
    1. How to implement a project gracefully and efficiently when working across companies and teams?
    1. Application A needs to reference several pages or the entire service of application B. How does 0 cost reference, and A new version of service B is released, and service A needs to be updated automatically?
    1. .

Three. Several ways to realize the micro front end

iframe

advantages

  • Perfect support for JS isolation, style isolation

disadvantages

  • If the URL is not synchronized, the URL status in the IFrame is lost when the browser refreshes
  • Iframe Indicates a partial bullet frame
  • Internal and external communication is inefficient and variables cannot be shared
  • Resources are reloaded at a slower rate each time they are entered

Route distribution

Use nginx/K8S ingress reverse proxy to different front-end services.

advantages

  • Low development cost
  • Configuration is simple

disadvantages

  • When switching between multiple applications, each application will reload, affecting the experience (think about the difference between traditional pages and SPA).
  • Data cannot be shared between multiple applications
  • Communication between multiple applications is difficult
  • Multiple application common dependency reloading

web components

advantages

  • Each service has a separate script and style

disadvantages

  • Large renovation cost
  • Each browser is compatible and unfriendly
  • Multiple application common dependency reloading

single-SPA

advantages

  • Good experience, multi-service switching like a single SPA
  • Have a life cycle of services
  • Shared data
  • Compatible with different technology stack operation

disadvantages

  • Multi-application, no multi-application sandbox mechanism
  • Sloppy style naming can lead to conflicts across multiple applications
  • Js entry results in strong coupling between the child service and the base

qiankun

The universe was developed by @Kuitos and produced by Ali. By far, it is the most perfect micro front-end solution, and also the most start. Its code is written very beautiful, I suggest you to read, learn.

advantages

  • Based on single-SPA package, out of the box
  • Technology independent, multiple technology stacks can coexist
  • HTML Entry access, decoupling base and subservices
  • Style isolation
  • Js sandbox mechanism
  • Resource preloading
  • Provides a global error mechanism
  • Provide cross-service communication mechanisms
  • The life cycle of providing services
  • Off the pedestal, a single service downgrades running policy processing

disadvantages

  • Shared runtime cache support
  • Not compatible with IE series (although everyone has abandoned IE/Edge, some government projects need to support IE9 +)

4. Micro front end design concept

Centralized routing – Registry

Registries: Service providers must register notification service addresses, and service callers must be able to discover target services.

This is similar to microservices on the back end.

We need to maintain the mapping between routes and services in one place.

Service life cycle

The central service of the micro front end is called the base.

The base needs to control the loading and unloading of services. In this case, the application life cycle of the sub-service is involved.

In terms of the sub-service loading to unloading process, the following needs to be included:

  • The subservice load is initialized
  • The child service is rendered
  • The subservice is uninstalled
  • Child service update event

Independent deployment

After large applications split multiple sub-applications, each sub-application is an independent service, which can generate docker images independently and access CI/CD independently.

Independent development, independent operation

An important consideration for the micro front end is that a sub-service can run in two ways.

  1. Local development time
  2. Online running time

For 2, when running on line, that is, it is connected to the micro front end system and controlled by the base uniformly.

But for 1, local development, not necessarily dock debugging, may be a pure sub-service. That is, the micro front-end, which needs to consider the service degradation operation strategy, can operate without the base.

Micro front-end vs micro services

The design of the micro front end is inspired by the back-end micro services, but it is different from the back-end micro services.

The difference between

    1. Microfronts focus on service aggregation, while microservices focus on decoupling
    1. There are no cross-container service invocations in the microfront because the microfront running environment is the browser. Microservices, on the other hand, have many cross-container service calls, so restful, RPC calls need to be involved.
    1. Following 2, microservices have service discovery, service registries, service registry heartbeat, and dynamic capacity expansion. The micro front end, on the other hand, communicates with multiple applications and is uniformly scheduled through the base, and they are all in the same window environment.
    1. The micro front end has a multi-application sandbox mechanism as well as a style isolation mechanism. Microservices don’t exist, they are all API HTTP calls, there is no sandbox problem.
    1. The micro front end has app Entry issues that require some runtime sacrifice in exchange for efficient update maintenance costs. However, microservices do not have App Entry and provide API HTTP calls externally.
    1. The upper control service of the microfront is the base, and the upper control service of the microservice is the gateway. Although both are upper-level services, their roles are completely different.
    1. Common resources can be shared at runtime in the microfront-end base, which microservices cannot. For example, to solve the problem that N public resources are updated and each sub-service is updated and put online again, the micro front end only needs to update one place, while the micro service needs to update each sub-service.
    1. The micro front end needs to solve the experience problem and has pre-loaded sub-service technology that the micro service does not need.
    1. The operating environment is different. The micro front end is in the browser and the micro server is on the server.

The same

    1. Sub-service support: independently developed, independently run, independently deployed
    1. Both have registries. (although their registry implementation mechanisms are completely different)
    1. An application can be implemented using multiple technology stacks and aggregated at runtime

Six. Micro front end design

@Kuitos don’t hit me. Run

In the next article, I will share the details of the micro front end implementation and the underlying implementation.

Code word is not easy, a lot of praise attention ~