Multi-Web application integration system and method based on micro-front-end architecture

Abstract

The invention provides a multi-Web application integration system and method based on a micro-front-end architecture, and aims to solve the problems of state persistence, cross-application communication and style isolation in multi-Web application integration. The system takes a main application as a host, and the integrated configuration module, the routing module, the micro-front-end component module and the Bus module work cooperatively. The configuration module realizes complex configuration loading through enhanced JSON analysis; the routing module dynamically generates routing and supports hot updating; the micro front-end component module is combined with an iframe sandbox and a Shadow DOM (Document Object Model) to realize dual isolation of codes and styles, and state persistence is realized through a keep-alive mode; and the Bus module provides a decentralized publishing-subscribing communication mechanism. According to the method, seamless integration and flexible layout of multiple sub-applications are realized, multi-technology stack adaptation is supported, the user experience continuity and the development efficiency are improved, the coupling degree between the applications is reduced, and the method is suitable for various multi-Web application integration scenes.

Description

Technical Field

[0001] This invention relates to the field of web front-end development technology, specifically to a multi-web application integration system and method based on a micro-front-end architecture. More particularly, it relates to a multi-application integration system and method for building large, complex web applications. Background Technology

[0002] As businesses rapidly expand, web application systems are becoming increasingly large and complex. Traditional monolithic front-end architectures, where all functional modules are packaged and developed within a single project, face numerous challenges, including low development efficiency, outdated technology stacks, maintenance difficulties, and high deployment risks. To address these issues, micro-front-end architectures have emerged. These architectures break down large front-end applications into multiple smaller, more manageable independent sub-applications. These sub-applications can be independently developed, tested, and deployed by different teams, and then integrated by a single main application.

[0003] In the prior art, patent document CN115794093B discloses a micro-frontend integration method based on the main application registry, which controls the loading, mounting, and unloading of each sub-application through predefined lifecycle functions. However, such solutions still have several shortcomings in practical applications. First, when switching applications, the old sub-application instance is usually completely unloaded and destroyed, resulting in the loss of its internal running state, such as user-filled form data and page scroll position information. When the user returns to the application, it needs to be reloaded and initialized, which not only interrupts the user's operation flow but also brings unnecessary performance overhead. Second, the cross-application communication mechanism in existing solutions often relies on a centralized global state manager or data transfer through listener functions. This approach is cumbersome to configure, increases the coupling between applications, and may cause data security risks due to global state pollution. In addition, style isolation between different sub-applications is also a problem, especially when integrating sub-applications developed with different technology stacks. Global styles or component library styles are prone to overlap, leading to user interface chaos. Finally, the main application's lifecycle management of all sub-applications is relatively simple and lacks flexibility. It cannot provide differentiated configuration and management based on the characteristics and business scenarios of different sub-applications (for example, some applications need to remain active while others do not).

[0004] Therefore, the market needs a multi-web application integration system and method based on a micro-frontend architecture that supports highly customizable configuration by introducing an application keep-alive mechanism, an event bus communication model, and a WebComponent Shadow DOM style isolation strategy. Summary of the Invention

[0005] To address the shortcomings of existing technologies, the present invention aims to provide a multi-Web application integration system and method based on a micro-frontend architecture, which seeks to solve technical problems in existing micro-frontend technologies such as state loss due to sub-application switching, complex cross-application communication, easy style contamination, and inflexible configuration management.

[0006] According to the present invention, a multi-Web application integration system based on a micro-frontend architecture includes: a configuration module, a routing module, a micro-frontend component module, and a Bus module; The configuration module is used to define the integration rules of the sub-application, load the sub-application by creating a sandbox environment, and proxy the interface operations within the sub-application to the protected container node within the main application. The routing module is connected to the configuration module and is used to dynamically generate application routes based on the integration rules. The micro-frontend component module is called by the routing module and is used to create containers with style isolation for sub-applications; The Bus module is used to provide an event bus instance injected into the sandbox environment to enable cross-application communication.

[0007] Preferably, the configuration module creates an invisible iframe as the sandbox environment, and by hijacking the Document Object Model application interface and the routing application interface within the iframe, it proxies the operation to a container node in the main application protected by a shadow Document Object Model, thereby achieving visual integration and strict isolation of the runtime environment.

