Micro-service front-end integration system and method and medium

Abstract

The invention provides a micro-service front-end integration system and method and a medium. The system comprises a main application container layer, a construction platform and at least one sub-application, the main application container layer is in communication connection with each sub-application, and the construction platform is connected with the main application container layer and each sub-application; the main application container layer is used for realizing dynamic routing matching of a sub-application interface, performing life cycle management on a sub-application and completing loading and unloading of the sub-application; the sub-applications are independent front-end applications, and each sub-application is a sub-application with an independent code library and double sandbox isolation; and the construction platform is used for realizing construction, testing and deployment of the sub-applications. According to the method, the flexibility, the efficiency and the maintainability of front-end application development can be improved.

Description

Technical Field

[0001] This application relates to the field of application development technology, and in particular to a microservice front-end integration system, method and medium. Background Technology

[0002] With the increasing prevalence of Single Page Applications (SPAs), front-end projects are becoming increasingly complex and large. In terms of business development, traditional monolithic front-end technologies package all functionalities into a single application. As business grows, the codebase expands, code coupling increases, hindering continuous business expansion. Front-end performance issues, such as slow initial page load times and large packaged file sizes, begin to emerge. In terms of development processes, multiple developers working on the same codebase simultaneously increase the risk of code conflicts and maintenance costs. Regarding deployment, any issue, large or small, requires a full release and update, impacting the iteration speed of agile development and hindering operational processes such as customer environment upgrades. Summary of the Invention

[0003] In view of this, this application provides a microservice front-end integration system, method and medium, which addresses the above-mentioned technical problems by introducing a microservice framework to fundamentally increase flexibility, efficiency and maintainability.

[0004] According to one aspect of this application, a microservice front-end integration system is provided, including a main application container layer, at least one sub-application, and a build platform; the main application container layer is communicatively connected to each sub-application, and the build platform is connected to both the main application container layer and each sub-application.

[0005] The main application container layer is used to implement dynamic routing to match sub-application interfaces, manage the lifecycle of sub-applications, and complete the loading and unloading of sub-applications.

[0006] The sub-applications are independent front-end applications, each with its own codebase and dual sandbox isolation.

[0007] The platform is used to build, test, and deploy sub-applications.

[0008] In one implementation, the main application container layer includes a loader, which is used to preload potentially needed sub-application resources when the main application is idle, and when the sub-application is triggered to load, it requests the resource list of the sub-application from the CDN, and obtains the JS and CSS files of the sub-application in parallel based on the resource list. At the same time, after the resources are loaded, it initializes the dual sandbox system of the sub-application and notifies the sub-application to execute the loading command to complete the loading.

[0009] In one implementation, the main application container layer includes a routing distribution unit, which defines routing rules in JSON Schema format. The routing rules include path information, dynamic matching rules, route-level attribute passing information, and / or asynchronous loader information. The dynamic matching rules implement dynamic injection of regular expressions for path matching through the activeRule field.

[0010] In one implementation, the main application container layer further includes a lifecycle management unit, which dynamically updates the routing configuration through the registerMicroApps() API to control the sub-applications to complete the routing configuration update without restarting the main application.

[0011] In one implementation, the sub-application includes a dual sandbox system comprising a JS sandbox and a CSS-scoped isolation sandbox; the JS sandbox is used to isolate global variables and events of each sub-application; and the CSS-scoped isolation sandbox is used to isolate styles of each sub-application.

[0012] In one implementation, the JS sandbox is a proxy sandbox, which includes a fakeWindow object and a proxy object. The proxy object takes the window as the target object. When a property is retrieved, it returns the property of the window or the property of the fakeWindow. When a property is set, the property value is stored in the fakeWindow object.

[0013] In one implementation, the CSS Scoped isolation sandbox processes CSS styles through a preset function that replaces class selectors in the CSS with class selectors that include a prefix.

