Micro-frontend-based back office integration method, system, device and storage medium

Abstract

This invention provides a method, system, device, and storage medium for integrated middle and back-end systems based on a micro-frontend. The method includes: constructing a unified base and connecting sub-applications; parsing access addresses and reading project configurations; executing a preprocessing lifecycle and loading page resources; executing a page registration lifecycle to complete permission menu linkage and state coordination; handling collaborative work between low-code and source code versions and resource release when the page leaves. By integrating a unified entry point, address parsing, lifecycle scheduling, permission menu linkage, state sharing, and low-code collaboration onto a single base, this invention enables hybrid operation and gradual migration of source code and low-code pages, establishes a unified sub-application operation mechanism, converges common dependencies and project access methods, and significantly improves the development efficiency and maintainability of the middle and back-end system.

Description

Technical Field

[0001] This invention relates to the field of software development, and more specifically, to a method, system, device, and storage medium for integrated middle and back-end systems based on micro-frontends. Background Technology

[0002] As enterprise applications continue to expand, the front-end and back-end domains are facing increasingly complex business scenarios and development challenges. Traditional solutions mainly include local development models based on pure scaffolding (such as Vue Admin and React Admin), pure low-code / no-code platform deployment models, and front-end applications that are independently maintained and deployed by each business line. While these solutions have certain applicability in specific scenarios, their inherent technical shortcomings are gradually being exposed in the context of integrated enterprise-level back-end management, making it difficult to meet the comprehensive requirements of modern enterprises for development efficiency, system maintainability, and rapid business iteration.

[0003] Existing technologies have the following main drawbacks in mid-to-back-end scenarios: First, the development model is too simplistic and lacks flexibility. Existing technologies either only support local coding or a purely low-code drag-and-drop mode, failing to simultaneously meet the mixed needs of different scenarios within the same system, such as complex business logic development, rapid construction of simple pages, and frequent iterations. Developers must write a large amount of code when dealing with complex interactive pages, while having to go through cumbersome engineering processes when dealing with simple display pages, resulting in low development efficiency.

[0004] Second, the lack of a unified engineering foundation leads to poor reusability. Inconsistent project structures, dependency versions, and coding standards across different business lines prevent the effective reuse of components, utility functions, and common capabilities across projects. Different teams frequently implement the same functional modules (such as login authentication, access control, and request encapsulation), resulting in significant duplication of development work. Furthermore, the differences in technology stacks between projects further exacerbate maintenance costs.

[0005] Third, R&D efficiency varies widely. Complex business pages have long development cycles, while simple pages suffer from over-engineering, making it difficult to improve the overall R&D efficiency of the team through scaling. The lack of a standardized access mechanism and runtime container makes starting new projects costly and migrating older projects difficult.

[0006] Therefore, there is an urgent need in the existing technology for a micro-frontend integrated solution that is closer to the characteristics of middle and back-end business, which can unify the unified entry point, address resolution, lifecycle scheduling, permission menu linkage, state sharing and low-code collaboration within the same base to solve the above-mentioned defects.

[0007] In view of this, the present invention provides a method, system, device and storage medium for integrated middle and back-end systems based on micro-frontend. Summary of the Invention

[0008] To address the problems in existing technologies, the present invention aims to provide a method, system, device, and storage medium for integrated middle and back-end systems based on micro-frontends. This overcomes the shortcomings of existing technologies, enables collaborative operation and hybrid delivery of source code pages and low-code pages, establishes a unified entry point and operating base for multiple middle and back-end sub-applications, and converges user session states, request configurations, common dependencies, sharing capabilities, and project access methods into a unified mechanism.

[0009] Embodiments of the present invention provide a method for integrating middle and back offices based on a micro-frontend, comprising the following steps: S110. Construct a unified base for the middle and back-end systems, and connect at least one sub-application to the unified base. The unified base maintains project configuration, page metadata, permission menu mapping, lifecycle hooks, namespaced shared state repository, and low-code page description information. S120. Receive a page access request, parse the access address to extract the target sub-application identifier and the target page path, form a page access context, and read the corresponding project configuration according to the target sub-application identifier. S130. Before loading page resources, execute the project-level preprocessing lifecycle to complete the loading of shared dependencies and user session state, and load page resources according to page type: if the target page is a source code page, dynamically load the page script and register page components; if the target page is a low-code page, read the page structure and generate a page instance at runtime. S140. After the page resources are prepared, execute the page registration lifecycle, register the page to the unified routing container, and execute permission menu linkage and state coordination; and S150. When switching pages or closing, execute the pre-departure lifecycle, prompt or save any unsubmitted data, and release related resources in a unified manner.

[0010] Preferably, step S110 includes: S111. Construct the unified base as a shared runtime container for multiple sub-applications. The unified base shall at least maintain project configuration, page metadata, permission menu mapping, lifecycle hooks, namespaced shared state repository, and low-code page description information. S112. When each sub-application accesses the unified base, it shall at least register the project identifier, page list, page script address, dependent resources, menu mapping relationship and page type. The base shall establish unified page access and loading rules based on the registration information, and maintain a namespaced shared state repository and its interface, as well as a global event mechanism, to realize cross-page and cross-sub-application data sharing and message passing.

[0011] Preferably, step S120 includes: S121. After receiving a page access request, the system extracts the target sub-application identifier and the target page path from the access address according to the preset routing matching rules, path resolution rules, hostname resolution rules or hash resolution rules, and forms a page access context. S122. The base obtains the corresponding project configuration based on the target sub-application identifier; if the configuration does not exist, it outputs a message indicating that the project or page does not exist; if the configuration exists, it enters the resource loading and lifecycle scheduling stage.

[0012] Preferably, step S130 includes: S131. The base performs a project-level preprocessing lifecycle before page resources are loaded, which is used to handle menu preparation, request configuration initialization, shared dependency loading, loading user session state and current project context settings. S132. If the target page is a source code page, then dynamically load it according to the dependency resource list and page script address, and register the page components; if the target page is a low-code page, then read the page structure, component tree, variable configuration and data source configuration, and generate a page instance at runtime.