[0008] Preferably, the micro-frontend component module creates a custom Web component element for each sub-application instance, and enables a shadow document object model within the custom element to create an independent document object model tree and cascading style sheet scope for the sub-application, thereby achieving style isolation.

[0009] Preferably, the event bus instance implemented by the Bus module includes a listening method and a triggering method; The listening method is used to register an event listener, and the triggering method is used to trigger an event and pass parameters; The event bus instance is injected into the global window object of the iframe where the sub-application is located, and the sub-application can directly call the listening method and triggering method to achieve decoupled cross-application communication.

[0010] Preferably, the integration rules include a runtime mode configuration for enabling or disabling persistent state keeping-alive; When keep-alive mode is enabled, the internal running state of the sub-application is fully preserved after switching, without the need for reloading and initialization.

[0011] A method for integrating multiple web applications based on a micro-frontend architecture, provided by the present invention, includes: Step S1: Define the integration rules for sub-applications through the configuration module; Step S2: Dynamically generate application routes based on the integration rules using the routing module; Step S3: In response to the application route, create a container with style isolation for the sub-application through the micro-frontend component module, and load the sub-application in the sandbox environment; Step S4: Inject an event bus instance into the sandbox environment through the communication module to enable cross-application communication.

[0012] Preferably, the integration rules are stored in one or more configuration files; The configuration file is in JSON format and includes the unique identifier id of the sub-application, the resource entry URL, the running mode identifier alive, and lifecycle hook functions; Step S1 further includes a configuration file parsing step: the parsing process achieves serialization and deserialization of complex data types, including functions and regular expressions, by rewriting the JSON.stringify and JSON.parse methods.

[0013] Preferably, step S2 further includes a routing and menu hot update step: The main application monitors configuration file changes through a file listener. When the configuration file is modified, the configuration module reloads, parses, and pushes the new configuration information to the routing module. The routing module compares the differences between the old and new routing tables, incrementally updates the routing table, and the navigation menu component is synchronously re-rendered.

[0014] Preferably, step S3 includes: Step S3.1: Check the sub-application running mode flag "alive". If "alive" is true and the sub-application instance exists in the cache pool, restore the instance and its corresponding state directly and display it. If it is the first load or "alive" is false, execute the instance creation process. Step S3.2: Create a Web Component container named based on the sub-application ID and timestamp, and enable Shadow DOM for the container to achieve style isolation; at the same time, create a visually invisible iframe sandbox, set the src attribute of the iframe to the sub-application resource entry URL, and build an independent code execution environment; Step S3.3: After the iframe is loaded, hijack the DOM manipulation API and routing API in the child application's JS environment, and delegate the DOM manipulation to the Shadow DOM of the Web Component container, so as to achieve seamless rendering of the child application in the main application's DOM and isolation of the code execution environment.

[0015] Preferably, in step S3.3, the main application uses CSS custom properties to make the theme variable penetrate the Shadow DOM boundary for use by sub-applications, thereby achieving a unified global theme switching.

[0016] Compared with the prior art, the present invention has the following beneficial effects: 1. This invention, through a configurable keep-alive mechanism, ensures that the internal state of a sub-application is fully preserved after switching, allowing it to be immediately restored when the user accesses it again, achieving seamless switching and improving the smoothness and continuity of operation.

[0017] 2. The present invention provides a decentralized communication scheme based on an injection-type event bus communication module, which is independent of the specific framework. The communication logic between applications is clear, significantly reducing the coupling between modules and improving the maintainability of the system.

[0018] 3. This invention utilizes the shadow document object model feature of Web components to create an independent document object model and cascading style sheet scope for each sub-application, fundamentally eliminating style conflicts between different sub-applications and between sub-applications and the main application.

[0019] 4. This invention is based on a configuration-driven model, combined with an iframe sandbox and a shadow document object model, which enables the system to easily integrate heterogeneous applications developed using different technology stacks and flexibly configure the running mode for each application, greatly enhancing the system's scalability and adaptability. Attached Figure Description

