This article can be regarded as a summary of my work in Ali as a micro front end. It is more like a memorandum of my own rather than a detailed description. I will gradually supplement many aspects because I have been doing it for a long time and my memory is blurred.

My understanding of the micro front end

When we talk about microfronds, we often talk about a front-end architecture model: a divide-and-conquer solution that disrupts the front-end “monolith” of applications. 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.

So my understanding of the micro front end is this:

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

Regardless of the architecture, I think the first problem that the micro front end solves is front-end engineering caused by teamwork/efficiency.

Architecture background

I always think that when we talk about ecological closed-loop or solutions it’s more persuasive to work with the architectural context, and to understand why we do it in many places.

The first article in the micro Front End series gave a detailed background on our project architecture. Here’s a quick review. For details, see “Unlocking the Micro Front End: The Birth of the” Monolith Application “.

Template architecture

Disadvantages:

• Back-end parse templates, mount templates;
• The back-end controls routing, while the front-end loses control of routing, and it is difficult for multiple teams to control routing rules.
• The master and child application scopes are not isolated;
• Each front-end release needs to release static resources and then release templates, which is tedious and error-prone.

The iframe architecture

Appeal:

• Need to be independent of back-end templates;
• Routes need to be controlled and unified routing rules should be formulated.
• Sandbox isolation for master applications;
• Try to minimize the changes to the sub-business, many business burden is very heavy;
• Fast landing and high availability;

Disadvantages:

• The communication mode is simple, and the simple PostMessage API does not meet the needs of the business;
• Split styles. Iframe causes global masks such as Dialog to be displayed only within the ifame block, making our system more like a “patchwork”;
• Performance bottleneck, route switching will lead to iframe child application reload, performance is worrying;
• Cross-domain problems. Chrome80’s Samesite policy causes cross-domain cookies of iframe scheme to fail to be brought to the back end.

Microfront-end architecture

Appeal:

• Modification cost;
• Sandbox isolation;
• Compatible with the iframe;
• Routing invariance;
• Communication invariance;
• Gray scale control and disaster recovery degradation;
• Suitable for three terminals: PC, desktop and POS;
• There are scenarios for sub-applications to be put on different platforms, so that the sub-applications have no perception of the platform and the host environment as far as possible.
• Compatible building platform;

The pain points

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

• Micro-front-end ecology needs to adapt to the building system;
• Compatible with ICestARK, Qiankun and singleSPA;
• Compatible with existing IFrame architecture and iframe ecology;
• Large business volume, high stability requirements;
• Adapt existing front-end infrastructure (release system, buried system, monitoring system);

We are eco-related in micro front end construction

Microfront-end framework

The selection of micro front end frame was qiankun. At that time, the selection target was relatively simple and crude:

• Simple access and less intrusion: I don’t want to connect a new scheme to reconstruct the old system directly;
• Compatible with IFrame ecology: there is a mature ecosystem and nearly 100 sub-applications have been accessed.
• There is not enough manpower to build/maintain a free micro front end framework: I am the only manpower and duplication of wheels is discouraged;

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

• Subapplication loading
• The sandbox isolation
• Routing hijacked
• Interapplication communication

The first three are the capabilities provided by the framework itself, while inter-application communication we use a self-built solution.

Why build your own communication model?

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

• If there is a mature IFrame communication scheme, can it be compatible with iframe scheme and reduce the cost of iframe application transformation?
• Whether it can support free switching under iframe and micro front-end access schemes without sensing sub-applications;

Therefore, based on the IFrame communication model, we judge the publish-subscribe model that encapsulates the micro front end based on the host environment, adopt the same API, and the sub-application no longer cares about its own access mode and host environment.

Application management

Routing management

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

• Early need to set good rules, can not be casually changed, many users are directly saved the corresponding page link;
• There are scenarios where routes jump between sub-applications. Proper routing rules facilitate route control and route management across application levels.
• We also need to have strong permission controls 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: indicates the permission point, which has an N-N relationship with subapplication microKey.
• Childhood: Childhood applications that registered as micro front terminals with /:platform/:privilegeKey as basePath;

Sub-application version control

For domestic mainstream micro front-end solutions, access is provided in two ways:

• Entry: Directly configure the HTML link of the sub-application, framework test analysis and analysis of the sub-application HTML and achieve resource injection;
• Resource configuration: Configure CDN resources such as JS and CSS to implement resource injection.

These two approaches determine how the publishing system fits into our micro-front-end ecosystem, and we’ve taken the first approach here.

Why entry mode?

• Sub-applications may be placed on multiple business platforms. Therefore, access to one solution cannot give up other applications. Entry form also gives sub-applications the ability to run independently as applications.
• Sub-application gray scale: HTML Entry has natural version control in the publishing platform;

Disaster Recovery (Emergency Policies)

In the aspect of DISASTER recovery degradation, because we already have a relatively mature IFrame ecology, and the micro front end scheme has made many downward compatible strategies when I designed it, so for disaster recovery degradation, we are downgraded to iframe scheme, and for the iframe still abnormal scenarios, we can only use monitoring and alarm to provide the bottom.

• Drop the iframe
  • Hot degrade: Automatically degrade iframe when catching mount errors;
  • Cold downgrade: Manually remove the iframe of the micro front-end configuration.
• monitoring
  • Micro front-end configuration loading monitoring;
  • Sub-application mount success rate monitoring;
  • Sub-application internal exception capture monitoring;

Subapplication enablement

In my opinion, sub-application enablement is an integral part of the micro front end, and I will mainly introduce you to some of the things I have done in sub-application enablement.

Communication model

The communication model has been briefly mentioned above and will not be described here.

Automatic submerged point

It does not make sense for the host app to mount the buried SDK at the same time. Setting this will increase data “noise”, so only the host app needs to mount the SDK. I have made a secondary encapsulation based on the buried point SDK of the group. When the main application is ready, the buried point SDK is mounted, and the current microKey is used as the ID of the buried point to aggregate the buried point of the sub-application, and the events of the buried point are opened for the sub-application.

To sum it up:

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

Abnormal monitoring

Like buried points, we also use the form of main application mount for anomaly monitoring, and use microKey for monitoring aggregation. However, the difference is that in the monitoring part, we exposed the event of uninstalling the monitoring of the main application to the sub-response. Different applications of different teams may adopt completely different monitoring systems, and the underlying monitoring SDK is hijacked 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 routing links synchronously.

Other assigned to

There are also a number of capabilities tailored to our business domain that I won’t go through in detail:

• Monad business domain multi-instance mount;
• Sub application background suspend, keepalive, keepalive;
• Different browser access behaviors: open a new page, redirect (brushless), redirect (refresh);
• Adaptation layer for different platforms: POS, desktop and browser;
• .

The last

Finally, a brief summary of what I consider to be micro front-end best practices:

• Large-scale B-terminal system, involving multiple business domains, multi-team maintenance, low coupling degree between sub-services, clear business boundary;
• Not too many, but not too few, and one or two sub-application microfronts lose their value, or have more suitable alternatives;
• The pain points of iframe or other alternatives are intolerable within the team;
• The micro front end will be accompanied by supporting the surrounding production, considering ROI;