This article can be regarded as a summary of my work on the micro front in Ali. It is not written in detail, but more like a memorandum to myself. In many places, my memory is blurred because I have been doing it for a long time, and I will add it slowly.

My understanding of the micro front end

When we talk about micro front-ends, we tend to talk about a front-end architecture pattern: a divide-and-conquer solution that breaks down the “boulder application” of the front-end. However, in my opinion, as the front-end backend application widely used in the enterprise, we are talking about micro front-end has been derived to a whole set of front-end ecological closed-loop (loaders, routing, publishing system, application of plug-in, etc.), even after the ecological running smoothly can be born out of a set of micro front-end solutions.

Therefore, my understanding of the micro front end is:

• The front-end architecture
• Ecological closed-loop
• The solution

In my opinion, the primary problem to be solved by Micro Front-end is the front-end engineering problem brought about by teamwork/efficiency.

Architecture background

I’ve always thought that when we’re talking about ecological closed loops or solutions, it’s much more persuasive in terms of the architectural context, and it helps people understand why we’re doing this in a lot of places.

The first article in the micro front end series covered the architectural background of our project in detail. Here is a brief review. For more details, see Deciphering the micro front end: The birth of the “boulder application”.

Template architecture

Disadvantages:

• Back-end parsing templates, mount templates;
• The back end controls routing, while the front end loses the right to control routing, and it is difficult for multiple teams to control routing rules.
• Master application scope is not isolated;
• Each front-end release needs to release the static resources first and then release the template, which is tedious and error-prone.

The iframe architecture

Appeal:

• Need to be independent of the backend template;
• It is necessary to control the routing and formulate uniform routing rules.
• Sandbox isolation for master application;
• Try to minimize the changes to the sub-business, many business burden is heavy;
• Fast landing and high availability;

Disadvantages:

• The communication mode is simple, and the simple PostMessage API cannot meet the needs of the business;
• Style-splitting, iFrame causes global masks such as Dialog to be displayed only within iFame block, making our system more “patchwork”;
• Performance bottlenecks. Routing switches can cause child applications in iframe to reload, causing performance problems.
• Cross-domain issues. Chrome80’s Samesite policy causes cross-domain cookies for iframe schemas to not be sent to the back end.

Micro front-end architecture

Appeal:

• Change cost;
• Sandbox isolation;
• Compatible with the iframe;
• Routing invariance;
• Communication invariance;
• Gray control, disaster reduction;
• Adapt to three terminals: PC, desktop, POS machine;
• There are scenarios for sub-applications to be launched on different platforms. As far as possible, the sub-applications should have no perception of the platform they are launched on and the host environment.
• Compatible building platform;

The pain points

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

• Micro-front-end ecology needs to adapt to the construction system;
• It needs to be compatible with ICESTARK, QIANKUN and SINGLESPA;
• Compatible with existing iframe architecture and iframe ecology;
• Large business volume, high stability requirements;
• Adapt the existing front-end infrastructure (release system, burial system, monitoring system);

We are on the micro front end of ecologically related construction

Micro front frame

Our technical selection of the micro front-end framework was QIANKUN, and the selection target was relatively simple and crude:

• Access is simple and less intrusive: I don’t want to access a new scheme to directly reconstruct the old system;
• Compatible with iframe ecology: there is a relatively mature ecosystem, and has been connected to nearly a hundred child applications;
• There is not enough manpower to build/maintain the free micro front frame: I am the only manpower and duplicate wheels are not encouraged;

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

• Child application loading
• The sandbox isolation
• Routing hijacked
• Interapplication communication

The first three are capabilities provided by the framework itself, while we use our own solutions for inter-application communication.

Why build your own communication model?

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

• There are already mature iframe communication schemes, can they be compatible with iframe schemes to reduce the cost of iframe application renovation;
• Whether it can support free switching between two access schemes of iframe and micro front end without child application awareness;

For this reason, based on the iframe communication model and the host environment judgment, we encapsulate the publish and subscribe model of the micro front end, adopt the exact same API, and the sub-applications no longer care about their own access mode and host environment.