[0013] Preferably, step S140 includes: S141. After the page resources are prepared, the system executes the page registration lifecycle and registers the page to the unified routing container; for pages that need to be cached and reused, it decides whether to retain the instance based on the page metadata; S142. The system matches the current route with the user's authorized menu set, extracts the corresponding menu item and permission code for the page; if the permissions are insufficient, it outputs the "no permission" page or redirects to the preset page; if the permissions are granted, it continues to render the target page. S143. During page operation, the unified base realizes cross-page and cross-sub-application data sharing, message passing and page switching control through namespaced shared state repository and global event mechanism.

[0014] Preferably, in step S150, when a user switches pages or closes a tab, the system calls the lifecycle before leaving the page to uniformly process unsubmitted data, redirection confirmation, resource release, and caching strategies; the low-code page is directly mounted into the portal as a runtime page, and is also converted into a code module for integration into the source code project after the page is stable, so as to support phased migration and hybrid delivery.

[0015] Preferably, the method further includes: during page operation, the base continuously maintains shared state, global events, menu context and project-level capabilities; when switching pages or leaving, the base performs pre-leave processing to handle unsubmitted data, jump blocking and resource release logic.

[0016] Embodiments of the present invention also provide a micro-frontend-based integrated middle and back office system for implementing the above-described micro-frontend-based integrated middle and back office method, wherein the micro-frontend-based integrated middle and back office system includes: The unified base module constructs a unified base for the middle and back-end systems and connects at least one sub-application to the unified base. The unified base maintains project configuration, page metadata, permission menu mapping, lifecycle hooks, a namespaced shared state repository, and low-code page description information. The access request module receives page access requests, parses the access address to extract the target sub-application identifier and the target page path, forms a page access context, and reads the corresponding project configuration based on the target sub-application identifier; The lifecycle module performs project-level preprocessing lifecycles before page resources are loaded, completing the loading of shared dependencies and user session states, and loading page resources according to page type: if the target page is a source code page, the page scripts are dynamically loaded and page components are registered; if the target page is a low-code page, the page structure is read and a page instance is generated at runtime. The state coordination module, after page resources are prepared, executes the page registration lifecycle, registers the page to the unified routing container, and performs permission menu linkage and state coordination; and The unified processing module executes the pre-exit lifecycle when switching pages or closing, prompts or saves unsubmitted data, and releases related resources in a unified manner.

[0017] Embodiments of the present invention also provide a mid-to-back-end integrated device based on a micro-frontend, comprising: processor; A memory in which executable instructions of the processor are stored; The processor is configured to execute the steps of the above-described micro-frontend-based integrated middle and back-end method by executing the executable instructions.

[0018] Embodiments of the present invention also provide a computer-readable storage medium for storing a program, which, when executed, implements the steps of the above-described integrated middle and back-end method based on a micro-frontend.

[0019] The purpose of this invention is to provide a method, system, device, and storage medium for integrated middle and back-end systems based on micro-frontends. This allows source code pages and low-code pages to run collaboratively under the same portal and supports mutual embedding, hybrid delivery, and gradual migration. It establishes a unified entry point and unified operating base for multiple middle and back-end sub-applications. Even after the sub-applications are split, user session states, request configurations, common dependencies, shared capabilities, and project access methods are still converged into a unified mechanism, which significantly improves R&D efficiency and reduces redundant construction costs. Attached Figure Description

[0020] Other features, objects, and advantages of the invention will become more apparent from the following detailed description of non-limiting embodiments with reference to the accompanying drawings.

[0021] Figure 1 This is a flowchart of the integrated middle and back-end method based on micro-frontend of the present invention.

[0022] Figure 2 This is a schematic diagram of the process steps for implementing the micro-frontend-based integrated middle and back-end method of the present invention.

[0023] Figure 3 This is a system architecture diagram of the integrated middle and back-end system based on micro-frontend of the present invention.

[0024] Figure 4 This is a schematic diagram of the integrated middle and back-end device based on the micro-frontend of the present invention.

[0025] Figure 5 This is a schematic diagram of the structure of a computer-readable storage medium according to an embodiment of the present invention. Detailed Implementation

[0026] The following specific examples illustrate the implementation methods of this application. Those skilled in the art can easily understand the other advantages and effects of this application from the content disclosed herein. This application can also be implemented or applied through other different specific embodiments, and various details in this application can be modified or changed according to different viewpoints and application systems without departing from the spirit of this application. It should be noted that, unless otherwise specified, the embodiments and features in the embodiments of this application can be combined with each other.

[0027] The embodiments of this application will now be described in detail with reference to the accompanying drawings, so that those skilled in the art can easily implement the application. This application may be embodied in many different forms and is not limited to the embodiments described herein.

[0028] In this application, the terms "one embodiment," "some embodiments," "example," "specific example," or "some examples," etc., refer to specific features, structures, materials, or characteristics represented in connection with that embodiment or example, which are included in at least one embodiment or example of this application. Furthermore, the specific features, structures, materials, or characteristics represented may be combined in any suitable manner in one or more embodiments or examples. Moreover, without contradiction, those skilled in the art can combine and integrate different embodiments or examples represented in this application, as well as features of different embodiments or examples.

[0029] Furthermore, the terms "first" and "second" are used for illustrative purposes only and should not be construed as indicating or implying relative importance or implicitly specifying the number of technical features indicated. Thus, a feature defined as "first" or "second" may explicitly or implicitly include at least one of that feature. In the representation of this application, "multiple" means two or more, unless otherwise explicitly specified.

[0030] For the purpose of clearly describing this application, devices that are not relevant to the description are omitted, and the same or similar components throughout the specification are given the same reference numerals.

