This article will explain the background of the birth of micro front end, explain in detail the reason of the concept of micro front end and its in-depth understanding. After reading this article, I believe that you have a relatively comprehensive cognition of micro front end, understand what problems it can solve your team and the whole enterprise, and what benefits it can bring.

A background.

Now many enterprises, basically in physical application code isolation, the implementation of a single application a single library, closed-loop deployment update test environment, pre-release environment and formal environment. Therefore, we discuss how to realize resource sharing among multiple applications based on different applications with different libraries and independent deployment.

In the past, most of the processing methods were extracted and referenced in the form of NPM packages. For example, when there may be some business logic modules or other reusable modules between multiple application projects, they are extracted and managed and used in the form of NPM packages. But this raises the following questions:

  • Publishing is inefficient. If you need to iterate logical services in the NPM package, you need to release the NPM package first, and then update the NPM package version for each application that uses the NPM package, and then build and release the NPM package version for each application, which is a tedious process. If there are more applications involved, there will be more effort and effort.
  • Multi-team collaboration is prone to irregularities. An NPM package containing generic modules is a shared asset and “everyone” owns it, but in practice this usually means that no one owns it. It can quickly become cluttered with stylistically inconsistent code with no clear convention or technical vision.

These issues led us to realize that scaling up front-end development so that multiple teams can develop a large and complex product simultaneously is an important but difficult challenge.

So, back in 2016, the micro front end concept was born.

Two. Micro front end concept

Micro Frontends’ website defines the concept of a microfront-end:

Techniques, strategies and recipes for building a modern web app with multiple teams that can ship features independently.

Translated into Chinese:

According to The Website of Micro Frontends, the microfront-end concept is an extension of the microservices concept, abandoning the large monolithic approach and breaking the front-end into small, simple blocks that can be developed, tested and deployed independently while still coming together as a single product to the customer. It can be understood that a microfront-end is an architectural style that aggregates several small, independently deliverable front-end applications into one whole.

A few points to note:

  • A microfront end is not a specific technology, but rather an integration of technologies, strategies, and methods, which may be presented as a macro architecture in the form of scaffolding, helper plug-ins, and specification constraints. There are several alternatives to this architecture, all of which have their pros and cons, but the one that fits the current business scenario is a good one.
  • The micro front end is not constrained by the technology stack. The design of each set of micro front-end solutions is based on actual needs. If multiple teams use the React stack uniformly, there may be no requirement for cross-stack use of micro front-end solutions. If multiple teams use react and Vue technology stacks at the same time, there may be high requirements for cross-stack microfront-end.

Three. Advantages of the micro front end

Synchronous update

Compared with the NPM package method of extraction, let us realize the importance of updating process and efficiency. Because the micro front-end is the aggregation of multiple sub-applications, if multiple service applications rely on the function module of the same service application, only the service application needs to be updated, and other service applications can be updated immediately, thus shortening the update process and saving the update cost.

The incremental upgrade

Due to historical baggage, there are still teams that use old and large front-end singletons and are held back by outdated technology stacks or rushed code quality to the point where you want to overturn and rewrite. To avoid the risk of a complete rewrite, we prefer to renovate older applications gradually, while continuing to provide new functionality to our customers without impact.

The micro front end gives us more freedom to make independent decisions about each part of the product, allows the team to continuously add new features and make little change to the whole, and allows incremental upgrades to our architecture, dependencies, and user experience.

In addition, if there is a major incompatibility update in the main framework, each microfront can choose to update at the appropriate time, rather than being forced to halt current development and update immediately. If we want to try new technologies, or new modes of interaction, it will have less impact on the whole.

Simple, decoupled code base

The source code base for each individual microfront-end project is much smaller than that for a single front-end project. These smaller code bases will be easier to develop. More importantly, we avoided unintended inappropriate coupling between unrelated components. Reduce this unintended coupling by reinforcing the boundaries of your application.

Of course, a stand-alone, high-level architectural approach, such as a microfront end, is not meant to replace good old code with clean specifications. We don’t want to avoid code optimization and code quality improvement. Instead, we trap ourselves for success by making it harder to make bad decisions and more likely to make good ones. For example, we made it difficult to share domain models across borders, so developers were less likely to do so. Similarly, the micro front end forces you to explicitly and deliberately understand how data and events are passed between different parts of your application, something we should have started doing a long time ago!

Independent deployment

As with microservices, the independent deployability of the microfront end is key. It reduces the scope of the deployment, thereby reducing the associated risk. Regardless of where your front-end code is hosted, each microfront should have its own continuous delivery channel that can be built, tested, and deployed all the way into production. We should be able to deploy each microservice without considering other code bases or channels. Even if the original single project was manually released quarterly on a fixed basis, or if other teams submitted unfinished or problematic code to their main branch, the current project would not be affected. If a micro front end project is ready to go into production, it should have this capability, and it is up to the team that builds and maintains it.

Autonomous team

The further benefit of separating our codebase from the release cycle is that we have a completely separate team that can participate in the idea, production, and subsequent process of our own product. Each team has all the resources they need to deliver value to their customers, which allows them to act quickly and effectively. To achieve this, our team needs to be divided vertically by business function, not by technology category. One simple approach is to segment the product based on what the end user will see, so each micro-front end encapsulates a single page of the application and is held accountable by a single team. This allows teams to work more cohesiveness than if they were organized by type of technology or “horizontal” concerns such as styles, forms, or validation.

Four. Types of micro front end schemes

At present, domestic micro front-end schemes can be roughly divided into:

  • Pedestal mode: Manage sub-applications by building pedestals and configuring hubs. For example, there are generic solutions based on SIngle Spa, as well as tailored solutions based on the team’s business.
  • Self-organizing mode: Intermodulation by convention, but problems such as dealing with third party dependencies.
  • Decentralized: Off the pedestal, each application can share resources with each other. For example, the EMP micro-front-end solution based on Webpack 5 Module Federation can realize multiple applications sharing resources with each other.

Concern now is to center model of EMP front-end solutions, can not only realize across technology stack calls, and can be applied to the same technology stack depth between customization sharing resources, if started researching micro front, we can try to understand the EMP micro front-end plan, may bring you a good experience.

Detailed comparative analysis of multiple solutions will be explained in detail in the next article “Comparing various micro front-end solutions”. Welcome to pay attention to the first update of the wiki blog.

EMP micro front End Wiki blog postUpdate directory:

  • Basic Knowledge analysis

    What is a micro front end

    Compare various microfront-end solutions

    Webpack5 Module Federation

    The design architecture of EMP

  • Quick start

    How does the React project use and access EMP

    How do VUE projects use and access EMP

    Tutorial on how to use auxiliary plug-ins

  • Advanced tutorial

    How do Vue and React projects call each other remotely

    How do COCOS2D projects use and access EMP

    Teach you base station building skills