Reliably Access Micro Frontend

By Fengshui

A micro frontend brings many benefits and challenges. How can we access a micro frontend based on the current technology stack? What common functions are required? How can we resolve the plug-in mechanism? This article describes a micro frontend access solution and implementation details.

Preface

The micro frontend concept has reached news headlines several times in China, and the problems it solves are prominent. However, these challenges mentioned in the micro frontend are significant when our team maintains projects.

"The micro frontend is some framework with some technology."

This statement shows limitations, which can be assumed as opinions of a layman trying to follow the tide. In my projects, mass stock technology stack and pages have been operating online. Any iteration and upgrade must be careful and safe. A micro frontend brings the benefits of user experience and technical maintenance to a certain extent, but the business value cannot be quantified. It needs guidelines to implement this technology. It is expected to respect stock technology stacks and isolate the basic elements of controllable influence ranges. Then, the implementation of a micro frontend solution is considered.

Based on the information above, you need to fully understand the technical solution and proportion in the current transformation site to implement this new technology. You should also be aware of capability differences provided by existing mature micro frontend frameworks. Mechanic application should be avoided.

Background

The projects maintained by my team are operated by PC background through workstations. This could lead to problems if they are with different partners in different countries or different time zones.

The developers creating a new page may come from different teams. Thus, it is difficult to ensure the unification of styles in multiple management pages, design specifications, components, and interaction behaviors during the fulfillment of existing requirements.

When the business is migrated to another workstation, it still requires logic consistency with differences in navigation bars and themes. Existing stock solutions use Java to directly HTML using templates. After generations of iteration, pages generated by various technology stacks already exist in different systems.

Although pages were implemented by React, none of them were in the form of conventional React components since the former developers were very capable. For example:

Most of the pages are configured and generated by JSON with consumption components.
Some pages are configured and generated by another team's JSON with consumption components, which is completely different from the JSON above.
Other pages are loaded through the JS Bundle provided by a page publishing platform.

Developers have no choice but to work out a reliable implementation solution when facing a technical background.

Solution and Flowchart

Firstly, analyze the common features that need to be loaded on all of the pages on the site:

The figure above shows the simplified common features. Brief introductions are listed below:

Layout Loader: Load navigations for different workstations
DADA Loader: Load pages configured by JSON
Source Code Loader: Load JS Bundle
Micro Loader: Process micro frontend loading
Log Report: Track logs
Time Zone: Switch time zones
i18n: Switch languages
Guider: Unified control of user guides

The additional extension capabilities on the pages are listed below:

Security Monitoring
Traffic Control
Pop-Up Window Control
Questionnaires
QA Robot

After rough classifications, the general loading processes of a page is listed below:

Implementation Details

Based on the preceding loading idea, the page loading path is converged first. This ensures the loading entries of all pages are under a unified loader. Then, the load life cycles of all pages are systematically processed.

While converging, it is also necessary to keep the core loading path plug-in open, in order to support different extension capabilities and render technology stack access at any time.

1. Plug-In Mechanism

In the main path, the loader loads configurations for processing, and configurations provide context. Then, configurations are transmitted to the plug-in for consumption. The process is shown listed below:

Take an independent sub-application of JS Bundle as an example:

<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>

With the preceding plug-in, it's possible to enable and consume different configurations.

The introduction of Layout Plugin consumes the hfType field and then loads the corresponding Layout resource to provide for the Container for the next phase.

According to the configuration, if the micro frontend is enabled on the current page, Micro Loader will consume the provided Container and create a sandbox. In this case, it is based on qiankun. Then, Micro Loader provides a Container.

Finally, Container is submitted to the SourceCode Plugin for Bundle loading, running, and rendering. Developers can hand it over to a different plug-in for Container consumption according to different configurations with another rendering protocol or technology stack.

In this process, the plug-in of each link is independent and pluggable. For example, without loading the Layout Plugin, the hfType field can't be consumed, and the Layout plug-in logic can't be injected into the getContainer method. Then, the Container is rendered directly through the outermost layer with no corresponding menu presented. Without Micro Plugin, no micro frontend logic is injected, no sandbox is created, and the page rendering process continues to run in normal mode.

2. Secure Migration

For our projects, a one-size-fits-all solution is unfeasible. For existing stock pages, it requires a full analysis of the current stock technology stack:

For the stock pages above, they should be deployed online from left to right in batches at a page-level. For the left part, some projects need modifications before being deployed for online access.

This migration testing needs to work out an automated end-to-end (E2E) testing process and sort out the micro frontend registry through batch migration. With these two types of process and scope control, the content delivered in the current solution is completely controllable. The remaining parts are repetitive tasks with quantified coverage.

3. Micro Frontend Form

According to the solution above, the expected micro frontend forms are listed below:

Each page that enables the micro frontend can be a primary application.
The micro frontend is an optional plug-in. Any business exceptions that occur due to the micro frontend can be closed at any time.
Switching between the micro frontend page routers can achieve partial refresh, while non-micro-frontend registries pages are redirected directly. As the coverage of the micro frontend pages increases, partial refresh also rises gradually.
Use different extension plug-ins to load the stock pages of different technology stack types and convert them into corresponding sub-applications.

The registration and call paths in SchemaResolver are listed below:

Summary

The outstanding thoughts behind the micro frontend are the key to solving specific problems. This technology brings values only when specific business problems are solved. Don't be too goal-oriented. Currently, SchemaResolver provides different opening capabilities tailored to roles:

For platform administrators, it provides the plug-in capability to enable global scalability.
For page developers, it provides standard access solution paths, multiple technology stack access, and other capabilities, including the micro frontend, multi-language, tracking, menus, and theme loading. It also decouples the common capabilities of different systems, which allows quick migration of specific business logic to other platforms.
For third-party users, it provides unified access criteria through the isolation technology stacks of the micro frontend and isolated sub-application styles, without learning about system menus or access methods of themes. It migrates to corresponding platforms to see the page conditions of the site globally through unified page system control.

Community

Reliably Access Micro Frontend

Preface

Background

Solution and Flowchart

Implementation Details

1. Plug-In Mechanism

2. Secure Migration

3. Micro Frontend Form

Summary

Read previous post:

Read next post:

Yee

You may also like

Comments

Yee

Related Products

Super App Solution for Telcos

DevOps Solution

ACK One

Container Registry