Decrypting the micro front end: Talking about the micro front end ecology

This article can be regarded as a summary of my micro-front-end work in Alibaba. What has not been written is not in detail. It is more like a memo to myself. In many places, because I have been doing it for a long time, the memory is blurred and I will slowly. supplement.

My understanding of micro front end

When we talk about micro front-ends, we often mention a front-end architecture model: a divide-and-conquer solution that disintegrates the front-end "monolithic application". But in my opinion, with the widespread use of micro front-ends in enterprise-level mid- and back-end applications, when we talk about micro front-ends, we have derived a complete set of front-end ecological closed loops (loaders, routing, publishing systems, application plug-ins, etc.). Even after this set of ecological runs smoothly, a complete set of micro front-end solutions can be implemented.

Therefore, my understanding of the micro front end is:

• Front-end architecture
• Ecological closed loop
• solution

And leaving the above-mentioned architectural level cognition aside, I think the first problem that the micro front-end solves is the front-end engineering problem brought about by teamwork/efficiency.

Architecture background

I always think that when we talk about ecological closed-loop or solutions, it will be more convincing to match the architectural background, and it will also allow everyone to understand why we do it in many places.

The first article of the previous micro-front-end series has introduced our project architecture background in detail. Here is a brief review. For details, see "Decrypted Micro-Frontend: The Birth of "

Template architecture

Disadvantages:

• The back-end analyzes the template and mounts the template;
• The back-end controls routing, the front-end loses control over routing, and it is difficult to control routing rules for multiple teams;
• The main and sub-application scopes are not isolated;
• Each front-end release needs to release static resources first and then release the template, which is cumbersome and error-prone;

iframe architecture

Appeal:

• Need not to rely on the back-end template;
• Need to control routing and formulate unified routing rules;
• Sandbox isolation of main and sub-applications;
• Try to minimize the changes to the sub-business as much as possible, because many businesses have heavy burdens;
• Land quickly and achieve high availability;

Disadvantages:

• The communication method is simple, and the simple postmessage API cannot meet the needs of the business;
• Fragmentation of styles, iframes will cause global masks such as Dialog to be displayed only in the ifame block, making our system more like a "patch together";
• Performance bottleneck, routing switching will cause reloading of sub-applications in iframe, performance is worrying;
• Cross-domain issues, the samesite policy of chrome80 will cause the cross-domain cookies of the iframe scheme to fail to be brought to the backend;

Micro front-end architecture

Appeal:

• Change cost
• Sandbox isolation;
• Iframe compatible;
• Route invariance;
• Communication immutability;
• Grayscale control, disaster tolerance and degradation;
• Adapt to three terminals: pc, desktop terminal, POS machine;
• There are scenarios for sub-applications to be put on different platforms. As far as possible, the sub-applications should be unaware of the delivery platform and the host environment;
• Compatible build platform;

Industry pain points

Here I communicated with other teams in Ali when I was building the micro-front-end ecosystem, and collected the pain points encountered by other teams in the process of building the micro-front-end ecosystem:

• The micro front-end ecosystem needs to be adapted to build a system;
• Need to be compatible with icestark, qiankun, singleSPA;
• Compatible with the existing iframe architecture and iframe ecology;
• Large business volume and high stability requirements;
• Adapt to the existing front-end infrastructure (release system, embedded point system, monitoring system);

Our construction related to the micro front-end ecology

Micro front-end framework

Our technology selection of micro front-end framework was qiankun, and the selection goal at that time was relatively simple and rude:

• Simple access and less intrusion: I don’t want to access a new solution to directly reconstruct the old system;
• Compatible with iframe ecology: a relatively mature ecosystem already exists, and nearly a hundred sub-applications have been integrated;
• There is not enough manpower to build/maintain a free micro front-end framework: I am the only manpower, and I do not encourage re-creating wheels;

In my opinion, as the final link in the micro-front-end ecosystem, the micro-front-end framework should integrate the most core functions:

• Sub-application loading
• Sandbox isolation
• Route hijacking
• Inter-application communication

The first three points are the capabilities provided by the adopted framework itself, and we have adopted a self-built solution for inter-application communication.

Why build your own communication model?

In fact, the communication solution provided by the framework side can basically meet most business scenarios, but we again have higher demands on the basis:

• There are relatively mature iframe communication solutions, can they be compatible with iframe solutions, and reduce the cost of iframe application transformation;
• Can it support free switching under the two access schemes of iframe and micro front end without any perception of sub-applications;

To this end, based on the iframe communication model, we encapsulated the publish-subscribe model of the micro front end based on the host environment judgment, and adopted the exact same API, so that the sub-application no longer cares about its own access method and host environment.