[0020] Other features, objects, and advantages of the present invention will become more apparent from the following detailed description of non-limiting embodiments with reference to the accompanying drawings: Figure 1 This is a schematic diagram of example code for routing configuration in one embodiment of the present invention; Figure 2 According to Figure 1 The page effect generated by the configuration shown is illustrated in the image. Figure 3 This is a schematic diagram of the overall architecture of a multi-Web application integration system based on a micro-frontend architecture, provided for an embodiment of the present invention. Detailed Implementation

[0021] The present invention will now be described in detail with reference to specific embodiments. These embodiments will help those skilled in the art to further understand the present invention, but do not limit the invention in any way. It should be noted that those skilled in the art can make several changes and improvements without departing from the concept of the present invention. These all fall within the protection scope of the present invention.

[0022] Example 1 This embodiment provides a multi-web application integration system based on a micro-frontend architecture. For example... Figure 3 As shown, this system is deployed within the main application to seamlessly integrate one or more independent sub-applications into a unified user interface, aiming to solve problems such as state persistence, cross-application communication, and style isolation. Specifically, the system mainly includes: a configuration module, a routing module, a micro-frontend component module, and a Bus module. These modules work together to constitute the core capabilities of the integrated system described in this invention.

[0023] The main application serves as the host environment for the entire system, typically a web application, such as a single-page application built on front-end frameworks like Vue, React, or Angular. It is responsible for initializing the system and providing a unified runtime shell and entry point for all sub-applications.

[0024] The configuration module, as the core configuration unit of the system, is primarily responsible for defining and managing the integration rules for all sub-applications to be integrated. These rules are centrally stored in one or more configuration files. As a specific implementation, these configuration files can be in JSON format due to their good readability, programmability, and cross-language support. The configuration module reads information from the configuration files, parses it, and then makes it available for use by other modules of the system.

[0025] The routing module handles application navigation and view switching. It works closely with the configuration module, receiving configuration information parsed from the configuration module and dynamically generating routing rules within the application based on this information. When a user accesses a URL via a navigation menu or directly, the routing module matches the corresponding routing rules to determine which page or component to render.

[0026] A micro-frontend component module is a container that hosts and renders specific sub-applications. It is typically implemented as a reusable frontend component, such as a Vue or React component. When the routing module decides to display a specific sub-application, it instantiates a micro-frontend component module and passes the sub-application's specific configuration information (such as resource addresses and runtime modes) to it. Correspondingly, the micro-frontend component module is responsible for loading and rendering the sub-application and providing it with the necessary isolation environment.

[0027] The Bus module (also known as the communication module) provides a unified, decoupled cross-application communication mechanism for the system. This module implements an event bus pattern. When a sub-application is loaded, the main application injects an instance of the Bus module into the sub-application's runtime environment through the micro-frontend component module. In this way, the main application and sub-applications, as well as different sub-applications, can communicate securely and efficiently using a publish-subscribe approach through this shared Bus instance, without directly depending on each other or on global state.

[0028] The internal implementation and working principle of the configuration module will be explained in detail below: One of the core functions of the configuration module is parsing configuration files. In a preferred approach, the JSON structure of the configuration file is carefully designed to flexibly describe each sub-application. For example, a typical sub-application configuration object might contain the following fields: 1. id: String type, used as a unique identifier for the sub-application. This ID must remain unique throughout the system and is used for route matching, state management, and communication location. For example, it can be set to "app-user-management" or "app-dashboard".

[0029] 2. url: A string pointing to the resource entry file of the sub-application. This is typically the URL of an HTML file, such as https: / / cdn.example.com / user-management / index.html. The main application will load all resources from the sub-application through this address. 3. `alive`: A boolean value specifying the running mode of the sub-application. When `alive` is `true`, the system enables "keep-alive" mode. In this mode, when a user switches from this sub-application to another application, the instance of the sub-application and its internal state (such as DOM state, JavaScript stack, form data, scroll position, etc.) are not destroyed but cached. When the user switches back to this application, the system can directly restore its previous state, achieving a seamless and fast switch, thereby improving the continuity of the user experience. When `alive` is `false`, the system adopts the "singleton" mode, that is, a brand new instance is created every time the sub-application is entered, and it is completely destroyed when the user leaves. This mode ensures that only one instance runs at a time, which is suitable for application scenarios that do not need or should not maintain state. 4. `lifecycle`: An object type that allows developers to inject custom lifecycle hooks into sub-applications. These hooks are called back by the main application at key stages such as loading, mounting, activation, and unmounting of the sub-application. For example, hooks such as `beforeMount`, `mounted`, `activated`, `deactivated`, and `unmounted` can be defined.

