A front end module federation system, a front end module federation implementation method
Patent Information
- Application Number
- CN202611040443.2
- Authority / Receiving Office
- CN · China
- Patent Type
- Applications(China)
- Current Assignee / Owner
- Filing Date
- 2026-07-14
- Publication Date
- 2026-10-09
AI Technical Summary
这导致企业无法对所有模块资产进行集中管控，难以实现跨项目的模块共享和版本统一管理
本申请通过独立部署的模块注册中心对所有远程模块的元数据进行统一管理，提供了标准化的模块注册和查询接口，使得企业能够构建统一的前端模块资产库，不同团队和项目可以方便地发现和使用已有的模块，实现了前端模块的中心化治理与高效共享，极大地降低了重复开发成本，提高了模块的复用效率。且模块注册中心内置了智能版本管理模块，能够根据语义化版本规则自动解析模块间的依赖关系，检测并解决版本冲突。当宿主应用请求加载某个模块时，注册中心会返回兼容且稳定的最优版本组合，避免了因版本不匹配导致的运行时错误，提高了系统的稳定性。
Smart Images
Figure CN122884469A_ABST
Abstract
Description
Technical Field
[0001] This invention relates to the field of industrial front-end interactive system development technology, specifically to a front-end module federation system and a front-end module federation implementation method. Background Technology
[0002] With the continuous expansion of web applications and the rapid development of front-end technologies, traditional monolithic application architectures are no longer sufficient to meet the development and maintenance needs of large-scale enterprise applications. To address the complexity of monolithic applications, micro-front-end architecture has emerged, which breaks down large front-end applications into multiple independent sub-applications that can be developed and deployed separately.
[0003] Currently, mainstream micro-frontend and module federation solutions mainly include WebpackModuleFederation, Single-SPA, and qiankun. However, these existing solutions still have the following significant drawbacks in practical applications: Lack of unified centralized governance: Existing solutions typically scatter module configuration information across the build configuration files of various applications, lacking a globally unified module registration and management center. This prevents enterprises from centrally managing all module assets, making it difficult to achieve cross-project module sharing and unified version management. When multiple projects use the same module, issues such as version inconsistencies and redundant development can easily arise, significantly reducing module reuse efficiency. Poor module loading performance: Existing solutions typically require loading the code of all modules during application initialization or bundling multiple modules together during the build process. This results in an excessively large initial application package size and long initial loading time, severely impacting user experience. While some solutions support on-demand loading, they lack effective cache management and version verification mechanisms, failing to fully leverage caching to improve loading performance. Insufficient version conflict resolution capabilities: When multiple modules depend on different versions of the same third-party library, existing solutions often fail to effectively resolve version conflicts, easily leading to runtime errors. Although some solutions provide mechanisms for shared dependencies, these mechanisms require configuration at build time and lack dynamic negotiation and isolation capabilities at runtime, making them inflexible in handling complex dependency relationships. Summary of the Invention
[0004] A primary objective of this invention is to overcome at least one of the aforementioned deficiencies by providing a front-end module federation system and a front-end module federation implementation method that enables efficient sharing, loosely coupled communication, and intelligent version management of front-end modules, thereby improving module reusability, maintainability, and team collaboration efficiency.
[0005] To achieve the above objectives, the technical solution adopted by the present invention is as follows: This invention provides a front-end module federation system, which includes: The module registry center is configured to store and manage metadata information for all remote modules, and provides module registration interfaces, module query interfaces, and version management modules. At least one host application, each host application integrates a dynamic loading engine, the dynamic loading engine is configured to trigger the remote module loading requirement at runtime based on user operation or route switching, query the metadata of the target remote module from the module registry center, and asynchronously load and execute the target remote module based on the metadata; At least one remote module is developed and built in a development environment independent of the host application. After the build is completed, an independent production environment code package is generated and deployed to an independent file server or content delivery network. After deployment, its metadata is registered with the module registry center through an automated process.
[0006] According to one embodiment of the present invention, the metadata information includes at least one of the following: a unique identifier of the remote module, a semantic version number, the URL address of the entry file of the remote module code package, other remote modules it depends on and their version constraints, and the API schema interface definition of the remote module.
[0007] According to one embodiment of the present invention, the version management module of the module registry is configured to: maintain a complete version history of each remote module, parse the dependencies between remote modules according to semantic versioning rules, automatically detect and resolve version conflicts, and return a compatible and stable optimal combination of remote module versions to the host application.
[0008] According to one embodiment of the present invention, the dynamic loading engine includes: Run the parsing unit, configured to respond to trigger conditions during the host application's runtime, and generate a loading instruction containing the target remote module's unique identifier and version requirements; The metadata acquisition unit is configured to send a query request to the module registry center and receive the returned metadata of the target remote module; The asynchronous execution unit is configured to asynchronously retrieve the remote module code package from a file server or content delivery network based on the entry file URL address in the metadata, using ES6 dynamic import technology, and initialize and execute the remote module in an independent sandbox context. The cache management unit is configured to cache the loaded remote module code locally and verify the validity of the cached version with the module registry center during subsequent loading requests.
[0009] According to one embodiment of the present invention, the dynamic loading engine further includes an error isolation unit, which is configured to capture exceptions and execute a preset degradation strategy when a remote module fails to load or an execution error occurs, so as to ensure that other functions of the host application are not affected.
[0010] According to one embodiment of the present invention, the front-end module federation system further includes an event communication bus, which is introduced by the host application and all remote modules in the form of a reusable library and adopts a publish-subscribe model as the only communication channel between the host application and remote modules, as well as between any two remote modules.
[0011] According to one embodiment of the present invention, the front-end module federation system broadcasts events published by any publisher to subscribers of the events via an event communication bus, wherein the publisher is a host application or a remote module, and the subscriber is a host application or a remote module.
[0012] According to one embodiment of the present invention, the event communication bus is specifically configured to: allow publishers to carry event data in JSON format, support subscribers to filter event data, and provide one-time subscription and unsubscription functions for events.
[0013] According to one embodiment of the present invention, the host application further includes a local module, which participates in the construction process of the host application and is configured to import remote modules at runtime through a dynamic loading engine.
[0014] In particular, the present invention also provides a front-end module federation implementation method, which includes the following steps: S1. Remote module release phase: S11. Develop the remote module in a development environment independent of the host application. S12. Generate the production environment code package for the remote module through an independent build process. S13. Deploy the production environment code package to a separate file server or content delivery network. S14. Call the registration interface of the module registry center to register the metadata, including the remote module's unique identifier, semantic version number, code package entry file URL address, dependency relationship and API schema, to the module registry center; S2, Remote Module Query and Loading Phase: S21. During initialization, the host application only loads its own core code and local modules. S22. When a user operation or route change triggers a remote module loading requirement, the dynamic loading engine within the host application sends a query request containing the unique identifier and version requirements of the target remote module to the module registry center. S23. The module registry center parses dependencies according to version rules and returns the metadata of the optimal version. S24. The dynamic loading engine asynchronously loads remote module code packages from a separate file server or CDN based on the entry file URL address in the metadata. S25. The dynamic loading engine executes the initialization code of remote modules in an independent sandbox, integrating the remote modules into the host application. S3. Runtime Communication Phase: When the host application or any loaded remote module needs to interact with other entities, it publishes an event carrying data through the event communication bus as the publisher; the receiver that has pre-subscribed to the event receives the event notification and executes the corresponding business logic. The receiver is the host application or any loaded remote module.
[0015] In particular, the present invention also provides a computing device including a memory, a processor, and a computer program stored in the memory and executable by the processor, wherein the processor executes the computer program to implement the method described above.
[0016] The present invention also provides a computer-readable storage medium storing a computer program that, when executed by a processor, implements the method described above. The computer-readable storage medium is preferably a non-volatile readable storage medium.
[0017] Compared with existing technologies, the advantages and beneficial effects of the front-end module federation system and front-end module federation implementation method of this invention patent application are as follows: This application utilizes a separately deployed module registry center to centrally manage the metadata of all remote modules. It provides standardized module registration and query interfaces, enabling enterprises to build a unified front-end module asset repository. Different teams and projects can easily discover and use existing modules, achieving centralized governance and efficient sharing of front-end modules. This significantly reduces redundant development costs and improves module reusability. Furthermore, the module registry center incorporates an intelligent version management module that automatically resolves dependencies between modules based on semantic versioning rules, detecting and resolving version conflicts. When a host application requests to load a module, the registry center returns a compatible and stable optimal version combination, avoiding runtime errors caused by version incompatibility and improving system stability.
[0018] This application employs a runtime dynamic on-demand loading mechanism. During initialization, the host application only loads its core code and local modules, while remote modules are only loaded asynchronously when actually needed. Simultaneously, the dynamic loading engine incorporates a cache management unit that can cache loaded modules locally and verify the cache's validity during subsequent loading. This effectively reduces the application's initial package size and loading time, optimizes the user experience, and significantly improves application loading performance.
[0019] In addition, this application uses an event communication bus as the only communication channel between modules. Based on the publish-subscribe pattern, it realizes loosely coupled communication between modules. Modules do not need to directly reference each other's code or API. They only interact through event names and standardized data formats. This ensures that the technology selection, upgrade, replacement, or even reconstruction of a single remote module will not affect other modules, reducing the coupling between modules and greatly improving the maintainability of the system and the flexibility of technology iteration. Attached Figure Description
[0020] The following sections will describe some specific embodiments of the invention in detail by way of example and not limitation, with reference to the accompanying drawings. The same reference numerals in the drawings denote the same or similar parts or portions. Those skilled in the art should understand that these drawings are not necessarily drawn to scale. In the drawings: Figure 1 This is a schematic diagram of the framework structure of a front-end module federation system according to an embodiment of the present invention; Figure 2 This is a schematic diagram illustrating the workflow of a front-end module federation implementation method according to an embodiment of the present invention; Figure 3 This is a structural diagram of a computing device according to another embodiment of this application; Figure 4 This is a computer-readable storage medium structure diagram according to another embodiment of this application. Detailed Implementation
[0021] The technical solution of the present invention will now be clearly and completely described with reference to the accompanying drawings. Obviously, the described embodiments are only some, not all, of the embodiments of the present invention. Based on the embodiments of the present invention, all other embodiments obtained by those skilled in the art without creative effort are within the scope of protection of the present invention.
[0022] Furthermore, the technical features involved in the different embodiments of the present invention described below can be combined with each other as long as they do not conflict with each other.
[0023] Example 1: like Figure 1 As shown, the front-end module federation system described in this embodiment mainly includes four core components: a module registration center, at least one host application, at least one remote module, and an event communication bus 44.
[0024] The module registry is the core governance component of the entire system. It is a centrally deployed server that does not store the actual code packages of any remote modules. It only stores and manages the metadata information of all remote modules, provides standardized module registration and module query interfaces, and has a built-in version management module responsible for maintaining module version history, resolving dependencies, and resolving version conflicts.
[0025] By adopting an independent module registry center to uniformly manage and discover the metadata of distributed modules, the drawbacks of existing micro-frontend solutions, such as decentralized module management and difficulty in cross-project reuse, are overcome. This enables enterprises to build a unified module ecosystem, allowing different teams and projects to efficiently share and use modules developed by others, greatly reducing the cost of repetitive development.
[0026] The module registry provides the following three core interfaces: Module registration interface: Designed using a RESTful API, it receives registration requests submitted when remote modules are published. The registration request includes complete metadata information of the remote module. After verifying the format and completeness of the metadata, the module registry stores it in a MongoDB database. Module query interface: Also adopts a RESTful API design, it receives GET requests sent by the host application. Request parameters include the unique identifier and version constraints of the target remote module. The module registry queries and returns the metadata of modules that meet the requirements based on these parameters. Module deregistration interface: Used to delete the metadata information of a remote module from the module registry when the module is no longer in use.
[0027] The built-in version management module of the module registry is responsible for maintaining a complete version history for each remote module and implementing intelligent dependency resolution. It follows the Semantic Versioning 2.0.0 specification, determining version compatibility based on the major, minor, and patch version numbers. When resolving dependencies, the version management module recursively traverses the dependency tree, checking for version conflicts. If a conflict exists, it automatically resolves the conflict according to preset priority rules (such as prioritizing the latest compatible version) and returns the optimal version combination to the host application.
[0028] The host application is the main web application that integrates remote modules using this system. It can be any single-page application developed based on modern front-end frameworks (such as React, Vue, and Angular). The host application consists of two parts: local modules and a dynamic loading engine. Each host application integrates a dynamic loading engine, which is responsible for generating module loading instructions in response to triggering conditions during application runtime, querying the metadata of the target remote module from the module registry, and asynchronously loading and executing the remote module from an independent code storage facility based on the metadata.
[0029] Local modules are the host application's own business modules, such as homepage navigation and user login. They are built and deployed along with the host application and are loaded when the application starts. Local modules can import and use remote modules at runtime through a dynamic loading engine.
[0030] The dynamic loading engine is a core component of the host application. It is a lightweight JavaScript library integrated into the core code of the host application. The dynamic loading engine consists of the following five units: Runtime parsing unit: Responsible for monitoring user actions and route switching events in the host application. When a trigger condition for loading a remote module is detected (such as a user clicking a button that requires loading a payment module), the runtime parsing unit generates a loading instruction, which contains the unique identifier and version requirements of the target remote module; Metadata Acquisition Unit: Based on the loading instructions generated by the execution parsing unit, it sends an HTTP query request to the module registry center. Upon successful request, it receives and parses the returned metadata information of the target remote module. Asynchronous Execution Unit: Based on the entry file URL in the metadata, it asynchronously retrieves the code package of a remote module from a separate file server or CDN using the ES6 standard dynamic import (import()) function. After successful code loading, the asynchronous execution unit creates an independent sandbox context in which it executes the initialization code of the remote module, avoiding global variable pollution. After execution, it exposes the public interfaces exported by the remote module to the host application. The cache management unit uses the browser's localStorage or IndexedDB to cache loaded remote module code locally. The cache key is the remote module's unique identifier and version number, and the value is the module's code content. On subsequent load requests, the cache management unit first checks if a valid cache exists locally. If it does, it sends a HEAD request to the module registry to verify if the cached version still meets the current requirements. If it does, the cached code is used directly; otherwise, the latest version is reloaded. The Error Isolation Unit is responsible for capturing all exceptions that may occur during the loading and execution of remote modules, including network errors, code syntax errors, and runtime errors. When an exception is captured, the Error Isolation Unit executes a pre-defined fallback strategy, such as displaying a user-friendly error message page or loading a simplified alternative module. This ensures that the failure of a single remote module does not cause the entire host application to crash.
[0031] Thanks to a mechanism based on runtime querying and dynamic on-demand loading, the host application does not need to load all its code during initialization; it only asynchronously retrieves remote modules when actually needed. This effectively reduces the application's initial package size and initial loading time, optimizes critical rendering paths, and thus significantly improves the user's loading experience and interaction smoothness.
[0032] A remote module is a code package that is developed, built, and deployed independently of the host application. It is developed and built in an independent development environment and does not participate in any of the host application's build process. After completion, the remote module generates an independent production environment code package, which is deployed to a separate file server or content delivery network (CDN). Upon deployment, its metadata is registered with the module registry center via an automated process. A remote module can be a complete business function module (such as a payment module or user center module) or a general-purpose UI component library or tool library.
[0033] Each remote module is developed in accordance with a unified interface specification: The module must export a default initialization function that takes a configuration object as an argument and returns the module’s public API. All external dependencies of a module must be explicitly declared in the package.json file and registered in the metadata; The public interface of a module must conform to a predefined API schema to ensure consistency and compatibility of the interface.
[0034] The remote module's build process is completely independent of the host application, using the same or different build tools (such as Webpack or Vite). After build, one or more compressed and optimized production-ready code packages are generated and deployed to a separate file server or CDN. Once deployed, the CI / CD pipeline automatically calls the module registry's registration interface to register the module's metadata in the central repository.
[0035] The Event Communication Bus (ECB) is a lightweight, reusable library (similar to a JavaScript library) distributed as an npm package and included by the host application and all remote modules. Employing a publish-subscribe (Pub / Sub) design pattern, the ECB serves as the sole communication channel between all components in the system, achieving complete decoupled interaction. The ECB generally provides the following mechanisms: event publishing, where any remote module or host application can publish (trigger) an event carrying related data (typically in JSON format); and event subscription, where any remote module or host application can subscribe to events it is interested in and execute the corresponding callback function upon event publication to receive data. Through this ECB, all components can synchronize data and state without directly referencing each other's code or functions, achieving thoroughly loosely coupled communication.
[0036] The event communication bus in this embodiment provides the following core APIs: Subscribe to an event with a specified name; when the event is published, the callback function is executed. When subscribing to an event with a specified name, the callback function will only be executed once. Unsubscribe from an event with the specified name; Publish an event with the specified name, along with optional JSON data.
[0037] Based on the core APIs mentioned above, the event communication bus supports namespace isolation for events. By adding a prefix (such as "payment:success") to the event name, it avoids event name conflicts between different modules. At the same time, it supports subscribers to filter event data, and the callback function will only be executed when the event data meets specific conditions.
[0038] Because an event-driven communication bus is used as the sole channel for interaction between modules, there is no need for modules to directly reference or depend on each other, resulting in a completely loosely coupled architecture. This ensures that the technology selection, upgrades, replacements, or even refactoring of a single module will not affect other modules, greatly improving the system's maintainability and the flexibility of technology iteration.
[0039] In addition, the front-end module federation system in this application adopts an architecture that allows modules to be developed, built, versioned, and deployed independently, and combines centralized version management and dependency negotiation mechanisms. Different development teams can work in parallel, focusing on the development cycle of their own modules, without the need for frequent cross-team coordination and synchronized releases. This significantly improves the development efficiency and team autonomy of large projects.
[0040] Example 2: This embodiment describes a front-end module federation implementation method, such as Figure 2As shown, it can generally include a remote module deployment phase, a remote module query and loading phase, and a runtime communication phase, wherein: S1, the remote module release phase, may include: S11. Develop the remote module in a development environment independent of the host application. S12. Generate the production environment code package for the remote module through an independent build process. S13. Deploy the production environment code package to a separate file server or content delivery network. S14. Call the registration interface of the module registry center to register the metadata, including the remote module's unique identifier, semantic version number, code package entry file URL address, dependencies, and API schema, to the module registry center.
[0041] After the development team completes the development and testing of the remote module in an independent code repository, they push the code to the version control system. The CI / CD pipeline automatically triggers the build process, compiling, compressing, and packaging the code to generate an optimized production-ready code package. Once the build is complete, the pipeline uploads the code package to the designated CDN node and obtains the package's access URL. Finally, the pipeline calls the module registry's registration interface, submitting metadata including the module's unique identifier, version number, entry URL, dependencies, and API schema. After successful verification by the registry, this version of the remote module is officially released and available for use by all host applications.
[0042] S2, Remote Module Query and Loading Phase: S21. During initialization, the host application only loads its own core code and local modules. S22. When a user operation or route change triggers a remote module loading requirement, the dynamic loading engine within the host application sends a query request containing the unique identifier and version requirements of the target remote module to the module registry center. S23. The module registry center parses dependencies according to version rules and returns the metadata of the optimal version. S24. The dynamic loading engine asynchronously loads the remote module code package from the independent file server or CDN based on the entry file URL address in the metadata. S25. The dynamic loading engine executes the initialization code of remote modules in an independent sandbox, integrating the remote modules into the host application.
[0043] When a user accesses the host application, the application initializes by loading only the core code and local modules, presenting a basic interface. When a user performs an action (such as clicking the "Enter Payment Page" button) that triggers a remote module loading request, the dynamic loading engine's runtime parsing unit detects this event and generates a loading instruction containing the target module ID and version requirements. The cache management unit checks the local cache; if a valid cache exists, it is used directly; otherwise, the metadata acquisition unit sends a query request to the module registry. The module registry's version management module resolves dependencies and returns the metadata for the optimal version. The asynchronous execution unit downloads the remote module code package asynchronously from the CDN based on the entry URL in the metadata and executes the initialization code in an independent sandbox environment. After initialization, the remote module's public API is exposed to the host application, which calls the corresponding API to render the module's interface, completing module integration.
[0044] S3. Runtime Communication Phase: When the host application or any loaded remote module needs to interact with other entities, it publishes an event carrying data through the event communication bus as the publisher; the receiver that has pre-subscribed to the event receives the event notification and executes the corresponding business logic. The receiver is the host application or any loaded remote module.
[0045] When a loaded remote module needs to interact with other modules or the host application, it doesn't directly call the other party's API. Instead, it publishes an event through the event communication bus. For example, after a user completes a payment, the payment module publishes a "payment:success" event, carrying data such as the order ID and payment amount. Upon receiving the event, the event communication bus verifies the validity of the event format and then iterates through all callback functions that have subscribed to the event. The order module, having pre-subscribed to the "payment:success" event, will receive the event notification and execute the business logic to update the order status. Simultaneously, the host application may also have subscribed to the event to redirect to the payment success page. Throughout the entire communication process, there is no direct dependency between the payment module and the order module, achieving complete decoupling.
[0046] In addition, the front-end module federation implementation method also includes a remote module update phase. When a remote module releases a new version and registers it with the module registry, the host application automatically obtains the latest version when it loads the remote module the next time. For loaded remote modules, hot update operations can be triggered through the event communication bus without refreshing the entire page.
[0047] Specifically, when a remote module releases a new version, the module registry updates its metadata records. For new loading requests, the registry automatically returns the latest compatible version. For online users who have already loaded older versions of the module, the system supports hot updates. The module maintainer can publish module update events through the event communication bus to notify all host applications currently using the module. Upon receiving the update event, the host application's dynamic loading engine asynchronously downloads the new version module code in the background, seamlessly replacing the old version module after initialization. The entire update process is transparent to the user, requires no page refresh, and does not affect normal user operation.
[0048] This application also provides a computing device, see embodiments thereof. Figure 3 The computing device includes a memory 1120, a processor 1110, and a computer program stored in the memory 1120 and executable by the processor 1110. The computer program is stored in a space 1130 for program code in the memory 1120. When executed by the processor 1110, the computer program implements a method step 1131 according to the invention.
[0049] This application also provides a computer-readable storage medium. (See attached embodiments.) Figure 4 The computer-readable storage medium includes a storage unit for program code, the storage unit being provided with a program 1131' for performing the method steps according to the invention, the program being executed by a processor.
[0050] This application also provides a computer program product containing instructions. When the computer program product is run on a computer, it causes the computer to perform the method steps according to the invention.
[0051] In the above embodiments, implementation can be achieved, in whole or in part, through software, hardware, firmware, or any combination thereof. When implemented in software, it can be implemented, in whole or in part, as a computer program product. A computer program product includes one or more computer instructions. When a computer loads and executes the computer program instructions, all or part of the flow or function according to the embodiments of this application is generated. The computer can be a general-purpose computer, a special-purpose computer, a computer network, or other programmable device. The computer instructions can be stored in a computer-readable storage medium or transmitted from one computer-readable storage medium to another. For example, computer instructions can be transmitted from one website, computer, server, or data center to another website, computer, server, or data center via wired (e.g., coaxial cable, fiber optic, digital subscriber line (DSL)) or wireless (e.g., infrared, wireless, microwave, etc.) means. The computer-readable storage medium can be any available medium that a computer can access or a data storage device such as a server or data center that integrates one or more available media. The available medium can be a magnetic medium (e.g., floppy disk, hard disk, magnetic tape), an optical medium (e.g., DVD), or a semiconductor medium (e.g., a solid-state drive (SSD)).
[0052] Those skilled in the art will further recognize that the units and algorithm steps of the various examples described in conjunction with the embodiments disclosed herein can be implemented in electronic hardware, computer software, or a combination of both. To clearly illustrate the interchangeability of hardware and software, the components and steps of the various examples have been generally described in terms of functionality in the foregoing description. Whether these functions are implemented in hardware or software depends on the specific application and design constraints of the technical solution. Those skilled in the art can use different methods to implement the described functions for each specific application, but such implementation should not be considered beyond the scope of this application.
[0053] Those skilled in the art will understand that all or part of the steps in the methods of the above embodiments can be implemented by a program instructing a processor, and the program can be stored in a computer-readable storage medium, which is a non-transitory medium, such as random access memory, read-only memory, flash memory, hard disk, solid-state drive, magnetic tape, floppy disk, optical disk, and any combination thereof.
[0054] In particular, the present invention also provides a computing device including a memory, a processor, and a computer program stored in the memory and executable by the processor, wherein the processor executes the computer program to implement the method described above.
[0055] The present invention also provides a computer-readable storage medium storing a computer program that, when executed by a processor, implements the method described above. The computer-readable storage medium is preferably a non-volatile readable storage medium.
[0056] The above embodiments are only for illustrating the technical concept and features of the present invention. Their purpose is to enable those skilled in the art to understand the content of the present invention and implement it accordingly. They should not be used to limit the scope of protection of the present invention. All equivalent changes or modifications made in accordance with the spirit and essence of the present invention should be covered within the scope of protection of the present invention.
Claims
1. A front-end module federation system, characterized in that, include: The module registry center is configured to store and manage metadata information for all remote modules, and provides module registration interfaces, module query interfaces, and version management modules. At least one host application, each host application integrates a dynamic loading engine, the dynamic loading engine is configured to, at runtime, trigger a remote module loading requirement based on user operation or route switching, query the metadata of the target remote module from the module registry center, and asynchronously load and execute the target remote module based on the metadata; At least one remote module is developed and built in a development environment independent of the host application. After the build is completed, an independent production environment code package is generated and deployed to an independent file server or content delivery network. After deployment, its metadata is registered with the module registry center through an automated process.
2. The front-end module federation system according to claim 1, characterized in that, The metadata information includes at least one of the following: a unique identifier for the remote module, a semantic version number, the URL address of the entry file of the remote module's code package, other remote modules it depends on and their version constraints, and the API schema interface definition of the remote module.
3. The front-end module federation system according to claim 1, characterized in that, The version management module of the module registry is configured to: maintain a complete version history of each remote module, parse the dependencies between remote modules according to semantic versioning rules, automatically detect and resolve version conflicts, and return a compatible and stable optimal combination of remote module versions to the host application.
4. The front-end module federation system according to claim 1, characterized in that, The dynamic loading engine includes: Run the parsing unit, configured to respond to trigger conditions during the host application's runtime, and generate a loading instruction containing the target remote module's unique identifier and version requirements; The metadata acquisition unit is configured to send a query request to the module registration center and receive the returned metadata of the target remote module; An asynchronous execution unit is configured to asynchronously obtain a remote module code package from the file server or content delivery network based on the entry file URL address in the metadata using ES6 dynamic import technology, and initialize and execute the remote module in an independent sandbox context. The cache management unit is configured to cache the loaded remote module code locally and verify the validity of the cached version with the module registry center during subsequent loading requests.
5. The front-end module federation system according to claim 4, characterized in that, The dynamic loading engine also includes an error isolation unit, which is configured to capture exceptions and execute preset degradation strategies when remote modules fail to load or encounter execution errors, ensuring that other functions of the host application are not affected.
6. The front-end module federation system according to claim 1, characterized in that, The front-end module federation system also includes an event communication bus, which is introduced by the host application and all remote modules in the form of a reusable library. The event communication bus adopts a publish-subscribe model as the only communication channel between the host application and remote modules, as well as between any two remote modules.
7. The front-end module federation system according to claim 6, characterized in that, The front-end module federation system broadcasts events published by any publisher to recipients subscribing to the events via the event communication bus, wherein the publisher is the host application or a remote module, and the recipient is the host application or a remote module.
8. The front-end module federation system according to claim 6 or 7, characterized in that, The event communication bus is specifically configured to allow publishers to carry event data in JSON format, support subscribers to filter the event data, and provide one-time subscription and unsubscription functions for events.
9. The front-end module federation system according to claim 1, characterized in that, The host application also includes a local module that participates in the host application's construction process and is configured to import remote modules at runtime through the dynamic loading engine.
10. A method for implementing a front-end module federation, characterized in that, Includes the following steps, S1. Remote module release phase: S11. Develop the remote module in a development environment independent of the host application. S12. Generate the production environment code package for the remote module through an independent build process. S13. Deploy the production environment code package to a separate file server or content delivery network. S14. Call the registration interface of the module registry center to register the metadata, including the remote module's unique identifier, semantic version number, code package entry file URL address, dependency relationship and API schema, to the module registry center; S2, Remote Module Query and Loading Phase: S21. During initialization, the host application only loads its own core code and local modules. S22. When a user operation or route change triggers a remote module loading requirement, the dynamic loading engine within the host application sends a query request containing the unique identifier and version requirements of the target remote module to the module registry center. S23. The module registry center parses dependencies according to version rules and returns the metadata of the optimal version. S24. The dynamic loading engine asynchronously loads the remote module code package from the independent file server or CDN based on the entry file URL address in the metadata. S25. The dynamic loading engine executes the initialization code of remote modules in an independent sandbox, integrating the remote modules into the host application. S3, Runtime Communication Phase: When the host application or any loaded remote module needs to interact with other entities, it publishes events carrying data through the event communication bus as the publisher. The recipient that has pre-subscribed to the event receives the event notification and executes the corresponding business logic. The recipient is the host application or any loaded remote module.