Micro front-end is a relatively new topic recently. It does not specifically refer to a certain library or framework, but an idea, a concept, and using this idea. According to your own needs, you can realize a micro front-end suitable for yourself.

This article is written based on the recent sharing of micro front-end technology solutions I held in the company. The micro front-end solution provided is also used in internal projects of the company and has received good feedback and received widespread praise. This article does not specifically talk about how to implement micro front-ends, but only talks about the concept of micro front-ends. We hope to understand micro front-ends through this article.

Preface

Micro front-end is currently an emerging idea in the industry.

The background of the idea of ​​birth is that within the company, there are often a type of projects, which are very large and heavy. The business content involved is diverse and complex, and it also involves various issues such as joint maintenance across departments and the huge technical debt accumulated. Such projects will cost huge expenses in terms of maintenance costs and deployment costs. Front-end developers are suffering from maintaining such projects. There is an urgent need to find solutions to this type of problem.

Based on this background, we began to explore the feasibility of the solution, and it was based on this that the micro front-end began to slowly appear in people's vision.

status quo

Development History

In the early stages of the development of the Web, there was no so-called front-end concept, and the content of the web page was relatively simple, mostly involving the display of text and picture information and form content. These tasks may be handled by the website manager himself. Then Microsoft launched the Ajax technology, which caused technological changes in web pages. From then on, the website began to have dynamic interactiveness. The ability to initiate requests on the web page to dynamically obtain the content of the server, which enriches the interactivity of the web page. The development of web pages also further increases the interaction between the UI interface and form. The front-end is gradually divided into a relatively independent function in the development of data and logic.

With the emergence of nodejs and the emergence of angular, libraries such as vue/react, as well as an ecosystem built on nodejs, With the birth of tools such as grunt, gulp, webpack, etc., the front end has entered a period of blowout-like explosion, which is also the period we are in. The front-end is becoming more and more professional. The technical content included is becoming more and more abundant. Relying on nodejs and numerous technical frameworks, we are further developing towards engineering, and front-end projects are becoming larger and larger.

Problems emerging

Have you maintained a project that may have a history of more than four or five years? Have you maintained a project that combines various libraries? Have you maintained a project jointly developed across teams with multiple corporate departments?

For many people, a company they join is most afraid of being arranged to maintain such a project. Because every maintenance iteration is like opening a blind box, I never know any surprises waiting for me.

For projects like this, possible problems include:

• Cross-departmental, praising team joint development, how to communicate? How to collaborate?
• There are many business lines and many pages, how to manage it?
• How to manage code?
• How to manage branch?
• Multi-department iteration, how to control the version?
• There is a release conflict, how to resolve it?
• How to test?
• How to manage public code?
• ...

Modifying a certain line of code may bring unexpected results, the accumulation of various problems, technical debts and business debts, making the project increasingly bloated and difficult to maintain.

It is urgent to find a solution that can solve these problems.

iframe embed

Therefore, most of the time, we have to choose to use iframe embedding to disassemble the bloated projects bit by bit and return them to various departments or teams to maintain them for themselves. It also provides a system portal application, which uses iframe embedding method, and maintains a mapping between a menu list and other project portal links to form a website application.

Through iframe embedding, to a certain extent, it meets the needs of independent development and deployment of various departments, teams and business lines. You only need to provide corresponding page links to access. In the entire system. But there are some problems

Security Question

However, we know that there are security issues with iframes. If an attacker uses iframe to access a link from an unknown source, it may be injected into a malicious script and thus steal it. The system's privacy information requires us to strictly configure SCP and sandbox to ensure the security of the iframe as much as possible.

Resources loaded too much

Since you only need to provide links to embed, the flexibility is very high for each project. Each project can choose various technical frameworks to realize its own business. Or even if the same technical framework is used, the resources of each project are relatively independent, and the amount of resources to be loaded will be very large for the entire system. This leads to slowing down the page access speed, and often there will be too long waiting time for some areas of the page, which also brings experience problems.