[0030] It should be noted that, since the standard JSON format does not support complex data types such as functions or regular expressions, the configuration module in this embodiment implements an enhanced serialization and deserialization mechanism. Specifically, it overrides the JSON.stringify method to convert functions or regular expressions into strings with special markers during serialization; correspondingly, it overrides the JSON.parse method to identify these special markers during deserialization and uses constructors such as newFunction() or new RegExp() to restore them to their original data types. This allows developers to directly write lifecycle functions in the JSON configuration file, thereby improving the flexibility and convenience of configuration.

[0031] Another core technology of the configuration module lies in the loading and isolation of sub-applications. It combines iframe sandboxing and Shadow DOM techniques to achieve dual isolation between the code execution environment and UI styles. Specifically, the process is as follows: When a sub-application needs to be loaded, the configuration module first dynamically creates a visually invisible iframe element within the main application environment. This iframe constitutes the iframe sandbox within the sub-application sandbox environment. Then, the iframe's src attribute is set to the URL specified in the sub-application configuration, and the browser will load and parse the complete sub-application resources (including HTML, CSS, and JavaScript files) for this iframe.

[0032] Due to the inherent isolation provided by iframes, the JavaScript code of child applications will execute in a separate child application JS environment. This environment has its own independent window, document, and history objects, completely isolated from the global scope of the main application environment, thus fundamentally avoiding problems such as global variable pollution and global event listener conflicts.

[0033] However, to achieve seamless visual integration, the UI elements of the child application cannot be rendered inside an invisible iframe; they must be rendered into the DOM structure of the main application. To this end, after the iframe loads, the configuration module accesses its internal global context via `iframe.contentWindow` and intercepts or proxies a series of key application programming interfaces (APIs). These APIs include, but are not limited to: 1. DOM manipulation APIs: such as `document.getElementById`, `document.querySelector`, `document.createElement`, `Node.prototype.appendChild`, `Node.prototype.insertBefore`, etc. 2. Routing APIs: such as `history.pushState`, `history.replaceState`, and hashchange event listeners.

[0034] Hijacking can be achieved using JavaScript's Proxy object or by directly overriding these APIs. When code in the child application's JS environment attempts to call these hijacked APIs, the execution flow does not operate on the iframe sandbox's own document, but is instead proxied to a pre-specified container node in the main application environment.

[0035] In a preferred embodiment of the invention, the container node is a Web Component container. The Shadow DOM is enabled within this container. Therefore, all proxied DOM operations will ultimately create and attach the sub-application's UI elements (i.e., the sub-application UI) to the Shadow DOM. Due to the powerful style encapsulation of the Shadow DOM, the CSS styles within the sub-application UI will only be effective within the Shadow DOM and will not leak into the main application's DOM or other sub-applications' Shadow DOM, and vice versa.

[0036] Through the combined mechanism of iframe sandbox code execution, API proxy, and Shadow DOM UI rendering, the embodiments of the present invention successfully achieve the effect that the sub-application runs logically in an isolated sandbox, while visually it is seamlessly embedded in the main application interface, thus achieving a unity of security isolation and user experience.

[0037] Example 2 This embodiment describes in detail the implementation of the routing module and how it works in conjunction with the configuration module and micro-frontend component module to achieve dynamic routing and navigation in the application. In this embodiment, the routing module can be built based on a mature frontend routing library (such as Vue Router).

[0038] During system initialization, the routing module requests configuration information for all applications from the configuration module. After reading and deserializing the configuration file, the configuration module returns an array containing configuration objects for all sub-applications to the routing module.