[0014] In one implementation, the build platform includes a differential build system that performs incremental builds based on Git change sets to achieve differentiated upgrades of sub-applications.

[0015] According to one aspect of this application, a microservice front-end integration method is provided, applied to the microservice front-end integration system, comprising the following steps:

[0016] The main application container layer matches the sub-application interface according to dynamic routing rules through the routing distribution unit;

[0017] When a sub-application is triggered to load, the loader of the main application container layer requests the resource list of the sub-application from the CDN;

[0018] After the CDN returns the resource list, the loader retrieves the JS and CSS files of the sub-application in parallel.

[0019] The loader initializes the dual sandbox system for the sub-application to control the lifecycle of the sub-application.

[0020] Once loading is complete, the loader notifies the sub-application to execute the loading command to complete the loading of the sub-application;

[0021] When a child application is no longer needed, the main application container layer uninstalls the child application.

[0022] According to one aspect of this application, a storage medium is provided that stores a computer program, wherein the computer program is configured to execute the above-described microservice front-end integration method at runtime.

[0023] By means of the above technical solution, this application provides a microservice front-end integration system and method, which integrates web microservice solutions based on a microservice framework, improves the shortcomings and defects in the prior art, and brings at least the following advantages.

[0024] First, in terms of business development, we will implement business isolation, differentiate projects according to business scenarios, and split a single SPA into multiple independent sub-applications to achieve on-demand loading and expansion, thereby increasing flexibility and scalability.

[0025] In existing technologies, monolithic Single-Application Programs (SPAs) package all functions into a single application. As business grows, code coupling increases, leading to problems such as slow initial page load and limited scalability. However, in this embodiment, a single SPA is split into multiple independent sub-applications (such as "user management" and "transaction settlement" sub-applications in a financial system). The main application container layer acts as a coordination center, using dynamic routing to load sub-applications on demand. For example, when a user only operates the "user management" module, the main application only loads the resources of that sub-application, without loading unrelated sub-applications such as "transaction settlement." This directly reduces the amount of resources required for initial page load and solves the problem of slow initial page load in traditional monolithic applications. Furthermore, sub-applications are differentiated according to business scenarios, with each sub-application focusing on a specific business scenario, achieving business logic isolation. A dual sandbox system (JS sandbox and CSS-scorched isolation sandbox) further ensures the independent operation of sub-applications, preventing business logic from interfering with each other due to code coupling. When a business scenario needs to be expanded (such as adding cross-border payment function to "transaction settlement"), only the sub-application needs to be upgraded, without modifying other sub-applications or the main application. This greatly improves the iteration cycle of a single business module, for example, shortening it from two weeks to three days, while also ensuring a high deployment success rate.

[0026] Second, in terms of the development process, multiple code repositories are created to manage each independent sub-application. Each sub-application has its own code repository, and the independent front-end and back-end architecture, development, and code maintenance are mutually independent.

[0027] In traditional monolithic applications, multiple developers share a single codebase, leading to a high risk of code conflicts and a sharp increase in maintenance costs as the application grows. In this embodiment, sub-applications are explicitly defined as having "separate codebases," with each sub-application possessing an independent front-end and back-end architecture (such as independent Git repositories and development branches). This means different teams can develop different sub-applications in parallel (e.g., team A develops "report analysis," and team B develops "user management"). Code submissions, reviews, and merging are all performed within their respective codebases, fundamentally reducing the probability of code conflicts in multi-user collaboration. Furthermore, the lifecycle management unit supports dynamic updates to routing configurations (e.g., via the registerMicroApps() API). During development, sub-application feature iterations can be tested and verified independently without waiting for the development progress of other sub-applications. For example, when a data visualization module is added to the "report analysis" sub-application, the development team can debug this module independently without affecting the normal development process of the "user management" sub-application, significantly reducing the maintenance costs of cross-team collaboration.

[0028] Third, after splitting the codebase, the sub-applications were developed, tested, operated, and deployed independently, which enabled independent upgrades and deployments of the sub-applications and accelerated the delivery process.