Application management

Route management

Before talking about application management, I want to talk about routing management. For large-scale B-side systems, a set of reasonable routing rules is extremely important, especially our system is for external use:

• Rules need to be established in the early stage, and cannot be changed casually according to their temperament. Many users directly save the corresponding page link;
• There are scenarios where there are cross-application routing jumps between sub-applications, and reasonable routing rules are also convenient for cross-application routing control and routing management;
• We also need to do coarse authority control based on routing;

First of all, under routing constraints, I have adopted the following rules: /:platform/:privilegeKey/:childHash

• platform: platform: pc, desktop, pos;
• PrivateKey: Privilege point, which has an n-n relationship with the sub-application microKey;
• childHash: The actual hash of the child application. When registering as a microfront terminal application, you need to use /:platform/:privilegeKey as the basePath;

Sub-application version control

For domestic mainstream micro front-end solutions, two ways of access are provided:

• entry: directly configure the html link of the sub-application, frame test and analyze the sub-application html and implement resource injection;
• Resource configuration: configure js, css and other cdn resources to realize resource injection;

These two methods determine how the publishing system cooperates with our micro front-end ecology. Here we adopt the first solution.

Why use entry mode?

• There are scenarios where sub-applications are put on multiple service platforms. You cannot give up other applications because of access to one set of solutions. The entry form also gives sub-applications the ability to run independently as applications -;
• Sub-application grayscale: html entry naturally exists version control in the publishing platform;

Disaster tolerance (emergency strategy)

In the case of disaster tolerance downgrade, because we already have a relatively mature iframe ecosystem, and the micro front-end solution has been backward compatible in many places when I designed it, so we are downgrading to disaster tolerance. In the iframe solution, the scene where the iframe is still abnormal can only be covered by monitoring and alarming.

• Downgrade iframe

  • Hot downgrade: automatically downgrade the iframe by catching mounting errors;
  • Cold downgrade: manually remove the micro front end configuration downgrade iframe;

• monitor

  • Micro front-end configuration loading monitoring;
  • Sub-application mounting success rate monitoring;
  • Abnormal capture and monitoring within the sub-application;

Sub-application empowerment

In my opinion, sub-application empowerment is an indispensable part of the micro front end. The following mainly introduces some of what I have done in sub-application empowerment.

Communication model

The communication model has been briefly mentioned above, so I won't go into details here.

Automatic burying point

It is meaningless for the main and sub-applications to mount the embedded point SDK at the same time. The setting will increase the data "noise", so only the main application needs to mount the SDK. Here I have done a secondary package based on the group’s embedded point SDK, mount the embedded point SDK when the main application is ready, and use the current microKey as the embedded point of the embedded point’s id aggregation sub-application, and open the embedded point to the sub-application Invoke the event.

In summary:

• Aggregate embedded point SDK;
• Automatic collection of PV / UV;
• Manually trigger the buried point event;
• Buried point expansion: automatic collection of all buried points at the business level;

Exception monitoring

Like the buried point, we also adopt the form of main application mounting for abnormal monitoring, and use microKey for monitoring aggregation. But the difference is that in the monitoring area, we exposed the event of uninstalling the main application monitoring to the sub-app. Different applications of different teams may adopt completely different monitoring systems, and the bottom layer of the monitoring SDK is hijacking native fetch etc. If the incident is to be done, pollution is likely to occur between different SDKs.

Routing center

On the basis of routing rules and authority points, we have also implemented our own routing management and control configuration platform. We closed all the urls of routing jumps between sub-applications and replaced them with sub-applications in the form of routing events + schema. The sub-application's own link only needs to be synchronized to the routing center when the business is iterated, and there is no need for other sub-applications to update the routing link synchronously.

Other empowerment

There are still many capabilities customized according to our business domain, so I won’t elaborate on them one by one:

• Multi-instance mounting of single sub-business domain;
• Sub-application background suspension, keepalive, keepalive;
• Different browser access behaviors: open a new page, redirect (without brush), redirect (refresh);
• Adaptation layer of different platforms: pos, desktop, browser;
• ...

At last

Finally, let's briefly talk about the best practices of micro front-ends that I personally think:

• Large-scale B-end system, involving multiple business domains, multiple team maintenance, low coupling between sub-businesses, and clear business boundaries;
• You cannot require too many sub-applications, but not too few. One or two sub-application micro-front ends lose their value, or there are more suitable alternatives;
• The team can no longer tolerate the pain points caused by iframes or other alternatives;
• The micro front end will be accompanied by the production of supporting peripherals, so consider the ROI;