[0031] Throughout this specification, when it is said that a device is "connected" to another device, this includes not only "direct connection" but also "indirect connection" by placing other components in between. Furthermore, when it is said that a device "comprises" a certain constituent element, unless otherwise stated otherwise, this does not exclude other constituent elements, but rather implies that other constituent elements may be included.

[0032] When we say that a device is "above" another device, this can mean that it is directly above the other device, or it can mean that other devices are present in between. Conversely, when we say that a device is "directly" "above" another device, there are no other devices present in between.

[0033] Although the terms first, second, etc., are used in some instances herein to refer to various elements, these elements should not be limited by these terms. These terms are used only to distinguish one element from another. For example, first interface and second interface, etc., are used. Furthermore, as used herein, the singular forms “a,” “an,” and “the” are intended to also include the plural forms unless the context indicates otherwise. It should be further understood that the terms “comprising,” “including,” indicate the presence of features, steps, operations, elements, components, items, kinds, and / or groups, but do not exclude the presence, occurrence, or addition of one or more other features, steps, operations, elements, components, items, kinds, and / or groups. The terms “or” and “and / or” as used herein are interpreted as inclusive, or mean any one or any combination thereof. Thus, “A, B, or C” or “A, B, and / or C” means “any one of: A; B; C; A and B; A and C; B and C; A, B, and C.” Exceptions to this definition will only occur if the combination of elements, functions, steps, or operations is inherently mutually exclusive in some way.

[0034] The technical terms used herein are for reference only to specific embodiments and are not intended to limit the scope of this application. The singular form used herein includes the plural form unless the statement explicitly indicates otherwise. The word "comprising" as used in the specification means to specify a particular characteristic, region, integer, step, operation, element, and / or component, and does not exclude the presence or addition of other characteristics, regions, integers, steps, operations, elements, and / or components.

[0035] Although not explicitly defined, all terms, including technical and scientific terms used herein, shall have the same meaning as commonly understood by one of ordinary skill in the art to which this application pertains. Terms defined in commonly used dictionaries shall be further interpreted as having a meaning consistent with the relevant technical literature and the content of this present application, and shall not be over-interpreted as having an ideal or overly formulaic meaning unless otherwise defined.

[0036] Figure 1 This is a flowchart of the integrated middle and back-end method based on a micro-frontend, as described in this invention. Figure 1 As shown, the integrated middle and back-end method based on micro-frontend of the present invention includes the following steps: S110. Construct a unified backend infrastructure and connect at least one sub-application to it. The unified infrastructure maintains project configuration, page metadata, permission menu mapping, lifecycle hooks, a namespaced shared state repository, and low-code page description information. Internally, the infrastructure maintains a unified routing container (essentially a global route matching table and view rendering exit point), and all sub-application pages will be registered in this container.

[0037] S120: Receive a page access request, parse the access address to extract the target sub-application identifier and the target page path, form a page access context, and read the corresponding project configuration based on the target sub-application identifier.

[0038] S130. Before loading page resources, execute the project-level preprocessing lifecycle to complete the loading of shared dependencies and user session state, and load page resources according to page type: if the target page is a source code page, dynamically load page scripts and register page components. If the target page is a low-code page, read the page structure and generate a page instance at runtime.

[0039] S140. After page resources are prepared, execute the page registration lifecycle to register the page to the unified routing container, and perform permission menu linkage and state coordination.

[0040] S150. When switching or closing a page, execute the pre-departure lifecycle, prompt or save any unsubmitted data, and release related resources uniformly. This preferred embodiment illustrates the basic method flow of the present invention. Its technical effect is that by integrating unified base construction, address resolution, differentiated page loading, lifecycle management, permission status linkage, and pre-departure processing into a closed-loop process, it provides for the first time an integrated architecture that can accommodate both source code development and low-code drag-and-drop modes for mid-to-back-end scenarios. Specifically, steps S110 and S120 solve the problem of unified entry and configuration management for multiple applications, eliminating the fragmentation of users switching repeatedly between different systems. Step S130, through preprocessing the lifecycle and the type-based loading mechanism, enables complex business pages (source code) and simple display pages (low-code) to be treated equally and executed in the same runtime, breaking through the limitations of the single development mode of traditional solutions. Step S140 binds route registration with permission status, ensuring that the page runs in the correct authorized environment. Step S150, through the unified termination of the pre-departure lifecycle, ensures data security and effective resource release during multi-page switching. The above steps work together to form a complete closed loop from request access to page unloading, which significantly improves the R&D efficiency, maintainability and user experience of the middle and back-end systems.

[0041] In a preferred embodiment, step S110 includes: S111. Build a unified base as a shared runtime container for multiple sub-applications. The unified base should at least maintain project configuration, page metadata, permission menu mapping, lifecycle hooks, namespaced shared state repository, and low-code page description information.

[0042] S112. When each sub-application connects to the unified base, it must register at least the project identifier, page list, page script address, dependent resources, menu mapping relationship, and page type. The base establishes unified page access and loading rules based on the registration information (i.e., the aforementioned project identifier, page list, page script address, dependent resources, menu mapping relationship, and page type). The base also maintains a namespaced shared state repository and a global event mechanism to achieve cross-page and cross-sub-application data sharing and message passing. This preferred embodiment further defines the construction details of the unified base (S111) and the access contract of sub-applications (S112) on top of the basic solution. Its technical effects are as follows: First, by constructing a shared runtime container that maintains core information such as project configuration, page metadata, and permission mapping through S111, a standardized runtime environment is provided for all sub-applications, solving the problems of inconsistent engineering structures and chaotic specifications in the existing technology. Second, through the registration contract (project identifier, page list, script address, page type, etc.) specified in S112, sub-applications developed by different teams and with different technology stacks can connect to the base in a declarative manner, achieving true technology stack independence. More importantly, the namespaced shared state repository and global event mechanism maintained in S112 provide an orderly and controllable solution for data sharing and communication across sub-applications. Compared to having each sub-application implement communication independently (such as through global variables or browser storage), this solution's namespace mechanism effectively avoids state pollution and event conflicts, making state management clear and traceable when multiple teams collaborate to develop large-scale back-end systems. This significantly reduces debugging costs and online failure risks caused by state chaos.