[0029] Traditional monolithic applications require a full release for even minor changes, resulting in slow iteration speeds and impacting agile development pace. In this embodiment, the differential build system uses Git changesets for incremental builds. When a sub-application is modified, only the modified portion needs to be packaged (e.g., in the "User Management" sub-application, only the password verification logic is updated, and the build platform only generates an incremental package for that part), instead of a full application build. This significantly shortens build time and improves deployment efficiency. Furthermore, the loader supports independent loading and unloading of sub-applications, allowing them to complete the entire development, testing, and deployment process independently. For example, after fixing a bug in the "Transaction Settlement" sub-application, it can be independently deployed to the production environment. Users do not need to wait for a full system update; they only need to load the latest version when accessing the sub-application, achieving an agile delivery model of "partial upgrade, global availability," significantly accelerating iteration cycles and delivery speed.

[0030] In summary, this application's embodiments utilize a divide-and-conquer strategy to break down complex single-page front-end applications into highly cohesive, loosely coupled sub-applications, thereby significantly improving development, business expansion, operation, and delivery speed. Through a system architecture of "main application container layer - sub-application - build platform," dynamic routing, sandbox isolation, and independent deployment, the shortcomings of traditional monolithic front-end applications are thoroughly addressed from three dimensions: business architecture, development collaboration, and deployment process, achieving a comprehensive improvement in flexibility, efficiency, and maintainability.

[0031] The above description is only an overview of the technical solution of this application. In order to better understand the technical means of this application and to implement it in accordance with the contents of the specification, and to make the above and other objects, features and advantages of this application more obvious and understandable, the following are specific embodiments of this application. Attached Figure Description

[0032] The accompanying drawings, which are included to provide a further understanding of this application and form part of this application, illustrate exemplary embodiments and are used to explain this application, but do not constitute an undue limitation of this application. In the drawings:

[0033] Figure 1 This illustration shows a schematic diagram of a microservice front-end integration system architecture provided in an embodiment of this application;

[0034] Figure 2 This illustration shows a schematic diagram of a dual sandbox principle for a sub-application container in a microservice front-end integration system provided in an embodiment of this application.

[0035] Figure 3 This paper illustrates a flowchart of a multi-version parallel loading process in a microservice front-end integration system provided by an embodiment of this application.

[0036] Figure 4 A flowchart of a microservice front-end integration method provided in an embodiment of this application is shown. Detailed Implementation

[0037] To enable those skilled in the art to better understand the present application, the technical solutions in the embodiments of the present application will be clearly and completely described below with reference to the accompanying drawings. Obviously, the described embodiments are only a part of the embodiments of the present application, and not all of them. Based on the embodiments of the present application, all other embodiments obtained by those skilled in the art without creative effort should fall within the scope of protection of the present application. It should be noted that, unless otherwise specified, the embodiments and features in the embodiments of the present application can be combined with each other.

[0038] As analyzed earlier, existing front-end and back-end frameworks for current single-page applications (SPAs) suffer from several problems, including high performance overhead, high coupling, and increased maintenance costs. These problems hinder business expansion and make it difficult to provide a better front-end interactive experience.

[0039] Therefore, this application provides a microservice solution, and in particular relates to a multi-application integration system and method based on a microservice architecture (such as the Qiankun microservice architecture), which is suitable for the modular development and deployment of enterprise-level web applications.

[0040] The specific architecture design is as follows: Figure 1As shown. The entire system comprises three core components, which will be described in detail below.

[0041] 1. The main application container layer implements dynamic routing to match sub-application interfaces, manages the lifecycle of sub-applications, and completes the loading and unloading mechanisms for sub-applications. In dynamic routing configuration, routing rules can be defined using JSON Schema format, and the `activeRule` field enables dynamic injection of regular expressions for path matching. A specific definition example is as follows:

[0042]

[0043] During runtime, the routing configuration can be dynamically updated via the registerMicroApps() API without restarting the application. This hot update mechanism for routing rules has significant advantages over traditional solutions.

[0044] II. Sub-application container, which contains the implementation of a dual sandbox system, its schematic diagram is as follows: Figure 2 As shown, it includes a JS sandbox and a CSSScoped isolation sandbox to ensure that global variables or events between sub-applications do not affect each other and styles are isolated from each other; and it implements a resource loader for sub-applications to support preloading and dependency analysis, enabling on-demand loading of dependencies.

[0045] like Figure 2 As shown, the process includes:

[0046] A. Initialization Phase

[0047] 1. Load sub-applications;

[0048] 2. Create a sandbox;

[0049] 3. Rebuild the global API;

[0050] B. Operation Phase

[0051] 1. Sub-application execution;

[0052] 2. Global access interception;

[0053] 3. Environment variable manipulation;

[0054] C. Destruction Phase

[0055] 1. Uninstall sub-applications;

[0056] 2. Clean up memory references;

[0057] 3. Restore the environment.

[0058] The key technical points are illustrated in the code examples below:

[0059]

[0060]

[0061]

[0062] Thirdly, regarding version deployment, a differential build system is implemented, enabling incremental builds based on Git change sets, thereby achieving differentiated upgrades and improving iteration speed. In the version coordination service, multiple versions can be loaded in parallel, loading the same dependencies from different versions. The specific process is as follows: Figure 3 As shown, it includes the following steps:

[0063] 1. The main application triggers application loading (app1) to the loader;

[0064] 2. The loader requests manifest.json from the CDN network;

[0065] 3. The CDN returns a resource list to the loader;

[0066] 4. The loader loads JS and CSS files from the CDN in parallel;

[0067] 5. The loader initializes the sandbox environment for the sub-application based on the loaded files;

[0068] 6. The sub-application reports lifecycle readiness to the loader;

[0069] 7. The loader sends a notification to the main application that loading is complete;

[0070] 8. The main application executes mount() to complete the loading of the sub-application.

[0071] Depend on Figure 3 The process shown demonstrates that when the main application is idle, it preloads potentially needed sub-application resources and reuses common external dependency libraries through external methods to achieve dependency sharing. Page caching can adopt long-term caching based on content hashing to improve page access speed and optimize user experience.

[0072] This application provides a microservice front-end integration system, including a main application container layer, at least one sub-application, and a build platform. The main application container layer is communicatively connected to each sub-application, and the build platform is connected to both the main application container layer and each sub-application. The main application container layer is used to dynamically route and match sub-application interfaces, manage the lifecycle of sub-applications, and load and unload them. Each sub-application is an independent front-end application with its own codebase. The build platform is used to build, test, and deploy the sub-applications. In this system, the traditional monolithic front-end application is broken down into an independently running cluster of sub-applications through a three-layer architecture of "main application container layer + sub-application + build platform." The main application acts as a coordination center to integrate and manage the sub-applications, while the build platform provides full lifecycle support. For example, in a financial information system, "user management," "transaction settlement," and "report analysis" can be split into three sub-applications. The main application container layer is responsible for page navigation and access control, while the build platform handles the packaging and deployment of each sub-application separately. This achieves business isolation and independent expansion, solving the problems of high coupling and difficult maintenance associated with traditional monolithic applications.

[0073] In one implementation, the main application container layer includes a loader. The loader preloads potentially needed sub-application resources when the main application is idle. When a sub-application is triggered to load, the loader requests a resource list from the CDN and, based on this list, retrieves the sub-application's JS and CSS files in parallel. Simultaneously, after resource loading is complete, the loader initializes the sub-application's dual sandbox system and notifies the sub-application to execute a loading command to complete the loading process. In this implementation, the loader optimizes resource loading efficiency through a process of "preloading + parallel requests + sandbox initialization," combined with CDN to achieve distributed resource acquisition. For example, when a user is on the "Homepage," the loader preloads the basic resources of the "Transaction Settlement" sub-application; when the user clicks "Transaction Settlement," the loader retrieves the resource list from the CDN and downloads JS and CSS files simultaneously, quickly completing page rendering. This reduces the waiting time after user interaction and significantly improves the first-screen loading speed.

