Micro front end is a popular concept recently, there are many articles about the practice of micro front end, but the overall look will still have a face of meng feeling, because there are many scenes, many concepts, and more complex technical solutions. Here I hope to be able to do an overall combing of the background and scheme of the micro front end.

What?

Why is a microfront called a microfront? It is mainly compared with the microservice on the server side, which is to split the large application into smaller independent services, while the microfront-end can be understood as the front-end module resources that can be dynamically loaded. This is a wide range and can be thought of as a generalized micro front end.

Why?

Why do a micro front end? Or what problem is the micro front end trying to solve?

In fact, there is more than one answer to this most basic question. Single-spa, the originator of microfront-end, initially solved the problem of using new front-end technology stack in old projects. At the present stage, another major problem that the microfront-end announced by Ant Financial Micro Front-end Framework Qiankun wants to solve is the difficulty of boulder project maintenance and collaborative development. The two goals are basically the same. The main goal is to decouple large projects. That’s the main problem we’re trying to solve with the micro front end as a technical solution, and that’s what I think of as the narrow micro front end scope. The corresponding problem of the generalized microfront-end scope is the dynamic reference (runtime loading) of components or modules, which is relatively small in granularity and aimed not at system-level splitting but at integration.

In addition, when it comes to front-end system splitting and dynamic loading, the fundamental question is “Why not use iframe?” The answer is available on Qiankun’s website.

How?

How does the micro front end work?

We mainly aim at the narrow micro front end, that is, to decouple large projects. There are two basic problems:

  1. Do sub-applications need to be isolated from each other and support technology stack disunity? This is critical, because the current mainstream solution is to choose isolation, if you choose not isolation, it is generally the technology stack unification, integration in component and tool dimensions. For example, the scheme of Meituan Takeout has a high degree of coupling between the master and sub-projects (routing loading convention, component dynamic loading convention, store loading convention, shared components and tools, etc.) and high maintenance cost, which, to some extent, goes against our original intention to reduce maintenance difficulties of boulder engineering. But this is also its advantage, the degree of integration and reuse between sub-projects can be higher.
  2. When does the subapplication load? Route switchover or manual loading? For now, most of the scenarios involve switching between sub-apps by changing the route through the switching menu. Manual loading is rare, but there are scenarios, and the new version of Single-Spa-based Parcel offers this support.

Let’s take a look at the three most critical questions that a typical micro front-end solution needs to answer:

  1. How are subapplications defined and used?
  2. How to load dynamically?
  3. How to isolate?

Single-spa

Single-spa, which came out a few years ago, solves the first problem. Here’s a look at its use.

As you can see, the key API is registerApplication, which needs to be passed in to the app, which is usually a function that returns a promise. The resolve value needs to contain sub-application lifecycle methods such as mount, unmount, and bootstrap. This design is quite imaginative. As long as it conforms to this rule, we can realize this function by ourselves and add our own rules, which is exactly what Qiankun did.

Another parameter, activeWhen, is the rule for loading subapplications based on routes. Single-spa listens for route changes and hijacks the change native method to apply route judgment logic. Part of the code is as follows:

window.addEventListener("hashchange", urlReroute);
window.addEventListener("popstate", urlReroute);
window.history.pushState = patchedUpdateState(
  window.history.pushState,
  "pushState"
);
Copy the code

Once the child app is loaded, single-SPA maintains an instance of the child app and uses it directly when it is activated again.

Single-spa mainly solved the first of the three problems, but with no specific solutions for the second and third, Qiankun filled the gap.

Qiankun

First let’s see how it’s used:

In this way, Qiankun solved the remaining two problems — loading and isolation — and became a complete microfront-end solution.

Of course, in addition to these three primary issues, there are also secondary issues that need to be addressed, such as: How do you share the base libraries? How does the sub-app intertune with the main app? And so on. As more and more teams are working on the micro front end concept, Qiankun is improving. Here are the new features and future plans.

Finally, I would like to say that the micro front end is not a silver bullet, it is only a solution to solve specific problems, and has its own disadvantages, such as the ali Cloud summary in the following figure. So if you don’t have the pain points mentioned in this article, don’t bother trying.