[0039] Subsequently, the routing module iterates through the configuration array, dynamically generating a route record for each sub-application configuration. In addition, the system also supports configuring ordinary pages outside the micro-frontend (such as static pages like "About Us" and "Contact Us"). These pages can also be defined in the configuration file, and the routing module will generate route records for them.

[0040] A typical route record object contains the following key properties: 1. path: A string type that defines the URL path to access this route. For example, for a sub-application with the ID "app-dashboard", its path can be configured as / dashboard. The routing module supports configuring dynamic route segments, such as / users / :userId. 2. component: Specifies the component to be rendered when this route is activated. For a sub-application, the component specified here is a micro-frontend component module; for a regular page, this can be any standard frontend component defined by the developer.

[0041] 3. props: A boolean or function type used to pass parameters to the component. In one implementation of this invention, this property can be set to a function that returns an object containing complete configuration information of the current sub-application. Thus, when a route match is successful, the routing library will automatically pass all configuration items of the sub-application, such as its id, URL, and live mode, as properties (props) to the instantiated micro-frontend component module.

[0042] Suppose we need to configure a page consisting of two sub-applications, one on top and one on the bottom. The first sub-application has keep-alive enabled and route synchronization is enabled, while the second has keep-alive disabled, as follows: Figure 1As shown, the layout configuration defines a page whose component is a custom layout component. This layout component defines two micro-frontends. These two micro-frontends share the same global route path but connect to two different applications by configuring two different URLs. Their rendering positions on the page are configured using the x (distance relative to the left side of the page), y (distance relative to the top of the page), z (level), w (width), and h (height) properties (for example, the first sub-application (ID L2) is placed 59% of the way from the top of the page (y=59%), and the second sub-application (ID CM) is placed 3% of the way from the top of the page (y=3%), so the second sub-application will be above the first). The first sub-application, sub-application 1 (ID L2), has keep-alive mode (alive: true) and route synchronization enabled, while the second sub-application, sub-application 2 (ID CM), has keep-alive mode disabled (alive: false).

[0043] The routing module dynamically adds all generated route records to the running application's routing table using APIs provided by the routing library (such as Vue Router's createRouter method).

[0044] Additionally, the system typically includes a navigation menu component. This component also obtains menu configuration information from the routing module or directly from the configuration module (this information can also be defined in the configuration file alongside the application configuration). The menu component automatically renders navigation links based on this information (e.g., using Vue Router). <router-link>(Component). When a user clicks a menu item, <router-link>This will trigger a URL change. Once the routing module detects the URL change, it will match the new routing rules, unload the old components, and mount the new components (i.e., micro-frontend component modules or ordinary page components), thereby completing the page switching.

[0045] Reference Figure 2 According to Figure 1 The diagram illustrates the page layout generated by the configuration shown. It visually demonstrates that when a user accesses the current page, the page is vertically divided into two areas: the upper half renders sub-application 1, and the lower half renders sub-application 2. This indicates that this technical solution supports integrating and laying out multiple sub-applications on the same page.

[0046] This invention also supports hot updates for routes and menus. In the development environment, the main application can set a file listener to monitor changes to the configuration file. When the developer modifies and saves the configuration file (e.g., adding a sub-application or modifying the live state of a sub-application), the file listener will capture this change and notify the configuration module to reload and parse the configuration. Subsequently, the configuration module will push the new configuration information to the routing module. The routing module will compare it with the current routing table, calculate the differences, and call the routing library's API (such as Vue Router's addRoute method) to dynamically and incrementally update the routing table. The navigation menu component will also listen for configuration changes and re-render accordingly. The entire process does not require manual browser refresh, realizing configuration-driven application integration hot updates, thereby significantly improving development and debugging efficiency.

[0047] Example 3 This embodiment describes the detailed implementation of the micro-frontend component module, which serves as the host of a sub-application. The micro-frontend component module is the core execution unit for achieving sub-application isolation, state persistence, and seamless integration. In this embodiment, this module can be implemented as a single-file Vue 3 component.

[0048] Micro-frontend component modules declare that they will receive sub-application configuration information from the routing module through their props definitions. These props include at least the sub-application URL, runtime mode, and lifecycle hooks.