[0074] In one implementation, the main application container layer includes a routing dispatch unit. This unit defines routing rules using JSON Schema format. Each routing rule contains path information, dynamic matching rules, route-level attribute information, and / or asynchronous loader information. Dynamic matching rules are implemented through the `activeRule` field, which dynamically injects regular expressions for path matching. The `activeRule` field supports three matching modes: regular expressions, function callbacks, and strings. Route parsing time is controlled within 5ms. JSON Schema-formatted routing rules are structured and extensible. The `activeRule` field supports regular expression injection, making route matching more flexible. For example, defining the routing rule `{path:' / trade',activeRule:' / trade / *'}`, when a user accesses ` / trade / payment`, the routing dispatch unit matches the "transaction settlement" sub-application using regular expressions and passes `{userId:123}` as a route attribute. This achieves dynamic binding between the sub-application and the URL path, supporting route navigation in complex business scenarios.

[0075] In one implementation, the main application container layer also includes a lifecycle management unit. This unit dynamically updates routing configurations via the `registerMicroApps()` API, allowing sub-applications to update their routing configurations without restarting the main application. Specifically, hot updates of routing configurations can be implemented using the `registerMicroApps()` API of the Qiankun microservice framework, taking effect without interrupting the main application. For example, when the "Report Analysis" sub-application adds a "Real-time Data" feature, the lifecycle management unit calls the API to add a routing rule of `{path:' / report / real-time',...}`, allowing users to access the new feature without refreshing the page. This supports dynamically expanding business functionality and avoids service interruptions caused by full deployments.

[0076] In one implementation, the sub-applications include a dual sandbox system, comprising a JS sandbox and a CSSScoped isolation sandbox. The JS sandbox isolates global variables and events within each sub-application, while the CSSScoped isolation sandbox isolates styles for each sub-application. The JS sandbox isolates global variables through a proxy mechanism, while the CSS sandbox isolates styles through class name prefixes, preventing code conflicts between sub-applications. For example, the `window.userInfo` variable defined in the "User Management" sub-application only takes effect within its own sandbox and will not override the variable with the same name in the "Transaction Settlement" sub-application; the `.btn` style of the former is automatically prefixed with `.user-app-btn` to avoid conflict with the `.btn` style of the latter. This completely resolves the code pollution problem between sub-applications and ensures the stability of multi-application integration.

[0077] In one implementation, the JS sandbox is a proxy sandbox, consisting of a fakeWindow object and a proxy object. The proxy object targets the window object; when retrieving a property, it returns either the window's property or the fakeWindow's property; when setting a property, it stores the property value in the fakeWindow object. Specifically, the proxy sandbox can be implemented based on ES6 Proxy. The fakeWindow acts as a "private global object" for the sub-application, and the proxy object is responsible for intercepting property read and write operations, prioritizing the use of the sub-application's private variables, and falling back to the global window when undefined. For example, when the sub-application executes `window.title = 'Transaction Page'`, the value is stored in the fakeWindow; when executing `console.log(window.location)`, the proxy object returns the global window's `location` property. Thus, while isolating the sub-application's global variables, normal access to the browser's native APIs is guaranteed.

[0078] In one implementation, the CSS Scoped isolation sandbox processes CSS styles through preset functions. These functions replace class selectors in the CSS with class selectors that include a prefix. Regular expressions are used to add a child-application-specific prefix to the CSS class names, ensuring that styles only apply to the DOM elements of the current child application. For example, if the preset function receives the CSS code `.btn{color:red;}` and the prefix `trade-app`, it will process it and output `.trade-app.btn{color:red;}`, ensuring that the style only applies to the button in the "Trade Settlement" child application. This avoids global style pollution, allowing child applications to define styles independently without worrying about conflicts.

