Micro front-end heat no longer? The qiankun author has something to say

Author | Jayanin

Guest | Liu Kui

In recent years, with the rapid development of the Internet, the business complexity of many enterprises will rise, and more and more people will participate in the business, which brings serious maintenance costs. In order to solve this problem, the micro front end once became a technology hotspot, and major companies have increased investment in the micro front end. In the face of some problems exposed by the micro front end in the landing practice, many companies have also proposed solutions, such as the qiankun of Ant Group, JD.com's MicroApp and so on.

Micro-front-end is an architectural concept, which is similar to the architecture of microservices, applying the concept of microservices to the browser side, that is, single-page front-end applications from a single single application to an application that aggregates multiple small front-end applications into one. Each front-end application can also be independently developed and deployed independently. The micro front end sounds beautiful, but there will be many questions in the specific landing process: what scenario is suitable for the micro front end, and how to judge the best time to carry out the micro front end? How to split the business most efficiently? Has the micro-front end passed the momentum and how will it develop?

Out of curiosity about the above questions, we specially interviewed Liu Kui, a front-end engineer in the experience technology department of Ant Group, who is also a qiankun author, currently on GitHub, Qiankun Contributor NO.1, a proper open source software enthusiast.

At the same time, Mr. Liu Kui is also a lecturer on the topic of "Practice and Exploration of Micro Front-end Architecture Model" of QCon+ Case Study Club launched in mid-March, bringing the sharing of "Productization Exploration of Ant Micro Front-end R&D Model". Therefore, we interviewed Teacher Liu Kui on the issues related to micro-front-end technology, let's take a look at his practice and thinking.

InfoQ: What kind of work have you been in charge of lately?

Liu Kui: My current work at Ant is mainly divided into two parts: the first part is to work with the team to define the unified micro-front-end development model of Ant. This R&D model is not only to do the research and development of some micro-front-end related basic frameworks and libraries, but also to cover some productized process design in the entire micro-application R&D life cycle. For example, from how a micro-application is created on the internal R&D platform, to how to describe the relationship between the micro-application and other micro-applications, how to clearly express it in the product, to how to achieve the grayscale distribution of the micro-application, and the monitoring and abnormal emergency response capabilities after the final launch. In general, what we are doing is a research and development platform for the characteristics of micro-front-end scenarios.

The second part is based on the current micro-front-end application model, how to apply this set of dynamic mechanisms to other middle office scenarios, and then unify our internal middle office development model in order to solve some of these common problems. For example, page hosting and grayscale for middle-office applications, and multi-environment deployment of applications (public cloud, private cloud), these are the problems that you need to solve regardless of whether you use a micro-frontend.

InfoQ: Have you encountered any difficulties in your daily work at the micro front end? Can you share that specifically?

Liu Kui: From my point of view, there are several typical and often discussed problems in micro-front-end research and development: the first is how do we split a boulder application, what is the granularity and boundary of the split; the second is how to do dependency multiplexing between multiple micro-applications; and the third is how to govern micro-applications.

Let's start with the first question. When doing a micro-front-end split for a boulder application, the most common granularity is to disassemble by page dimension, which is usually fine. But there are also some scenarios, we expect to extract a part of the UI in the page into a micro-application for other applications to directly integrate and reuse, this time will be more entangled, in the end should be dismantled to the big or small? Dismantling is prone to some combination scenarios that are not easy to reuse, resulting in code redundancy, and dismantling smaller may lead to special trouble in collaboration between micro-applications, which reduces development efficiency.

This actually involves a problem, that is, how do we divide the service boundaries of microapps. A more reasonable way is to divide according to service integrity to see if the microapp can provide a service independently and completely. Not just from the perspective of the front-end component, to see if the UI is reusable. There is a simple evaluation method: see if your microapp needs to communicate frequently with other microapps? If the answer is yes, then you may need to consider whether the granularity of the split is too fine.

The second problem, and one that the community often discusses: how to do dependency multiplexing between microapps. In fact, in most cases, this is a pseudo-proposition, because multiplexing dependencies lead to implicit coupling between microapps, which in turn causes microapps to evolve independently, which is contrary to micro-front-end architectures. However, at present, this problem is not insoluble, based on esm/bundless and other means, we can achieve micro-applications to run independently to use their own dependencies, and when integrated, as far as possible to reuse the same version of the container's dependencies, but this community has not yet matured the program, we are also exploring.

The third is the governance of microapps. When we practice micro-front-ends at scale within a company, or when the number of micro-applications increases and dependencies become complex, it is easy to encounter problems related to architectural governance. For example, how to ensure that the host application uses the microapp application resources that match the environment, without causing failure because the online reference to the offline microapp, such as how to ensure that the high availability level between applications is equal, and will not be because a core link application depends on a low service level application, resulting in the problem that the service is often unavailable. To manage these problems, we need to start from the platform side as soon as possible, do the data collection and statistics of the relevant research and development stage, and then design our systematic products and R&D ideas based on these data references, and converge the R&D process from the entire platform level.

InfoQ: Which scenarios do you think are suitable for micro-frontends and which scenarios are not?

Liu Kui: Before answering this question, we may first have to answer what problems the micro frontend solves.

From an engineering point of view, the micro front end actually solves the problem of how to reduce the coupling between system components through some physical isolation means in the context of high-speed iteration of front-end technology and frequent changes in organizational structure, so as to ensure that the development and delivery of each component are independent, and thus realize the ability of gradual evolution of the entire system.

From a product point of view, the micro front end solves how to achieve the platform and dynamicness of the entire product without the perception of the technology stack. Dynamically assemble services from different systems for different scenarios and user roles.

Understanding these two points, we can answer this question, which is simply:

If you're not going to do continuous delivery on a long-tail application, you don't need a micro-frontend; if your products are all developed by the same small team, you don't need a micro-frontend; if your product doesn't have an integrated/integrated appeal, you don't need a micro-frontend. vice versa.