[0049] When a route is activated and a sub-application needs to be rendered, Vue Router instantiates a micro-frontend component module and passes the corresponding configuration as props. Within the component's `mounted` lifecycle hook, the logic for loading and rendering the sub-application begins. First, the micro-frontend component module creates a unique internal identifier for the upcoming sub-application instance and checks if the instance already exists in the cache (especially in `alive` mode). If `alive` is true and the sub-application instance (including its iframe and Web Component container) already exists in the cache, the component simply needs to redisplay the previously hidden container and trigger its `activated` lifecycle hook to restore its state.

[0050] If a completely new instance of the sub-application needs to be created (i.e., on the first load, or when `alive` is false), the micro-frontend component module will perform the following key steps: Creating a Web Component container: The component first calls the `customElements.define()` method to dynamically define and register a new Web Component custom element. To avoid naming conflicts, the tag name of this custom element can be generated based on the sub-application's ID and timestamp, for example, `micro-app-user-management-1678886400000`. Then, the component creates an instance of this custom element using `document.createElement()`, which becomes the Web Component container.

[0051] Enabling Shadow DOM and achieving style isolation: After creating the Web Component container, the component immediately calls its `attachShadow({ mode: 'open'})` method. This call creates a Shadow Root for the container, namely the Shadow DOM. The Shadow DOM is a separate DOM tree isolated from the main document (main application DOM). All HTML content injected into this Shadow DOM and... <style>标签，其作用域都被严格限制在该树内部，这从根本上解决了CSS样式冲突问题。不同子应用之间、子应用与主应用之间的样式（包括全局样式、组件库样式等）将不会相互干扰，保证了各自UI的视觉保真度。同时，为支持全局主题切换等场景，主应用可以通过CSS自定义属性的方式，将主题变量（如主色调、字体大小等）穿透Shadow DOM边界，供子应用UI使用。

[0052] 创建iframe沙箱并实现代码隔离：与创建Web Component容器并行，微前端组件模块还会创建一个不可见的iframe元素，作为iframe沙箱。如实施例1所述，这个iframe的src被设置为子应用的url，其内部的子应用JS环境是完全隔离的。

[0053] 建立代理和连接：iframe加载完毕后，微前端组件模块获取其contentWindow对象，并执行API劫持逻辑。它会将子应用内部的DOM操作目标重定向到刚刚创建的ShadowDOM 。例如，当子应用代码执行document.body.appendChild(myElement)时，被劫持的appendChild方法实际上会执行shadowRoot.appendChild(myElement)，从而将myElement渲染为子应用UI 的一部分。

[0054] 状态保活的实现：微前端组件模块内部维护一个缓存池，用于存放alive模式下的子应用实例。一个实例通常包括对其Web Component容器和iframe沙箱的引用。当用户导航离开一个alive的子应用时，路由系统会卸载这个微前端组件模块，但在其beforeUnmount或deactivated生命周期钩子中，组件并不会销毁Web Component容器和iframe沙箱，而是简单地将它们从主应用DOM 中移除或设置其样式为display: none，然后将实例存入缓存池。由于iframe本身未被销毁，其内部的子应用JS环境、全局变量、事件监听、定时器以及内存中的所有数据都得以完整保留。当用户再次访问该子应用时，组件从缓存池中取出实例，将其重新附加到DOM中并显示，从而实现状态的持久化与快速恢复。

[0055] 综上所述，微前端组件模块不仅是子应用的渲染器，更是一个功能完备的生命周期管理器和隔离环境提供者，是实现本发明技术效果的关键构成。

[0056] 实施例 4本实施例对用于解决跨应用通信问题的去中心化Bus模块的实现原理及使用方式进行详细阐述。在复杂的微前端架构中，主应用与子应用、以及子应用与子应用之间常需进行数据交换和事件通知，一个设计良好的通信机制至关重要。

[0057] Bus模块的核心是一个实现了事件总线模式的Bus类，实现步骤如下：Bus对象成员函数：该Bus类提供了两个核心方法on(eventName, callback)用于注册一个事件监听器，例如on(event: string, callback: Function)；emit(eventName,...args)用于触发一个事件并传递任意数量的参数，例如emit(event: string, data?:any)。