Application management

Routing management

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

• The early need to set the rules, can not be changed with the temperament, many users directly saved the corresponding page links;
• There are scenarios of inter-application routing jump among sub-applications. Reasonable routing rules are also convenient for cross-application routing control and routing management.
• We also need to do rough access control based on routing;

Here in the first place in the routing constraints, I took the following rules: / : platform / : privilegeKey / : childHash

• Platform: PC, Desktop, POS;
• PriviateKey: Permission point, which has an n-n relationship with child application microKey;
• /:platform/:privilegeKey as basePath /:platform/:privilegeKey

Subapplication version control

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

• Entry: Configure the HTML link of the child application directly. The framework analyzes the HTML of the child application and implements resource injection.
• Resource configuration: configure JS, CSS and other CDN resources to achieve resource injection;

These two approaches determine how the publishing system fits into our micro-front-end ecosystem, and here we take the first option.

Why the Entry model?

• There are scenarios in which sub-applications can be placed on multiple business platforms. You cannot access one solution at the cost of others. The Entry form also gives sub-applications the ability to run independently as an application —
• Subapp Grayscale: HTML Entry is naturally version-controlled on the publishing platform;

Disaster Recovery (Emergency Response Strategy)

In terms of disaster recovery and degradation, since we already have a set of mature iframe ecology, and the micro front end scheme has made a strategy of downward compatibility in many places when I designed it, the disaster recovery and degradation is to downgrade to the iframe scheme, and the scene where the iframe is still abnormal can only be covered by monitoring and alarming.

• Drop the iframe

  • Thermal degradation: Catch mount errors to automatically degrade iframes;
  • Cold demotion: manually remove the micro-front end configuration to demotion the iframe;

• monitoring

  • Micro-front-end configuration loading monitoring;
  • Sub-application mount success rate monitoring;
  • Child application internal exception capture monitoring;

Child application enablement

In my opinion, sub-application enabling is an integral part of the micro front end, so here’s what I’ve been doing with sub-application enabling.

Communication model

The communication model has been briefly mentioned above, so I won’t repeat it here.

Automatic submerged point

It does not make sense for the host application to mount the buried SDK at the same time. Setting this up increases the data “noise”, so only the host application needs to mount the SDK. Here, I do a secondary package based on the group’s buried point SDK, mount the buried point SDK when the main application is ready, aggregate the buried point of the child application with the current MicroKey as the buried point ID, and call events for the open buried point of the child application.

To sum up:

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

Abnormal monitoring

As with buried points, exception monitoring takes the form of a main application mount and is aggregated with MicroKey. However, the difference is that in the monitoring part, we expose the events of uninstalling the monitoring of the main application to the sub-application. Different applications connected to different teams may adopt completely different monitoring systems, while the underlying monitoring SDK is all done by hijacking the fetch and other native events, so pollution is likely to occur between different SDKs.

Routing middle

Based on routing rules and access point, we also fell to the ground his own routing control configuration platform, we or the url of all child routing jump between applications, replacing + schema for according to the routing event application form, let the child calls, so in the application has its own links with business iterative time only need to be synchronized to the routing middle office, There is no need for other child applications to update the routing links simultaneously.

Other assigned to

There are also a number of capabilities that are customized for our business domain, and I won’t go through them all:

• Single business domain multi-instance mount;
• Child application background hang, KeepAlive, keepalive;
• Different browser access behaviors: open new page, redirect (brushless), redirect (refresh);
• Adaptation layers for different platforms: POS, desktop, browser;
• .

The last

Finally, a brief list of what I consider to be best practices for micro front-ends:

• Large B-end system, involving multiple business domains, multi-team maintenance, low coupling degree among sub-businesses and clear business boundaries;
• You can’t ask for more subapplications, but you can’t ask for too few subapplications, where one or two subapplications lose the value of the micro front end, or there are more suitable alternatives;
• The pain points caused by iframes or other alternatives are intolerable within the team;
• The micro front end will be accompanied by supporting peripheral production, considering the ROI;