[0043] In a preferred embodiment, step S120 includes: S121. After receiving a page access request, the system extracts the target sub-application identifier and the target page path from the access address according to the preset routing matching rules, path resolution rules, hostname resolution rules or hash resolution rules, and forms a page access context.

[0044] S122. The base obtains the corresponding project configuration based on the target sub-application identifier. If the configuration does not exist, a message indicating that the project or page does not exist is output. If the configuration exists, the resource loading and lifecycle scheduling phase begins. This preferred embodiment, based on the basic scheme, further defines various specific rules for address resolution (S121) and a handling mechanism for missing configurations (S122). Its technical advantages are: First, the various resolution rules listed in S121, such as route matching, path resolution, hostname resolution, and hash resolution, make the routing scheme of this invention highly adaptable to different scenarios. For example, hostname resolution (e.g., crm.company.com) can be used for sub-applications that need to be deployed independently, path prefix resolution (e.g., / crm) can be used for sub-applications that need to be quickly integrated, and hash resolution can be used for older systems using traditional hash routing. This flexibility allows this invention to seamlessly connect with front-end projects from different historical periods and with different deployment methods, significantly reducing the technical threshold for system integration. Second, the mechanism in S122 that outputs a unified error message when the configuration does not exist avoids users facing blank pages or incomprehensible script errors, providing user-friendly feedback. At the same time, this mechanism also makes it easier for operations and maintenance personnel to quickly locate whether the problem is a routing configuration error or a sub-application not being registered, thus improving the system's observability and troubleshooting efficiency.

[0045] This invention defines three types of core lifecycle hooks: project-level preprocessing lifecycle (hereinafter referred to as beforeLaunch), page registration lifecycle (hereinafter referred to as onLaunch), and pre-leave lifecycle (hereinafter referred to as beforeLeave). In a preferred embodiment, step S130 includes: S131. The base executes the project-level beforeLaunch lifecycle before page resources are loaded, which is used to handle menu preparation, request configuration initialization, shared dependency loading, loading user session state and current project context settings.

[0046] S132. If the target page is a source code page, dynamic loading is completed according to the dependency resource list and page script address, and page components are registered. If the target page is a low-code page, the page structure, component tree, variable configuration, and data source configuration are read, and a page instance is generated at runtime. This preferred embodiment, based on the basic solution, further defines the specific responsibilities of the preprocessing lifecycle (beforeLaunch) (S131) ​​and the detailed process of page resource loading (S132). Its technical effect is that S131 moves the most common common capabilities in back-end scenarios, such as menu preparation, request configuration initialization, shared dependency loading, and loading user session state, to the preprocessing lifecycle for unified execution. The direct technical effect of this design is that each sub-application no longer needs to repeatedly write boilerplate code such as login verification, request interceptor configuration, and user information acquisition during development; it only needs to focus on its own business logic, thereby reducing the startup cost of sub-applications by more than 60%. At the same time, the use of dynamic script loading for source code pages in S132 realizes on-demand loading and avoids the problem of excessive initial screen loading. For low-code pages, by reading the structured page description (component tree, variable configuration, data source configuration) and dynamically generating instances at runtime, complete decoupling of page logic and rendering is achieved. The technical advantage of this dual-track loading mechanism is that operations and maintenance personnel can directly modify the low-code page description JSON file in the configuration center to update the page, without going through the complete CI / CD process of code submission, building, and deployment, thus shortening the iteration cycle of simple pages from days to minutes.

[0047] In a preferred embodiment, step S140 includes: S141. After the page resources are prepared, the system executes the onLaunch lifecycle and registers the page with the unified routing container. For pages that need to be cached and reused, the system determines whether to retain the instance based on the page metadata.

[0048] S142. The system matches the current route with the user's authorized menu set, extracting the corresponding menu item and permission code for the page. If permissions are insufficient, it outputs an "Insufficient Permissions" page or redirects to a preset page. If permissions are granted, it continues rendering the target page.

[0049] S143. During page execution, the unified base achieves cross-page and cross-sub-application data sharing, message passing, and page switching control through a namespaced shared state repository and a global event mechanism. This preferred embodiment, based on the basic solution, further defines the page registration lifecycle (onLaunch), page cache reuse (S141), permission menu linkage (S142), and state collaboration mechanism (S143). Its technical effects are as follows: The cache reuse mechanism in S141, which determines whether to retain instances based on page metadata, allows frequently accessed pages (such as the workbench homepage and data dashboard) to open instantly upon user re-entry, reducing loading time by more than 80% and greatly improving user experience. The permission menu linkage mechanism in S142 dynamically matches front-end routes with the back-end permission model. Compared to the traditional solution of verifying permissions via an interface after page loading, this solution can proactively block unauthorized access at the routing level, reducing invalid network requests and resource loading, while also improving system security. S143 achieves cross-page and cross-sub-application data sharing through a namespaced shared state repository and a global event mechanism. Its technical advantage lies in solving the "state silo" problem common in micro-frontend architectures. For example, when a user modifies a product price in the "Product Management" sub-application, the shopping cart page displayed in the "Order Management" sub-application can be updated in real-time through the global event mechanism, without requiring manual refresh by the user, achieving a seamless experience close to native single-page applications.