[0079] In one implementation, the build platform includes a differential build system. This system performs incremental builds based on Git change sets, enabling differentiated upgrades of sub-applications. By analyzing the change files in Git commit records, only the modified parts are repackaged to generate an incremental update package, rather than a full build. For example, if the "Report Analysis" sub-application only modifies the chart rendering logic, the differential build system only repackages chart.js and its dependencies, generating a 100KB incremental package instead of a 5MB full package. This shortens build time, reduces release bandwidth consumption, and accelerates the iteration cycle.

[0080] Corresponding to the above system, this application also provides a microservice front-end integration method, see [link to relevant documentation]. Figure 4 This includes the following steps:

[0081] S401: The main application container layer matches the sub-application interface according to dynamic routing rules through the routing distribution unit;

[0082] S402: When a sub-application is triggered to load, the loader of the main application container layer requests the resource list of the sub-application from the CDN;

[0083] S403: After the CDN returns the resource list, the loader retrieves the JS and CSS files of the sub-application in parallel;

[0084] S404: The loader initializes the dual sandbox system of the sub-application to control the lifecycle of the sub-application.

[0085] S405: The loader notifies the sub-application to execute the loading command operation, completing the loading of the sub-application;

[0086] S406: When a child application is no longer needed, the main application container layer uninstalls the child application.

[0087] As can be seen, the embodiments of this application address the shortcomings of the prior art by providing a microservice front-end integration system and method, integrating web microservice solutions based on a microservice framework, improving upon the aforementioned shortcomings and defects, and specifically bringing at least the following advantages.

[0088] First, in terms of business development, we will implement business isolation, differentiate projects according to business scenarios, and split a single SPA into multiple independent sub-applications to achieve on-demand loading and expansion, thereby increasing flexibility and scalability.

[0089] In existing technologies, monolithic Single-Application Modules (SPAs) package all functions into a single application. As business grows, code coupling increases, leading to problems such as slow initial page load and limited scalability. However, in this embodiment, a single SPA is split into multiple independent sub-applications (such as "User Management" and "Transaction Settlement" sub-applications in a financial system). The main application container layer acts as a coordination center, using dynamic routing to load sub-applications on demand. For example, when a user only operates the "User Management" module, the main application only loads the resources of that sub-application, without loading unrelated sub-applications such as "Transaction Settlement." This directly reduces the amount of resources required for initial page load and solves the problem of slow initial page load in traditional monolithic applications. Furthermore, sub-applications are differentiated according to business scenarios, with each sub-application focusing on a specific business scenario, achieving business logic isolation. A dual sandbox system (JS sandbox and CSS-scorched isolation sandbox) further ensures the independent operation of sub-applications, preventing business logic from interfering with each other due to code coupling. When a business scenario needs to be expanded (such as adding cross-border payment functionality to "Transaction Settlement"), only that sub-application needs to be upgraded, without modifying other sub-applications or the main application, greatly improving the flexibility of business expansion.

[0090] Second, in terms of the development process, multiple code repositories are created to manage each independent sub-application. Each sub-application has its own code repository, and the independent front-end and back-end architecture, development, and code maintenance are mutually independent.

[0091] In traditional monolithic applications, multiple developers share a single codebase, leading to a high risk of code conflicts and a sharp increase in maintenance costs as the application grows. In this embodiment, sub-applications are explicitly defined as having "separate codebases," with each sub-application possessing an independent front-end and back-end architecture (such as independent Git repositories and development branches). This means different teams can develop different sub-applications in parallel (e.g., team A develops "report analysis," and team B develops "user management"). Code submissions, reviews, and merging are all performed within their respective codebases, fundamentally reducing the probability of code conflicts in multi-user collaboration. Furthermore, the lifecycle management unit supports dynamic updates to routing configurations (e.g., via the registerMicroApps() API). During development, sub-application feature iterations can be tested and verified independently without waiting for the development progress of other sub-applications. For example, when a data visualization module is added to the "report analysis" sub-application, the development team can debug this module independently without affecting the normal development process of the "user management" sub-application, significantly reducing the maintenance costs of cross-team collaboration.