[0058] 下面说明该Bus模块如何集成至整个系统中。在主应用初始化时，会创建一个或多个Bus类的实例。可以创建一个全局共享的bus实例，用于广播类通信；也可以根据业务领域创建多个独立的bus实例（例如userBus、orderBus），用于特定领域内的通信，以进一步降低耦合。

[0059] 当微前端组件模块准备加载一个子应用时，它会获取到需要使用的Bus实例的引用。在子应用的iframe沙箱被创建并且其window对象可用之后，主应用通过iframe.contentWindow访问到子应用的全局上下文，然后将Bus实例的引用注入其中。一种直接的实现方式是将其赋值给iframe.contentWindow的一个属性，例如：iframe.contentWindow.bus = sharedBusInstance;完成注入后，通信链路即被建立，通信流程如下：步骤1：主应用可以预先通过bus.on('some-event', callback)来监听一个来自子应用的事件。

[0060] 步骤2：在子应用A的业务逻辑中，当需要通知外部时，它无需关心监听方，也无需引入任何复杂的库，只需直接调用注入的全局对象上的方法：window.bus.emit('some-event', { payload: 'some data'})。

[0061] 步骤3：Bus模块接收到emit调用后，在其内部的events映射中查找名为'some-event'的事件。

[0062] 步骤4：Bus模块找到主应用之前注册的callback，并执行它，同时将子应用传递的data作为参数传入。

[0063] 以此方式，即可实现从子应用到主应用的单向通信。反之，主应用亦可调用bus.emit()，而子应用通过window.bus.on()来监听，从而实现从主应用到子应用的通信。

[0064] 相应地，对于子应用间的通信，其原理类似。若子应用A和子应用B需要通信，主应用只需确保为它们注入的是同一个Bus实例。然后，子应用A可通过window.bus.emit()发送消息，子应用B通过window.bus.on()监听同一个事件名，即可接收到消息。

[0065] 可以理解的是，这种基于注入式事件总线的通信机制具有以下显著优点： 1. 去中心化和低耦合：通信双方不直接依赖对方，而是共同依赖于Bus。任何一方的增、删、改均不影响另一方，只要其遵守约定的事件名和数据结构即可。 2. 框架无关：Bus模块不依赖于任何前端框架（如Vue、React等）。因此，无论主应用还是子应用使用何种技术栈，均可无缝地使用此套通信机制。 3. 安全可控：Bus实例的创建和注入完全由主应用控制。主应用可以决定哪些子应用共享同一个Bus，哪些使用独立的Bus，从而可以精细地管理通信范围，避免了全局状态管理可能带来的数据污染和安全风险。

[0066] 综上，Bus模块为本发明所提供的微前端集成系统构建了一套高效、安全且灵活的通信基础设施。

[0067] 本领域技术人员知道，除了以纯计算机可读程序代码方式实现本发明提供的系统及其各个装置、模块、单元以外，完全可以通过将方法步骤进行逻辑编程来使得本发明提供的系统及其各个装置、模块、单元以逻辑门、开关、专用集成电路、可编程逻辑控制器以及嵌入式微控制器等的形式来实现相同功能。所以，本发明提供的系统及其各项装置、模块、单元可以被认为是一种硬件部件，而对其内包括的用于实现各种功能的装置、模块、单元也可以视为硬件部件内的结构；也可以将用于实现各种功能的装置、模块、单元视为既可以是实现方法的软件模块又可以是硬件部件内的结构。

[0068] 以上对本发明的具体实施例进行了描述。需要理解的是，本发明并不局限于上述特定实施方式，本领域技术人员可以在权利要求的范围内做出各种变化或修改，这并不影响本发明的实质内容。在不冲突的情况下，本申请的实施例和实施例中的特征可以任意相互组合。< / style>

Claims