[0050] In a preferred embodiment, in step S150, when the user switches pages or closes a tab, the system invokes the pre-departure lifecycle to uniformly handle unsubmitted data, redirect confirmation, resource release, and caching strategies. The low-code page is either directly mounted as a runtime page into the portal or, after page stabilization, converted into a code module for integration into the source code project, supporting phased migration and hybrid delivery. This preferred embodiment, based on the basic solution, further defines the handling of unsubmitted data in the pre-departure lifecycle (S150) and the gradual migration capability of the low-code page. Its technical effect is that the mechanism in S150, which calls the pre-departure lifecycle to uniformly check and prompt unsubmitted data, provides "anti-accidental touch" protection for user operations on complex form pages (such as approval forms and long questionnaires). Compared to the crude and uncustomizable pop-up of the browser's native beforeunload event, this solution can accurately identify the modification status of specific forms and provide customizable options such as "save draft," "discard changes," and "cancel departure," significantly improving user experience and data security in complex business scenarios. Furthermore, the limitation in this embodiment regarding low-code pages being "either directly mounted or converted into code modules for source code integration" has the technical advantage of providing a smooth "launch first, optimize later" path for enterprises to repay their technical debt. Business users can quickly launch pages using low-code methods to meet urgent business needs. Once the system is stable, developers can "upgrade" the low-code page to a source code page for in-depth customization and performance optimization. Throughout the process, the URL accessed by users remains unchanged, and the business is unaware of the changes, achieving a perfect balance between rapid delivery and long-term maintainability.