[0092] Third, after splitting the codebase, the sub-applications were developed, tested, operated, and deployed independently, which enabled independent upgrades and deployments of the sub-applications and accelerated the delivery process.

[0093] Traditional monolithic applications require a full release for even minor changes, resulting in slow iteration speeds and impacting agile development pace. In this embodiment, the differential build system uses Git changesets for incremental builds. When a sub-application is modified, only the modified portion needs to be packaged (e.g., in the "User Management" sub-application, only the password verification logic is updated, and the build platform only generates an incremental package for that part), instead of a full application build. This significantly shortens build time and improves deployment efficiency. Furthermore, the loader supports independent loading and unloading of sub-applications, allowing them to complete the entire development, testing, and deployment process independently. For example, after fixing a bug in the "Transaction Settlement" sub-application, it can be independently deployed to the production environment. Users do not need to wait for a full system update; they only need to load the latest version when accessing the sub-application, achieving an agile delivery model of "partial upgrade, global availability," significantly accelerating iteration cycles and delivery speed.

[0094] In summary, this application's embodiments utilize a divide-and-conquer strategy to break down complex single-page front-end applications into highly cohesive, loosely coupled sub-applications, thereby significantly improving development, business expansion, operation, and delivery speed. Through a system architecture of "main application container layer - sub-application - build platform," dynamic routing, sandbox isolation, and independent deployment, the shortcomings of traditional monolithic front-end applications are thoroughly addressed from three dimensions: business architecture, development collaboration, and deployment process, achieving a comprehensive improvement in flexibility, efficiency, and maintainability.

[0095] Embodiments of this application also provide a storage medium storing a computer program, wherein the computer program is configured to execute the steps in any of the above method embodiments when running.

[0096] Optionally, in this embodiment, the storage medium may include, but is not limited to, various media capable of storing computer programs, such as USB flash drives, read-only memory (ROM), random access memory (RAM), portable hard drives, magnetic disks, or optical disks.

[0097] Optionally, specific examples in this embodiment can refer to the examples described in the above embodiments and optional implementations, and will not be repeated here.

[0098] The sequence numbers of the embodiments in this application are for descriptive purposes only and do not represent the superiority or inferiority of the embodiments.

[0099] In the above embodiments of this application, the descriptions of each embodiment have different focuses. For parts not described in detail in a certain embodiment, please refer to the relevant descriptions of other embodiments.

[0100] In the several embodiments provided in this application, it should be understood that the disclosed technical content can be implemented in other ways. The device embodiments described above are merely illustrative; for example, the division of units is only a logical functional division, and in actual implementation, there may be other division methods. For example, multiple units or components may be combined or integrated into another system, or some features may be ignored or not executed. Furthermore, the displayed or discussed mutual coupling, direct coupling, or communication connection may be through some interfaces; the indirect coupling or communication connection between units or modules may be electrical or other forms.

[0101] The units described as separate components may or may not be physically separate. The components shown as units may or may not be physical units; that is, they may be located in one place or distributed across multiple network units. Some or all of the units can be selected to achieve the purpose of this embodiment according to actual needs.

[0102] Furthermore, the functional units in the various embodiments of this application can be integrated into one processing unit, or each unit can exist physically separately, or two or more units can be integrated into one unit. The integrated unit can be implemented in hardware or as a software functional unit.