Visit map lost

Because the site embedded in the iframe has exclusive access history, it is independent of the external history, that is, the history is accessed through the browser's forward/back button and The expected results cannot be obtained, which affects the user's operations to a certain extent.

Find a solution

Are there any other solutions to further solve these problems?

First of all, we know clearly that single-project management is not a feasible solution at present, and solutions need to be found in multi-project management.

Multi-project public business components

For most large-scale system projects, the following layout structure is generally adopted:

The main layout structure includes:

• Navigation bar (optional)
• Menu bar on the left (optional)
• Content area
• Footer (optional)

Under this layout structure, each business segment usually uses the navigation switch to navigate through the navigation bar or the left menu bar to display the business segment in the content area. That is, overall, for the business, the navigation bar, the left menu bar, and the footer are all possible in common, and the main difference lies in the content area.

Then we can extract the common parts, such as the navigation bar, the left menu bar, and the footer, as public business components. For each business segment, individual projects are independently developed and maintained, and these public business components are introduced into the project. One of the main responsibilities of the public business components is to provide links to various business segments.

This solution has the following advantages:

• The overall system is split into multiple projects according to the business segment;
• Realize the independence of the project and can be independently developed and published;
• Achieve an access experience similar to **SPA application by overloading rendering in the main project;

But it also brings new problems:

• Public business components

• How to manage public business components;

• Public business components How to maintain synchronous updates between business segment projects;

And the unresolved issues:

• Too much resource loading;

The projects in each business segment repeatedly load public business components and various library resources.

• The project cannot be managed uniformly;

Main project reload business project resources

In the previous solution, the introduction of public business components solved some problems and also brought about some problems. How to manage public business components in a unified manner and maintain consistency?

Let's go back to the iframe scheme, where there is a main project for managing these menu bars, navigation bars, etc. Similarly, you can learn from this idea. Also abstract a main project to manage these public business components, and then look for another way to load and render other business segment projects.

We know that projects in the business sector are also accessed through links, and each link corresponds to an html resource file. The page is rendered by loading this resource, as well as css resources, js resources, etc. in HTML. Then, we can parse this html resource, and then load the resulting html content, css file, and js file into a specific area after loading it in the main project. Then you can load business segment projects in the main project.

In the main project, implement a resource loader and parser, obtain the html resource file through the access link of the business segment project, and parse the content of the html, including:

• <head>, <title>, <link>, <script>, etc. in the tag;
• html content in the <body> tag, <script> etc.

Then load the parsed CSS resources and JS resources, insert the html content into a specific area, and render it. This presents the complete web content.

This solution further solves the following problems:

• Public business components are handed over to the main project for unified management, which directly avoids synchronization problems;
• All business segments are rendered in the main project, improving user experience;

However, new problems have been introduced:

• Business sectors are all running in the same environment, and multiple sectors are switched between them. The loaded resources are prone to polluting the environment. Such as polluting a global variable, polyfills polluting each other, etc.
• There may be a cross-domain issue for loading resources.

But it also has the following advantages:

• Split projects, can be developed and deployed independently;
• Unified management of main projects, public business components, easier to maintain;
• The switching between projects is optimized for experience;

When the plan was thinking about it here, I found that the main project was to load the business segment project by parsing link. And link For modern front-ends, the more meaning is that it may be routing. Then we follow this idea and continue to optimize.

New Solution

Speaking of routing, it is easy to think that mainstream libraries/frameworks such as react, vue, angular can be implemented through routing. Or, route distribution pages**.

So, we can further expand this idea. Can we distribute applications through ** routes?

###Route

In the front-end category, the routing refers to presenting different content to the user as the browser's address bar changes.

Front-end routing is usually implemented using hash or history API.

// hash
;`https://pengzhanbo.com/#route` // history API
`https://pengzhanbo.com/route`

The routing is further refined, and through /, it can be divided into multi-level routes such as first-level routes, second-level routes, third-level routes, etc.