1. A multi-Web application integration system based on a micro-frontend architecture, characterized in that, include: Configuration module, routing module, micro-frontend component module, and Bus module; The configuration module is used to define the integration rules of the sub-application, load the sub-application by creating a sandbox environment, and proxy the interface operations within the sub-application to the protected container node within the main application. The routing module is connected to the configuration module and is used to dynamically generate application routes based on the integration rules. The micro-frontend component module is called by the routing module and is used to create containers with style isolation for sub-applications; The Bus module is used to provide an event bus instance injected into the sandbox environment to enable cross-application communication.

2. The multi-Web application integration system based on micro-frontend architecture according to claim 1, characterized in that, The configuration module creates an invisible iframe as the sandbox environment and hijacks the Document Object Model (DOM) application interface and routing application interface within the iframe to proxy operations to a container node in the main application protected by a shadow DOM, thereby achieving visual integration and strict isolation of the runtime environment.

3. The multi-Web application integration system based on micro-frontend architecture according to claim 1, characterized in that, The micro-frontend component module creates a custom Web component element for each sub-application instance, and by enabling the shadow document object model within the custom element, it creates an independent document object model tree and cascading style sheet scope for the sub-application, thereby achieving style isolation.

4. The multi-Web application integration system based on micro-frontend architecture according to claim 1, characterized in that, The event bus instance implemented by the Bus module includes a listening method and a triggering method; The listening method is used to register an event listener, and the triggering method is used to trigger an event and pass parameters; The event bus instance is injected into the global window object of the iframe where the sub-application is located, and the sub-application can directly call the listening method and triggering method to achieve decoupled cross-application communication.

5. The multi-Web application integration system based on micro-frontend architecture according to claim 1, characterized in that, The integration rules include runtime mode configurations for enabling or disabling persistent state keeping-alive; When keep-alive mode is enabled, the internal running state of the sub-application is fully preserved after switching, without the need for reloading and initialization.

6. A method for integrating multiple Web applications based on a micro-frontend architecture, characterized in that, include: Step S1: Define the integration rules for sub-applications through the configuration module; Step S2: Dynamically generate application routes based on the integration rules using the routing module; Step S3: In response to the application route, create a container with style isolation for the sub-application through the micro-frontend component module, and load the sub-application in the sandbox environment; Step S4: Inject an event bus instance into the sandbox environment through the communication module to enable cross-application communication.

7. The multi-Web application integration method based on micro-frontend architecture according to claim 6, characterized in that, The integration rules are stored in one or more configuration files; The configuration file is in JSON format and includes the unique identifier id of the sub-application, the resource entry URL, the running mode identifier alive, and lifecycle hook functions; Step S1 further includes a configuration file parsing step: the parsing process achieves serialization and deserialization of complex data types, including functions and regular expressions, by rewriting the JSON.stringify and JSON.parse methods.

8. The method for integrating multiple Web applications based on a micro-frontend architecture according to claim 7, characterized in that, Step S2 also includes routing and menu hot update steps: The main application monitors configuration file changes through a file listener. When the configuration file is modified, the configuration module reloads, parses, and pushes the new configuration information to the routing module. The routing module compares the differences between the old and new routing tables, incrementally updates the routing table, and the navigation menu component is synchronously re-rendered.

9. The multi-Web application integration method based on micro-frontend architecture according to claim 6, characterized in that, Step S3 includes: Step S3.1: Check the sub-application running mode flag "alive". If "alive" is true and the sub-application instance exists in the cache pool, restore the instance and its corresponding state directly and display it. If it is the first load or "alive" is false, execute the instance creation process. Step S3.2: Create a Web Component container named based on the sub-application ID and timestamp, and enable Shadow DOM for the container to achieve style isolation; at the same time, create a visually invisible iframe sandbox, set the src attribute of the iframe to the sub-application resource entry URL, and build an independent code execution environment; Step S3.3: After the iframe is loaded, hijack the DOM manipulation API and routing API in the child application's JS environment, and delegate the DOM manipulation to the Shadow DOM of the Web Component container, so as to achieve seamless rendering of the child application in the main application's DOM and isolation of the code execution environment.

10. The method for integrating multiple Web applications based on a micro-frontend architecture according to claim 9, characterized in that, In step S3.3, the main application uses custom CSS properties to extend the theme variable through the Shadow DOM boundary, making it available to sub-applications and enabling unified global theme switching.

Images