I. Introduction
The concept of micro-front-end has been on major hot topics more than once in China, and the problems it solves are also obvious. The pain points mentioned in these micro-front-ends are also very prominent in the projects maintained by our team.
But I always believe that a new technology, wave, and the most popular one must be the outstanding thinking behind him.
"The micro front end is... xx framework, xx technology"
This kind of remarks kind of limits this outstanding way of thinking. I can only think of him as a layman to rub the popularity of the word.
In the projects and teams I am responsible for, there are already a very large stock of technology stacks and pages that are already running online, and any iterative upgrade must be careful and foolproof.
It can be said that, to a certain extent, these benefits brought by micro-front end are in terms of user experience and technical maintenance, and the value to the business cannot be quantified. The implementation of this technology has both the guidance and the guidance. policy.
We must maintain awe, isolation, and controllable basic elements of the stock technology stack, and then consider implementing the micro front-end solution.
Therefore, under these basic elements and guidelines, in order to implement this new technology, you must fully understand the current technical solutions and proportions of the current transformation site, as well as the current mature micro-front-end frameworks. .
Two backgrounds
The projects that my team maintains are all PC operating backgrounds (workstations). These workstations will have problems in different countries, different time zones, and different partners.
If you need to develop a new page requirement, it is likely that the developers involved are from different teams. At this time, we need to complete the existing requirements while ensuring that the styles of multiple management pages are unified, the design specifications are unified, and the components are unified. It is very difficult to unify the interaction behavior.
When the business needs to be migrated to another workbench, although the logic needs to be consistent, the navigation bar, themes, etc. are different.
The current stock solutions are to use Java to directly render HTML by using Template. After the iterations of previous generations of predecessors, there are already several pages produced by different technology stacks in different systems.
Although they are all implemented in React, the predecessors are very capable of tossing, and none of them are developed in the form of regular React components.
such as:
- Most of the pages are configured through a JSON, the page generated by the consumer component.
- Some pages are generated by the JSON configuration consumer component defined by another team, which is completely different from the above JSON.
- There are also some pages that are loaded through a JS Bundle provided by a page publishing platform.
In the face of such a technical background, in addition to shouting MMP with a smile and tearful words that I don't understand (existence is reasonable, what should you do?), you have to come up with such a landing plan in a down-to-earth manner.
Three plans & flow chart
First of all, it is necessary to clearly analyze the general characteristics of all pages on the site that need to be loaded:
The above are some general functional features after streamlining, here is a brief introduction:
- Layout Loader: used to load navigation of different workbenches
- DADA Loader: used to load the JSON configuration page
- Source Code Loader: used to load JS Bundle
- Micro Loader: used to handle micro front-end loading
- Log Report: used for log burying points
- Time Zone: Used to switch the time zone
- i18n: Used to switch multiple languages
- Guider: for unified management and control of user guidance
In addition, the following page expansion capabilities may also exist:
- Security Monitoring
- Flow control
- Pop-up control
- Questionnaire
- Question answering robot
Looking at the rough unified classification, the general loading process of the page should be like this:
Four implementation rules
Based on the above-mentioned loading idea, the first thing that needs to be done is to close the page loading path. It is necessary to ensure that the loading entry of all pages is under a unified Loader, and then the loading life cycle of all pages can be handled systematically.
While converging, it is also necessary to remain open, to maintain plug-in openness to the core loading path, to support different expansion capabilities at any time, and to access the rendering technology stack.
1 Plug-in mechanism
Therefore, on the main path, the configuration is loaded by Loader for processing. This configuration provides context in the main path, and then is handed over to the plug-in for consumption, as shown in the figure:
For example, take an independent JS Bundle type sub-application:
<div id="root"></div>
<script src="https://cdn.address/schema-resolver/index.js"></script>
<script src="https://cdn.address/schema-resolver/plugin/layout.js"></script>
<script src="https://cdn.address/schema-resolver/plugin/source-code.js"></script>
<script src="https://cdn.address/schema-resolver/plugin/micro-loader.js"></script>
<script src="https://cdn.address/schema-resolver/plugin/i18n.js"></script>
<script>
SchemaResolver.render(
{
micro: true,
host: "dev.address",
hfType: "layout1",
externals: ["//{HOST}/theme1/index.css"],
// host is cdn prefix, the resource maybe in different env & country
resource: {
js: "/index.js",
css: "/index.css",
},
},
{ container: document.querySelector("#root") }
);
</script>Through the introduction of the above Plugin, different configurations can be opened and consumed.
The Layout Plugin is introduced here, which consumes the hfType field and then loads the Layout resource to provide the Container to the next link.
According to the configuration, if the micro front end is enabled on the current page, the Micro Loader will consume the provided Container, then establish a sandbox (here based on qiankun), and then provide the Container.
Finally, it is handed over to SourceCode Plugin for Bundle loading, running and rendering. If this is another rendering protocol or technology stack, it can be handed over to different plug-ins to consume the Container according to different configurations.
In this process, the plug-ins of each link are independent and pluggable.
such as:
If the Layout Plugin is not loaded, the hfType field will not be consumed, and the Layout plug-in logic will not be injected into the getContainer method, then the Container under the outermost layer will be directly rendered, and there will be no menu related reveal .
If Micro Plugin is not loaded, there will be no logic injection of the micro front end, and no sandbox will be established. Then the page rendering process will continue to run in the normal mode.
2 Safe migration
For the projects that my team is responsible for, there is no one-size-fits-all solution, so for the existing stock page, a complete analysis of the current stock technology stack is required:
For the above stock pages, it is necessary to implement page-level control and online deployment in batches from left to right. For some pages on the left, even some project transformations are needed before they can be deployed and connected.
This type of migration test needs to deal with a set of automated e2e test procedures, and sort out the micro front-end registry at the same time through batch migration.
With these two process guarantees and scope control, the online content of the current plan is completely controllable, and most of the remaining tasks to be processed are more repetitive manual tasks, and the coverage rate can also be quantified.
3 Micro front end form
According to the above plan, the expected micro front-end form will be:
- Every page that opens the micro front end can become the main application.
- The micro front end is an optional plug-in, and it can be closed at any time if there is a business exception caused by the micro front end.
- The page routing of the same micro front end can be switched to each other to realize the partial refresh form, and the page jumps directly to the page in the non-micro front end registry. As the coverage rate of micro front-end pages increases, the coverage rate of partial refresh will gradually increase.
- Through different extension plug-ins, the stock pages of different technology stack types can be loaded and converted into corresponding sub-applications.
The registration and calling paths in SchemaResolver are as follows:
Five summary
Looking at the essence through technology, the outstanding thinking represented by the micro front end is the key to truly solving specific problems. Only when specific business problems are solved can this technology be valuable.
Don't make a micro front end for the micro front end, don't make a small program for the small program.
Currently, through SchemaResolver, different open capabilities can be provided for different roles:
- For platform administrators, provide plug-in capabilities to open global expansion capabilities.
- For page developers, it provides a standardized access solution path, provides multiple technology stack access capabilities, and provides micro-front-end, multi-language, embedded point, menu, theme loading and other capabilities without perception. The common capabilities of different systems are decoupled. At the same time, this approach allows page developers to quickly migrate specific business logic to other platforms.
- For third-party accessors, there is no need to care about system menus and theme access methods, provide a unified access aperture, isolate the technology stack and isolate sub-application styles through the micro front end. Finally, through the unified page system management and control, it is easy to check into the corresponding platform, and at the same time, you can see the situation of the site page globally.
This article is the original content of Alibaba Cloud and may not be reproduced without permission.