In modern front-end frameworks such as React / Vue / Angular, etc., there are technical solutions to implement SPA applications through routing. And the SPA application is the Routing and Distribution Page.

###Routing and distribution applications

Similar to the Routing Distribution Page, we can also distribute applications through **Routing Distribution.

Similar to the main project overloading business project resources, the mapping relationship between routing and business segment projects is realized. In the main project, find the business segment project through routing, load relevant resources and render them in the relevant area.

Main application and sub-application

From here, we position the main project as the main application and define each business segment project as a sub-application. Implement a sub-application loader in the main application, and the loader obtains the corresponding sub-application loaded by parsing the route.

**Main application: ** As an independent project, the entrance application of the entire system is responsible for unified management of public business components (such as menu bar, navigation bar, footer, etc.), responsible for implementing sub-application loaders, and responsible for implementing containers for rendering sub-applications.

**Sub-application: ** As an independent project, each business segment of the system is independently a separate project, developed, maintained and deployed separately.

Register sub-app

The main application needs to discover the sub-application through routes, and it is necessary to propose the mapping relationship between the route and the sub-application, so there is a mechanism for registering the sub-application with the main application. And associate relevant resource files, etc.

[
  {
    "AppName": "Sub Application",
    "route": "/sub-app-route",
    "resource": {
      "js": ["https://example.com/index.js"],
      "css": ["https://example.com/style.css"]
    }
  }
  // more...
]

Micro front end

By splitting the entire system into small projects, small projects are sub-applications. Through refinement, the entire system is refined into small applications. This reduces the complexity of the entire system. A small project can be a business project of a certain department, a section in a certain business project, or a separate page.

This is also why the new solution is called micro front-end.

Micro front-end refers to a system that is divided into tiny independent sub-applications and aggregated into a complete system through the main application. The micro front-end is a concept that has no strong correlation with the framework. It can be compared to the microservice on the server side and is a microservice on the browser side.

Since sub-applications are independent, they theoretically support the use of arbitrary technical frameworks for development, whether they are developed using jQuery, or Vue, React, Angular, etc. However, in practice, for the entire system, the choice of technical framework should be maintained in a unified manner to ensure the maintainability of the entire system.

Limitations of micro front-end

The micro front-end technical solution is more suitable for use in medium and large projects. For small projects, since the body size is not large, there is no need to further refine the entire system. Refining increases the complexity of the project.

For medium and large projects, if the old system is migrating to the micro front-end, it is inevitable that the migration and transition plan and planning between the new and old solutions must be considered. If there are multiple different technical frameworks applied in the old system, or different versions of the same framework, since the main application and all sub-apps are run in the same browser environment, There are inevitably problems of environmental pollution, such as global environmental pollution, multiple pollution of polyfill on native objects, etc., and also issues such as naming pollution of CSS. Therefore, how to ensure the correct rendering of sub-applications and how to avoid environmental pollution problems are also issues that need to be solved urgently.

The future of micro front-end

At present, micro front-ends are mainly divided into main applications and sub-applications. On micro, they are only refined to the page level. However, for micro front-ends, they can be further refined. For example, refinement to a certain block of the page and to a certain logical function can be shared in the main application and sub-application through the micro front-end technical solution. The entire system is increasingly broken down into pieces, further disassembling and refining the complexity, so that every function, logic, etc. can be maintained and deployed through a certain project, or even an independent project.

Micro front-end is a framework-independent concept, but when implementing micro front-end, if multiple technical frameworks are allowed to coexist, the problems brought about are more difficult to predict and difficult to solve than those that exist when not using micro front-end. In actual scenarios, it is best to limit it to a unified technical framework category to avoid introducing more complex problems due to coexisting different technical frameworks.

Conclusion

Micro front-end is a relatively emerging technical concept that is suitable for some front-end scenarios, but it is best if you have already considered it clearly. Micro front-end is the best solution to your scenario problems, otherwise, unless necessary, No need to choose a micro front-end solution.