[0103] If the integrated unit is implemented as a software functional unit and sold or used as an independent product, it can be stored in a computer-readable storage medium. Based on this understanding, the technical solution of this application, in essence, or the part that contributes to the prior art, or all or part of the technical solution, can be embodied in the form of a software product. This computer software product is stored in a storage medium and includes several instructions to cause a computer device (which may be a personal computer, server, or network device, etc.) to execute all or part of the steps of the methods described in the various embodiments of this application. The aforementioned storage medium includes various media capable of storing program code, such as USB flash drives, read-only memory (ROM), random access memory (RAM), portable hard drives, magnetic disks, or optical disks.

[0104] The above description is only a preferred embodiment of this application. It should be noted that for those skilled in the art, several improvements and modifications can be made without departing from the principle of this application, and these improvements and modifications should also be considered within the scope of protection of this application.

Claims

1. A microservice front-end integration system, characterized in that, It includes a main application container layer, a build platform, and at least one sub-application; the main application container layer is communicatively connected to each sub-application, and the build platform is connected to both the main application container layer and each sub-application. The main application container layer is used to implement dynamic routing to match sub-application interfaces, manage the lifecycle of sub-applications, and complete the loading and unloading of sub-applications. The sub-applications are independent front-end applications, each with its own codebase and dual sandbox isolation. The platform is used to build, test, and deploy sub-applications.

2. The system according to claim 1, characterized in that, The main application container layer includes a loader, which is used to preload potentially needed sub-application resources when the main application is idle. When the sub-application is triggered to load, the loader requests the resource list of the sub-application from the CDN and obtains the JS and CSS files of the sub-application in parallel based on the resource list. After the resources are loaded, the loader initializes the dual sandbox system of the sub-application and notifies the sub-application to execute the loading command to complete the loading.

3. The system according to claim 1, characterized in that, The main application container layer includes a routing distribution unit, which defines routing rules in JSON Schema format. The routing rules include path information, dynamic matching rules, route-level attribute passing information, and / or asynchronous loader information. The dynamic matching rules implement dynamic injection of regular expressions for path matching through the activeRule field.

4. The system according to claim 3, characterized in that, The main application container layer also includes a lifecycle management unit, which dynamically updates the routing configuration through the registerMicroApps() API to control the sub-applications to complete the routing configuration update without restarting the main application.

5. The system according to claim 1, characterized in that, The sub-application includes a dual sandbox system, which comprises a JS sandbox and a CSS Scoped isolation sandbox; the JS sandbox is used to isolate global variables and events of each sub-application; the CSS Scoped isolation sandbox is used to isolate styles of each sub-application.

6. The system according to claim 5, characterized in that, The JS sandbox is a proxy sandbox, which includes a fakeWindow object and a proxy object. The proxy object takes the window as the target object. When a property is retrieved, it returns the property of the window or the property of the fakeWindow. When a property is set, the property value is stored in the fakeWindow object.

7. The system according to claim 5, characterized in that, The CSS Scoped isolation sandbox processes CSS styles through preset functions, which replace class selectors in CSS with class selectors that include a prefix.

8. The system according to claim 1, characterized in that, The build platform includes a differential build system, which performs incremental builds based on Git change sets to achieve differentiated upgrades of sub-applications.

9. A microservice front-end integration method, characterized in that, The microservice front-end integration system described in any one of claims 1-8 includes the following steps: The main application container layer matches the sub-application interface according to dynamic routing rules through the routing distribution unit; When a sub-application is triggered to load, the loader of the main application container layer requests the resource list of the sub-application from the CDN; After the CDN returns the resource list, the loader retrieves the JS and CSS files of the sub-application in parallel. The loader initializes the dual sandbox system for the sub-application to control the lifecycle of the sub-application. The loader instructs the sub-application to execute the loading command operation to complete the loading of the sub-application; When a child application is no longer needed, the main application container layer uninstalls the child application.

10. A storage medium, characterized in that, The storage medium stores a computer program, wherein the computer program is configured to execute the method of claim 9 at runtime.

Images