Business logic splitting based on micro frontend

1. What is a micro frontend?

Micro frontends are a technical means and method strategy for multiple teams to jointly build modern web applications by independently releasing functions.

Micro frontends were formally proposed in the ThoughtWorks Technology Radar in 2016. Drawing on the architectural concept of microservices, a large frontend application is split into multiple independent and flexible small applications, each of which can be independently developed, run, and deployed, and then these small applications are combined into a complete application. Micro frontends can not only integrate multiple projects into one, but also reduce the coupling between projects and improve project scalability. Compared with a whole frontend warehouse, the frontend warehouse under the micro frontend architecture tends to be smaller and more flexible.

Architecture Features

• Technology stack independence: the main framework does not restrict the technology stack of the connected application, and the sub-application can choose the technology stack independently;
• Independent development/deployment: Each team has independent warehouses and is deployed separately without relying on each other;
• Incremental upgrade: When an application becomes large, it is very troublesome to upgrade or reconstruct the technology, but micro-applications have the characteristics of incremental upgrade;
• Independent runtime: Micro-applications are independent of each other at runtime and have independent state management;
• Improve efficiency: The larger the application, the more difficult it is to maintain and the lower the collaboration efficiency. Micro applications can be easily split to improve efficiency.

2. Currently Available Micro-frontend Solutions

2.1 Complete Isolation Based on iframe

As front-end developers, we are already very familiar with iframes, which allow us to run another application independently within an application.

advantage:

• It’s very simple and does not require any modification;
• Perfect isolation, JS and CSS are independent operating environments;
• There is no restriction on usage, and multiple iframes can be placed on a page to combine services.

shortcoming:

• The routing status cannot be maintained and is lost after refreshing;
• Complete isolation makes interaction with sub-applications extremely difficult, and only the postMessage method can be used;
• Pop-ups in an iframe cannot break through itself;
• The entire application is loading all resources, and the loading is too slow.

2.2 Routing hijacking based on single-spa

single-spa (opens new window) is a currently mainstream micro-frontend using pedestal technology. Its main implementation ideas are: pre-register sub-applications, listen to route changes, load sub-application resources when matching activated routes, call lifecycle functions (initialization, mounting, unmounting) in sequence, and finally render to the container.

advantage:

• There is an out-of-the-box API;
• It is independent of the technology stack and can be connected to any technology stack;
• HTML Entry access method packages the entire micro application into a JS file, publishes it to the static resource server, and then configures the address of the JS file in the main application to tell single-spa to load the micro application from this address.

shortcoming:

• It is highly invasive to micro-applications and packages the application into a JS file. Common optimization measures, such as on-demand loading and independent CSS packaging, are no longer available.
• Without style isolation, styles are easily confused and overlapped;
• No JS isolation, JS global object pollution;
• There is no preloading mechanism, and loading resources is too slow;
• There is no means of communication between micro-applications, and it can only be achieved by users themselves.

2.3 Encapsulating components based on web components

The official componentization solution achieves decoupling between applications by encapsulating components to a higher degree and integrating micro-applications together in a component loading manner.

advantage:

• Loading sub-applications is more elegant than the single-spa registration listening method;
• It is independent of the technology stack and is a browser native component that can be used in any framework.
• No need to have any connection with other applications;
• Shadow dom is used between applications to isolate the style.

shortcoming:

• Poor browser compatibility.

2.4 quankun

Quankun is a layer of encapsulation for single-spa, which mainly solves the pain points and shortcomings of single-spa. It parses HTML through the import-html-entry package to obtain the resource path, and then parses and loads the resources.

advantage:

• Developed and maintained by the Alibaba team, with extensive documentation and ready-to-use APIs;
• JS sandbox mechanism ensures that direct application variable events do not conflict;
• Resource preloading: preloading unopened micro-application resources during the browser's idle time, speeding up the opening of micro-applications.
• Can be used in any JS framework, like embedding an iframe, and is compatible with IE11.

shortcoming:

• There are few online deployment documents;
• It can only solve the problem of mutual pollution of styles between sub-projects, but cannot solve the problem of sub-project styles polluting the main project's style.

2.5 EMP

Mainly based on Webpack5 Module Federation, it is a decentralized micro-frontend implementation solution that can not only isolate applications well, but also easily realize resource sharing and communication between applications.

advantage:

• Quickly encapsulate reusable modules without unpacking them separately and publishing them to NPM, and directly expose modules that need to be shared;
• Real-time dynamic update, you only need to publish the base station application and refresh it when accessing to use the latest business module;
• The import end does not need to be manually updated, the remote module can be flexibly maintained and the import end can be freely combined, and even the remote module can be imported and used during operation;
• Share third-party dependencies to reuse code as much as possible and reduce loading content.

shortcoming:

• Strong dependence on webpack, not friendly to old projects;
• There is no CSS isolation and JS isolation, which requires user awareness;
• It is not possible to keep sub-applications alive or activate multiple applications;
• The routes of the main and sub-applications may conflict.

3. Problems we need to solve

Split giant applications to facilitate iterative updates and improve development and deployment efficiency

After a monolithic application evolves from an ordinary application to a front-end monolith over a relatively long period of time due to the increase and change of the number of people and teams involved, the application becomes unmaintainable. This kind of problem is especially common in enterprise-level Web applications. The micro-front-end concept can split a huge front-end application into multiple independent and flexible small applications. Each application can be developed, updated, and deployed independently, reducing the coupling between modules and improving the scalability of the project. It is conducive to the gradual optimization of each sub-application without affecting the operation of new functions and other sub-applications.

Collaborate across teams to achieve demand division of labor, strive for resource optimization, and improve work efficiency

Large demands need to be split, and different parts require different business capabilities, which require collaborative development involving multiple teams or even multiple departments. The so-called professional team does professional things, refines its capabilities, maximizes the utility of its capabilities, improves the overall work efficiency of the team, and achieves the effect of 1+1>2.

Compatible with historical applications to achieve incremental development

The technology stack of the old project is not unified. The micro-frontend main framework does not restrict the technology stack of the access application and can load different technology stack modules at any time. There is no need to make large-scale transformation and reconstruction to be compatible with existing projects, thereby improving development, testing and maintenance efficiency.

IV. Our Solution

1️⃣Use the web component-based micro-app framework as the basis to split out sub-applications that can run independently;

2️⃣Further encapsulate the business logic layer to achieve code isolation based on js sandbox and shadow dom;

3️⃣ Extract common modules for ion applications to further reduce the code size of the Jushi project and improve iterative maintenance efficiency.

4.1 Technical Features

High scalability, independence, and openness: Based on micro-app, the micro-front-end main framework is implemented, and the main application is split into the main platform system and various subsystems, which can be independently delivered and run as front-end sub-applications. The business modules are further abstracted, and the public modules are extracted from the sub-applications. Modular development and deployment are carried out to improve the scalability of each sub-application/business module, reduce coupling, improve development efficiency, and reduce delivery costs.

Unify the independence of functional modules and improve security: Common business functions such as user information and role permissions can be abstracted and developed and deployed separately to reduce repeated development and the amount of project code. However, because they need to be integrated into different sub-applications, in order to avoid conflicts with the host page style, a shadow dom+JS sandbox mechanism is used to establish an independent scope and implement custom element. Both JS and CSS are isolated in the dom scope to achieve code isolation, making the code cleaner and neater and reducing coupling.

Extract common functional modules to further reduce project redundancy: Use the vite tool to package menus, headers, footers, logins, registrations, etc. into micro ESM modules. For business projects currently implemented with a single technology stack, there is no need to redevelop common modules for each submodule, making the total size of the code package smaller, improving development efficiency, and realizing on-demand asynchronous loading of modules to increase the overall loading speed of the page.

4.2 What is JS Sandbox

The JS sandbox is mainly used to isolate variables mounted on the window to ensure the independence of the JS environment between applications. The window accessed when the sub-application is running is actually a Proxy object. All global variable changes of the sub-application are generated in the closure and will not be actually written back to the window, thus avoiding pollution between multiple instances.

4.3 What is shadow dom

Shadow-dom is a node tree outside the DOM tree. It is created based on custom DOM elements (not documents), and the created shadow-dom nodes can be intuitively seen from the interface. More importantly, shadow-dom has good sealing, which can isolate CSS styles and avoid CSS global style pollution.

4.4 How do modules communicate with each other?

This solution involves sub-applications split according to business and sub-modules split according to functions, and their communication methods are not connected.

1. The sub-application split by business is not a module, but an application that can run independently. However, frequent communication between applications will increase the complexity and coupling of applications. Therefore, communication between sub-applications should be minimized and interaction should not be allowed unless necessary. Here we can use the API officially provided by micro-app to achieve this.

2. The sub-modules split according to the functional modules are sub-modules implemented based on web components. The communication between them can follow the parent component loading the sub-component and the communication between the parent and child components.