[0051] In a preferred embodiment, the method further includes: during page operation, the base continuously maintains shared state, global events, menu context, and project-level capabilities. When switching pages or leaving, the base performs pre-departure processing to handle unsubmitted data, jump blocking, and resource release logic. This preferred embodiment, based on the basic solution, further defines the continuous maintenance behavior (shared state, global events, menu context) during page operation and the jump blocking logic in pre-departure processing. Its technical effect is that the base continuously maintains shared state and global events during page operation, ensuring that the state of the entire multi-application portal remains synchronized in real time. For example, global information such as user avatars and notification counts can remain consistent across all sub-applications, eliminating the confusion caused by inconsistent states when users switch between different applications. Simultaneously, the technical effect of continuously maintaining the menu context (i.e., the user's access path stack) is that the system can automatically generate accurate breadcrumb navigation and implement intelligent "back" logic (for example, after jumping from sub-application A to sub-application B, clicking back correctly returns to the previous page of sub-application A). This cross-sub-application navigation experience is impossible to achieve in traditional multi-system switching. Furthermore, the limitation on redirection blocking in this embodiment has the following technical effect: In critical business processes (such as payment, contract signing, and data submission), the system can forcibly prevent users from redirecting based on the business status until the process is completed. This mechanism provides underlying technical support for ensuring business integrity, avoiding data inconsistencies or business interruptions caused by user errors, and is particularly valuable for industries with strong compliance requirements such as finance and healthcare.

[0052] Figure 2 This is a schematic diagram illustrating the process steps of implementing the micro-frontend-based integrated middle and back office method of this invention. The following example uses a typical enterprise middle and back office system integration project for reference. Figure 1 and 2 As shown, the implementation process of a complete embodiment of the present invention is described in detail.

[0053] Step 1: System Initialization and Base Construction

[0054] The development team first built a micro-frontend foundation project called "Enterprise Workbench". This project is based on the Qiankun or similar micro-frontend framework, but with extensive customization for mid-to-back-end scenarios. The foundation project contains the following core files: main.js (entry file, responsible for registering sub-applications and starting global services), configCenter.js (configuration center, managing configuration information for all sub-applications), lifecycleManager.js (lifecycle manager, responsible for sequentially calling various lifecycle hooks), stateStore.js (global state repository, implementing namespaces based on a proxy), and eventBus.js (global event bus). After the foundation was built, it was deployed to a server with the main domain "work.company.com".

[0055] Step 2: Sub-application integration

[0056] Suppose there are three teams responsible for developing three sub-applications: "CRM" (Customer Relationship Management), "ERP" (Enterprise Resource Planning), and "BI" (Business Intelligence). Each team only needs to export a declaration object in its own project entry file according to the contract agreed upon by the base (the relevant code will not be elaborated here). After the base starts, it will read the declarations of all registered sub-applications and activate the corresponding sub-applications according to the activeRule rules (such as the path prefix / crm).

[0057] Step 3: User Access and Page Loading

[0058] Users access relevant URLs through their browsers, such as https: / / work.company.com / crm / customer / list. The base's address resolution module detects route changes and extracts the sub-application name "crm" and the page path " / customer / list". The base checks if the sub-application is registered and, upon confirmation, enters the beforeLaunch lifecycle. In this lifecycle, the base performs three tasks: First, it reads a token from cookies or localStorage to verify the user's identity and obtain user information from the backend; second, it initializes an axios instance with authentication headers and mounts it to the sub-application's context; third, it loads the common UI component library that the sub-application depends on. Next, the page loading module detects that the target page type is "source" and dynamically creates a script tag to load the "customerList.js" script. After the script is loaded, its rendering function is executed, rendering the customer list page into the specified container. Finally, the onLaunch lifecycle is triggered, and the page is officially registered. The permissions menu linkage module checks whether the current user has access permissions to " / crm / customer / list". If not, it displays a "no permissions" page.

[0059] Step 4: Hybrid Page Delivery and Migration

[0060] In another scenario, the CRM team needed to quickly build a "sales data dashboard," but front-end development resources were limited. They could leverage the company's internal low-code platform, quickly generating a page by dragging and dropping components and configuring data sources. This page was then published to the configuration center, obtaining a schemaId "crm-dashboard-schema". Next, a page record was added to the sub-application registration information, with the type "lowcode", and associated with this schemaId. When a user accesses " / crm / dashboard", the underlying low-code collaboration module retrieves the schema from the configuration center and dynamically generates a page instance using the low-code rendering engine. This low-code page seamlessly switches to the previously developed customer list page within the same portal, with users completely unaware of the technical differences between the two pages. Later, if more complex customization of the dashboard is desired, the low-code page can be "converted to code." The low-code platform generates corresponding Vue / React source code files, which developers can then use for further development before redeploying as a source code page. This completes a smooth, gradual migration.

[0061] Step 5: Leaving the page and recycling resources

[0062] When a user clicks the browser's back button or switches to another sub-application (such as ERP), the base will trigger a beforeLeave lifecycle for the currently active CRM sub-application. During this lifecycle, if an ongoing editing operation is detected on the customer list page (for example, an embedded customer information editing pop-up has not yet been saved), a pop-up will ask the user to confirm leaving. Upon confirmation, the system will perform resource reclamation: cancel all pending network requests, unbind all event listeners on the page, and finally destroy (if the page is marked as non-cached) or deactivate (if the page is marked as cacheable) the page instance. If the page is marked as cacheable, its instance will be retained in memory for quick recovery next time.

[0063] Through the complete implementation of the above five steps, this invention successfully integrates multiple independently developed mid- and back-end subsystems with potentially different technology stacks into a unified, controllable, and efficient integrated workbench, perfectly solving various defects existing in the prior art.

[0064] Compared with existing technologies that employ fragmented solutions such as pure scaffolding, pure low-code, or independent maintenance by each business line, this invention integrates a unified base, address resolution, lifecycle scheduling, permission menu linkage, state coordination, and low-code coordination into a complete architecture, achieving the following significant technical effects: I. Synergistic Gains at the Architectural Level. This invention is the first to connect six core capabilities into a closed-loop chain: By combining a unified base with address resolution, it integrates distributed systems into a single portal, achieving "one login, full access"; through lifecycle scheduling and low-code collaboration, it simultaneously accepts source code and low-code pages within the same runtime, supporting a smooth and gradual migration of "mounting old systems and developing new features from source code"; through a standardized page processing pipeline, it converges non-functional requirements such as login status checks, route authentication, page caching, and departure confirmation to a unified base for management, fundamentally solving the defects of inconsistent engineering structures and large amounts of redundant development.

[0065] II. Deep Integration at the Business Level. Existing micro-frontend solutions only focus on sub-application loading. This invention deeply integrates common backend capabilities into the runtime: through atomic-level linkage between permissions and routing, permissions are verified in real time at the routing scheduling layer, solving the problem of "pages can be opened but no one has the right to operate"; through a namespaced shared state repository and a global event mechanism, cross-application data sharing and message passing are achieved, breaking down "state silos"; common capabilities such as loading user session state and request configuration initialization are moved forward to the preprocessing lifecycle, allowing sub-applications to obtain these capabilities with zero code, reducing integration costs by more than 70%.

[0066] III. Irreplaceable Value in Practical Implementation. The unified foundation provides standardized access specifications and an isolated environment, supporting parallel development by multiple teams with different technology stacks, achieving "independent development and integrated operation"; it supports mixed operation of low-code and source code, providing a low-risk, step-by-step "engine-switching while flying" path for the transformation of legacy systems; and it consolidates the configuration, dependencies, and permissions of all sub-applications into a unified configuration center, achieving unified operation and maintenance and observability, significantly reducing operation and maintenance costs.

[0067] In summary, this invention enables hybrid operation of source code and low-code, unified governance of multiple sub-applications, and smooth migration of legacy systems, significantly improving R&D efficiency and maintainability in the middle and back-end domains.

[0068] Figure 3 This is a system architecture diagram of the browser connector service in the micro-frontend-based integrated middle and back-end system of this invention. (See diagram below.) Figure 3 As shown, the integrated middle and back-end system 5 based on micro-frontend of the present invention includes: The unified base module 51 builds a unified base for the middle and back-end systems and connects at least one sub-application to the unified base. The unified base maintains project configuration, page metadata, permission menu mapping, lifecycle hooks, a namespaced shared state repository, and low-code page description information.

[0069] The access request module 52 receives page access requests, parses the access address to extract the target sub-application identifier and the target page path, forms a page access context, and reads the corresponding project configuration based on the target sub-application identifier.

[0070] The lifecycle module 53 executes project-level preprocessing lifecycles before page resources are loaded, completing the loading of shared dependencies and user session state, and loading page resources according to the page type: if the target page is a source code page, it dynamically loads page scripts and registers page components. If the target page is a low-code page, it reads the page structure and generates a page instance at runtime.

[0071] The state coordination module 54, after page resources are prepared, executes the page registration lifecycle, registers the page to the unified routing container, and performs permission menu linkage and state coordination.

[0072] The unified processing module 55 executes the pre-exit lifecycle when the page is switched or closed, prompts or saves unsubmitted data, and releases related resources in a unified manner.

[0073] In summary, the micro-frontend-based integrated middle and back-end system of this invention enables source code pages and low-code pages to run collaboratively under the same portal and supports mutual embedding, hybrid delivery, and gradual migration. It establishes a unified entry point and unified operating base for multiple middle and back-end sub-applications, and after the sub-applications are split, it still converges user session states, request configurations, common dependencies, shared capabilities, and project access methods into a unified mechanism, which significantly improves R&D efficiency and reduces redundant construction costs.

[0074] This invention also provides a micro-frontend-based integrated middle and back office device, including a processor and a memory storing executable instructions for the processor. The processor is configured to execute steps of a micro-frontend-based integrated middle and back office method by executing the executable instructions.

[0075] As shown above, the micro-frontend-based integrated middle and back-end device of this invention enables source code pages and low-code pages to run collaboratively under the same portal and supports mutual embedding, hybrid delivery and progressive migration. It establishes a unified entry point and unified operating base for multiple middle and back-end sub-applications. Even after the sub-applications are split, user session states, request configurations, common dependencies, shared capabilities and project access methods are still converged into a unified mechanism, which significantly improves R&D efficiency and reduces the cost of redundant construction.

[0076] Those skilled in the art will understand that various aspects of the present invention can be implemented as systems, methods, or program products. Therefore, various aspects of the present invention can be specifically implemented in the following forms: a completely hardware implementation, a completely software implementation (including firmware, microcode, etc.), or a combination of hardware and software aspects, collectively referred to herein as a "circuit," "module," or "platform."

[0077] Figure 4 This is a schematic diagram of the integrated middle and back-end device based on a micro-frontend according to the present invention. See below for reference. Figure 4 To describe an electronic device 600 according to this embodiment of the present invention. Figure 4 The electronic device 600 shown is merely an example and should not impose any limitations on the functionality and scope of use of the embodiments of the present invention.

[0078] like Figure 4 As shown, the electronic device 600 is presented in the form of a general-purpose computing device. The components of the electronic device 600 may include, but are not limited to: at least one processing unit 610, at least one storage unit 620, a bus 630 connecting different platform components (including storage unit 620 and processing unit 610), a display unit 640, etc.

[0079] The storage unit stores program code, which can be executed by the processing unit 610 to perform the steps described in the method section of this specification according to various exemplary embodiments of the present invention. For example, the processing unit 610 can perform actions such as... Figure 1 The steps are shown in the figure.

[0080] Storage unit 620 may include readable media in the form of volatile storage units, such as random access memory (RAM) 6201 and / or cache memory 6202, and may further include read-only memory (ROM) 6203.

[0081] Storage unit 620 may also include a program / utility 6204 having a set (at least one) program module 6205, such program module 6205 including but not limited to: operating system, one or more application programs, other program modules and program data, each or some combination of these examples may include an implementation of a network environment.

[0082] Bus 630 can represent one or more of several types of bus structures, including a memory cell bus or memory cell controller, a peripheral bus, a graphics acceleration port, a processing unit, or a local bus using any of the multiple bus structures.

[0083] Electronic device 600 can also communicate with one or more external devices 700 (e.g., keyboard, pointing device, Bluetooth device, etc.), and with one or more devices that enable a user to interact with electronic device 600, and / or with any device that enables electronic device 600 to communicate with one or more other computing devices (e.g., router, modem, etc.). This communication can be performed via input / output (I / O) interface 650. Furthermore, electronic device 600 can also communicate with one or more networks (e.g., local area network (LAN), wide area network (WAN), and / or public networks, such as the Internet) via network adapter 660. Network adapter 660 can communicate with other modules of electronic device 600 via bus 630. It should be understood that, although not shown in the figures, other hardware and / or software modules can be used in conjunction with electronic device 600, including but not limited to: microcode, device drivers, redundant processing units, external disk drive arrays, RAID systems, tape drives, and data backup storage platforms.

[0084] This invention also provides a computer-readable storage medium for storing a program, which, when executed, implements the steps of a micro-frontend-based integrated middle and back-end method. In some possible implementations, various aspects of this invention can also be implemented as a program product comprising program code that, when run on a terminal device, causes the terminal device to perform the steps described in the above-described method section of this specification according to various exemplary embodiments of the invention.

[0085] As shown above, the micro-frontend-based integrated middle and back-end system of this invention enables source code pages and low-code pages to run collaboratively under the same portal and supports mutual embedding, hybrid delivery and progressive migration. It establishes a unified entry point and unified operating base for multiple middle and back-end sub-applications. Even after the sub-applications are split, user session states, request configurations, common dependencies, shared capabilities and project access methods are still converged into a unified mechanism, which significantly improves R&D efficiency and reduces the cost of redundant construction.

[0086] Figure 5 This is a schematic diagram of the structure of the computer-readable storage medium of the present invention. (Reference) Figure 5 As shown, a program product 800 for implementing the above-described method according to an embodiment of the present invention is described. It may employ a portable compact disc read-only memory (CD-ROM) and include program code, and may run on a terminal device, such as a personal computer. However, the program product of the present invention is not limited thereto. In this document, the readable storage medium may be any tangible medium containing or storing a program that may be used by or in conjunction with an instruction execution system, apparatus, or device.

[0087] The program product may employ any combination of one or more readable media. A readable medium may be a readable signal medium or a readable storage medium. A readable storage medium may be, for example, but not limited to, an electrical, magnetic, optical, electromagnetic, infrared, or semiconductor system, apparatus, or device, or any combination thereof. More specific examples of readable storage media (a non-exhaustive list) include: electrical connections having one or more wires, portable disks, hard disks, random access memory (RAM), read-only memory (ROM), erasable programmable read-only memory (EPROM or flash memory), optical fiber, portable compact disk read-only memory (CD-ROM), optical storage devices, magnetic storage devices, or any suitable combination thereof.

[0088] Computer-readable storage media may include data signals propagated in baseband or as part of a carrier wave, carrying readable program code. Such propagated data signals may take various forms, including but not limited to electromagnetic signals, optical signals, or any suitable combination thereof. A readable storage medium may also be any readable medium other than a readable storage medium that can transmit, propagate, or transfer a program for use by or in connection with an instruction execution system, apparatus, or device. The program code contained on the readable storage medium may be transmitted using any suitable medium, including but not limited to wireless, wired, optical fiber, RF, etc., or any suitable combination thereof.

[0089] Program code for performing the operations of this invention can be written in any combination of one or more programming languages, including object-oriented programming languages ​​such as Java and C++, and conventional procedural programming languages ​​such as C or similar languages. The program code can execute entirely on the user's computing device, partially on the user's device, as a standalone software package, partially on the user's computing device and partially on a remote computing device, or entirely on a remote computing device or server. In cases involving remote computing devices, the remote computing device can be connected to the user's computing device via any type of network, including a local area network (LAN) or a wide area network (WAN), or it can be connected to an external computing device (e.g., via the Internet using an Internet service provider).

[0090] In summary, the purpose of this invention is to provide a method, system, device, and storage medium for integrated middle and back-end systems based on micro-frontends. This allows source code pages and low-code pages to run collaboratively under the same portal and supports mutual embedding, hybrid delivery, and gradual migration. It establishes a unified entry point and unified operating base for multiple middle and back-end sub-applications. Furthermore, even after the sub-applications are split, user session states, request configurations, common dependencies, shared capabilities, and project access methods are still converged into a unified mechanism, significantly improving R&D efficiency and reducing redundant construction costs.

[0091] The above description, in conjunction with specific preferred embodiments, provides a further detailed explanation of the present invention. It should not be construed that the specific implementation of the present invention is limited to these descriptions. For those skilled in the art, various simple deductions or substitutions can be made without departing from the concept of the present invention, and all such modifications and substitutions should be considered within the scope of protection of the present invention.

Claims

1. A method for integrating middle and back offices based on micro-frontends, characterized in that, Includes the following steps: S110. Construct a unified base for the middle and back-end systems, and connect at least one sub-application to the unified base. The unified base maintains project configuration, page metadata, permission menu mapping, lifecycle hooks, namespaced shared state repository, and low-code page description information. S120. Receive a page access request, parse the access address to extract the target sub-application identifier and the target page path, form a page access context, and read the corresponding project configuration according to the target sub-application identifier. S130. Before loading page resources, execute the project-level preprocessing lifecycle to complete the loading of shared dependencies and user session state, and load page resources according to page type: if the target page is a source code page, dynamically load the page script and register page components; if the target page is a low-code page, read the page structure and generate a page instance at runtime. S140. After the page resources are prepared, execute the page registration lifecycle, register the page to the unified routing container, and execute permission menu linkage and state coordination; and S150. When switching pages or closing, execute the pre-departure lifecycle, prompt or save any unsubmitted data, and release related resources in a unified manner.

2. The integrated middle and back-end method based on micro-frontend as described in claim 1, characterized in that, Step S110 includes: S111. Construct the unified base as a shared runtime container for multiple sub-applications. The unified base shall at least maintain project configuration, page metadata, permission menu mapping, lifecycle hooks, namespaced shared state repository, and low-code page description information. S112. When each sub-application accesses the unified base, it shall at least register the project identifier, page list, page script address, dependent resources, menu mapping relationship and page type. The base shall establish unified page access and loading rules based on the registration information, and maintain a namespaced shared state repository and its interface, as well as a global event mechanism, to realize cross-page and cross-sub-application data sharing and message passing.

3. The integrated middle and back-end method based on micro-frontend as described in claim 1, characterized in that, Step S120 includes: S121. After receiving a page access request, the system extracts the target sub-application identifier and the target page path from the access address according to the preset routing matching rules, path resolution rules, hostname resolution rules or hash resolution rules, and forms a page access context. S122. The base obtains the corresponding project configuration based on the target sub-application identifier; if the configuration does not exist, it outputs a message indicating that the project or page does not exist; if the configuration exists, it enters the resource loading and lifecycle scheduling stage.

4. The integrated middle and back-end method based on micro-frontend as described in claim 1, characterized in that, Step S130 includes: S131. The base performs a project-level preprocessing lifecycle before page resources are loaded, which is used to handle menu preparation, request configuration initialization, shared dependency loading, loading user session state and current project context settings. S132. If the target page is a source code page, then dynamically load it according to the dependency resource list and page script address, and register the page components; if the target page is a low-code page, then read the page structure, component tree, variable configuration and data source configuration, and generate a page instance at runtime.

5. The integrated middle and back-end method based on micro-frontend as described in claim 1, characterized in that, Step S140 includes: S141. After the page resources are prepared, the system executes the page registration lifecycle and registers the page to the unified routing container; for pages that need to be cached and reused, it decides whether to retain the instance based on the page metadata; S142. The system matches the current route with the user's authorized menu set, extracts the corresponding menu item and permission code for the page; if the permissions are insufficient, it outputs the "no permission" page or redirects to the preset page; if the permissions are granted, it continues to render the target page. S143. During page operation, the unified base realizes cross-page and cross-sub-application data sharing, message passing and page switching control through namespaced shared state repository and global event mechanism.

6. The integrated middle and back-end method based on micro-frontend as described in claim 1, characterized in that, In step S150, when a user switches pages or closes a tab, the system calls the lifecycle before leaving the page to uniformly process unsubmitted data, redirection confirmation, resource release, and caching strategies. The low-code page is directly mounted into the portal as a runtime page, and after the page stabilizes, it is converted into a code module for integration into the source code project to support phased migration and hybrid delivery.

7. The integrated middle and back-end method based on micro-frontend as described in claim 1, characterized in that, The method also includes: during page operation, the base continuously maintains shared state, global events, menu context and project-level capabilities; when switching pages or leaving, the base performs pre-leave processing to handle unsubmitted data, jump blocking and resource release logic.

8. A micro-frontend-based integrated middle and back-end system for implementing the method of any one of claims 1 to 7, characterized in that, include: The unified base module constructs a unified base for the middle and back-end systems and connects at least one sub-application to the unified base. The unified base maintains project configuration, page metadata, permission menu mapping, lifecycle hooks, a namespaced shared state repository, and low-code page description information. The access request module receives page access requests, parses the access address to extract the target sub-application identifier and the target page path, forms a page access context, and reads the corresponding project configuration based on the target sub-application identifier; The lifecycle module performs project-level preprocessing lifecycles before page resources are loaded, completing the loading of shared dependencies and user session states, and loading page resources according to page type: if the target page is a source code page, the page scripts are dynamically loaded and page components are registered; if the target page is a low-code page, the page structure is read and a page instance is generated at runtime. After the page resources are prepared, the state coordination module executes the page registration lifecycle, registers the page to the unified routing container, and performs permission menu linkage and state coordination. as well as The unified processing module executes the pre-exit lifecycle when switching pages or closing, prompts or saves unsubmitted data, and releases related resources in a unified manner.

9. A mid-to-back-end integrated device based on a micro-frontend, characterized in that, include: processor; A memory in which executable instructions of the processor are stored; The processor is configured to perform the steps of the micro-frontend-based integrated middle and back-end method according to any one of claims 1 to 7 by executing the executable instructions.

10. A computer-readable storage medium for storing a program, characterized in that, When the program is executed by the processor, it implements the steps of the integrated middle and back-end method based on micro-frontend as described in any one of claims 1 to 7.

Images