Micro-front-end request management system, method and equipment based on dynamic data source and medium
By introducing a dynamic data source management system into the micro-frontend architecture, the problem of non-unique data request components is solved, achieving unified management and enhanced security of data requests, and ensuring the stability and consistency of the system.
Patent Information
- Application Number
- CN202511263634.0
- Authority / Receiving Office
- CN · China
- Patent Type
- Applications(China)
- Current Assignee / Owner
- Filing Date
- 2025-09-05
- Publication Date
- 2025-11-11
AI Technical Summary
In a micro-frontend architecture, data request component instances are not unique and are not standardized, making the system difficult to manage and violating the integrity and security of the micro-frontend architecture.
By using a micro-frontend request management system based on dynamic data sources, the system encapsulates data request components and creates unique instances in the main micro-frontend application, thereby achieving unified management of data requests, including permission verification, data processing, and dynamic data source registration, ensuring the consistency and security of data requests.
It enables unified management of data requests, improves the consistency and management capabilities of data requests, and enhances the security and stability of the system.
Smart Images
Figure CN120935153A_ABST
Abstract
Description
Technical Field
[0001] This application relates to the field of front-end development technology, and in particular to a micro-front-end request management system, method, device and medium based on dynamic data sources. Background Technology
[0002] With the rapid development of front-end technologies and the increasing complexity of business operations, micro-frontend architecture has gradually become the preferred solution for large-scale front-end projects. Micro-frontends decouple the front-end application into multiple independent, independently runnable and developable micro-applications. Each micro-application can independently choose its technology stack and deployment method, achieving application decoupling and independent evolution. In a micro-frontend architecture, each sub-application typically has its own interface data encapsulation and data processing logic. This distributed data request approach makes the system fragmented and difficult to manage, violating the original intention of micro-frontend architecture (which should be that technical architecture optimization should not affect the overall system integrity). Furthermore, as business expands and the number of micro-applications increases, the complexity and management difficulty of data requests also rise. Therefore, how to achieve unified management of data requests in a micro-frontend architecture has become a significant technical challenge. Summary of the Invention
[0003] In view of this, the purpose of this application is to provide a micro-frontend request management system, method, device and medium based on dynamic data sources. The micro-frontend request management system based on dynamic data sources solves the problems of non-unique data request component instances and non-standard data requests in micro-frontend applications, realizes unified management of data requests, improves the consistency and management capabilities of data requests, and enhances the security and stability of the system through a unified permission verification and data processing mechanism.
[0004] This application provides a micro-frontend request management system based on a dynamic data source. The system includes a main micro-frontend application and multiple sub-applications, each of which is communicatively connected to the main micro-frontend application. The micro-frontend main application is used to encapsulate a data request component based on the client library and create a unique data request instance. After sending the data request instance and the interface for registering the data source to the micro-frontend sub-application, it receives the data source registration request sent by the micro-frontend sub-application, adds the received data source object to the data source registration center, performs permission verification on the first HTTP request of the micro-frontend sub-application based on the data request component, processes the data of the first HTTP request that has passed permission verification, determines the response result of the first HTTP request, and sends the response result to the micro-frontend sub-application. The micro-frontend sub-application is used to encapsulate data source information based on the received interface of the registered data source, determine the data source object, and send the data source object to the micro-frontend main application for registration. Based on the data source object and the data request instance, a first HTTP request is constructed and sent to the micro-frontend main application.
[0005] In one possible implementation, the micro-frontend main application is further used for: Detect whether the caching option for the data source information is configured during the registration process; If so, the response result of the first HTTP request and the data source information are cached; When it is detected that the second HTTP request sent by the second micro-frontend application is consistent with the first HTTP request, the data source information and the response result of the first HTTP request are sent to the second micro-frontend application for data sharing.
[0006] In one possible implementation, when the micro-frontend main application is used to encapsulate a data request component based on a client library, the micro-frontend main application is specifically used for: The data request component is configured with basic functional encapsulation settings, data source functional encapsulation settings, and extended functional encapsulation settings. The basic function encapsulation settings include request header settings, request timeout settings, request cancellation function settings, and request interceptor function settings; the data source function encapsulation settings include API interfaces and configuration options; and the extended function encapsulation settings include response data processing settings, error handling settings, and log monitoring settings.
[0007] In one possible implementation, when the main micro-frontend application performs permission verification on the first HTTP request of the micro-frontend sub-application based on the data request component, the main micro-frontend application is specifically used for: Before the first HTTP request is sent to the main micro-frontend application, the pre-interceptor based on the data request instance performs permission verification on the identity information of the micro-frontend sub-application and the data source object to determine whether the micro-frontend sub-application has the permission to send the first HTTP request. If not, the pre-interceptor of the data request instance interrupts the sending of the first HTTP request of the micro-frontend application and sends an error message to the micro-frontend application; If so, then the sending of the first HTTP request of the micro frontend application is permitted.
[0008] In one possible implementation, the micro-frontend main application determines the response result of the first HTTP request in the following way: The post-interceptor based on the data request instance performs JSON parsing, status code judgment, and data format encapsulation on the response data corresponding to the first HTTP request that has passed the permission verification, and determines the response result of the first HTTP request.
[0009] In one possible implementation, when the micro-frontend main application adds the received data source object to the data source registry, the micro-frontend main application is specifically used for: After receiving the data source object, the interface for registering the data source checks and validates the data fields of the data source object, and stores the validated data source object in the data source registration center of the micro-frontend main application; wherein, the data source object includes the interface address, request method and request parameters.
[0010] In one possible implementation, before constructing the first HTTP request based on the data source object and the data request instance, the micro-frontend sub-application is further configured to: The micro-frontend main application sends a query request for the data source object in the data source registry. If the micro-frontend main application reports that the data source object exists in the data source registry, then a first HTTP request is constructed based on the data source object and the data request instance.
[0011] This application also provides a micro-frontend request management method based on dynamic data sources, the method comprising: Encapsulate a data request component based on a client library and create a unique data request instance; Based on the received interface of the registered data source, the data source information is encapsulated, the data source object is determined, and the data source object is added to the data source registration center; A first HTTP request is constructed based on the data source object and the data request instance. The first HTTP request of the micro-frontend sub-application is verified for permissions based on the data request component. Data processing is performed on the first HTTP request that has passed the permission verification to determine the response result of the first HTTP request.
[0012] This application also provides an electronic device, including: a processor, a memory, and a bus. The memory stores machine-readable instructions executable by the processor. When the electronic device is running, the processor communicates with the memory via the bus. When the machine-readable instructions are executed by the processor, the steps of the micro-frontend request management method based on dynamic data sources described above are performed.
[0013] This application also provides a computer-readable storage medium storing a computer program, which, when executed by a processor, performs the steps of the micro-frontend request management method based on a dynamic data source as described above.
[0014] This application provides a micro-frontend request management system, method, device, and medium based on dynamic data sources. The micro-frontend request management system includes a main micro-frontend application and multiple micro-frontend sub-applications. Each micro-frontend sub-application is communicatively connected to the main micro-frontend application. The main micro-frontend application is used to encapsulate a data request component based on a client library and create a unique data request instance. After sending the data request instance and the interface for registering a data source to the micro-frontend sub-applications, it receives a data source registration request sent by the main micro-frontend application, adds the received data source object to the data source registration center, performs permission verification on a first HTTP request from the micro-frontend sub-application based on the data request component, processes the data of the first HTTP request that has passed permission verification, determines the response result of the first HTTP request, and sends the response result to the micro-frontend sub-applications. The micro-frontend sub-applications are used to encapsulate data source information based on the received interface for registering the data source, determine the data source object, send the data source object to the main micro-frontend application for registration, construct a first HTTP request based on the data source object and the data request instance, and send the first HTTP request to the main micro-frontend application. The beneficial effects of this application are as follows: by using a micro-frontend request management system based on dynamic data sources, the problems of non-unique data request component instances and non-standard data requests in micro-frontend applications are solved, unified management of data requests is achieved, the consistency and management capabilities of data requests are improved, and the security and stability of the system are enhanced through a unified permission verification and data processing mechanism.
[0015] To make the above-mentioned objectives, features and advantages of this application more apparent and understandable, preferred embodiments are described below in detail with reference to the accompanying drawings. Attached Figure Description
[0016] To more clearly illustrate the technical solutions of the embodiments of this application, the accompanying drawings used in the embodiments will be briefly introduced below. It should be understood that the following drawings only show some embodiments of this application and should not be regarded as a limitation of the scope. For those skilled in the art, other related drawings can be obtained based on these drawings without creative effort.
[0017] Figure 1 A schematic diagram of the structure of a micro-frontend request management system based on a dynamic data source provided in an embodiment of this application; Figure 2 An interactive diagram of a micro-frontend request management system based on a dynamic data source, provided as an embodiment of this application; Figure 3 A flowchart illustrating a micro-frontend request management method based on a dynamic data source, provided as an embodiment of this application; Figure 4 This is a schematic diagram of the structure of an electronic device provided in an embodiment of this application.
[0018] Icons: 100 - Micro-frontend request management system based on dynamic data source; 110 - Micro-frontend main application; 120 - Micro-frontend sub-application; 400 - Electronic device; 410 - Processor; 420 - Memory; 430 - Bus. Detailed Implementation
[0019] To make the objectives, technical solutions, and advantages of the embodiments of this application clearer, the technical solutions of the embodiments of this application will be clearly and completely described below with reference to the accompanying drawings. Obviously, the described embodiments are only some embodiments of this application, and not all embodiments. The components of the embodiments of this application described and shown in the accompanying drawings can generally be arranged and designed in various different configurations. Therefore, the following detailed description of the embodiments of this application provided in the accompanying drawings is not intended to limit the scope of the claimed application, but merely represents selected embodiments of this application. Based on the embodiments of this application, every other embodiment obtained by those skilled in the art without inventive effort falls within the scope of protection of this application.
[0020] First, the applicable scenarios for this application will be introduced. This application can be applied to the field of front-end development technology.
[0021] Research has revealed that with the rapid development of front-end technologies and the increasing complexity of business operations, micro-frontend architecture has gradually become the preferred solution for large-scale front-end projects. Micro-frontends decouple the front-end application into multiple independent, independently runnable and developable micro-applications. Each micro-application can independently choose its technology stack and deployment method, achieving application decoupling and independent evolution. In a micro-frontend architecture, each sub-application typically has its own interface data encapsulation and data processing logic. This distributed data request approach makes the system fragmented and difficult to manage, contradicting the original intention of micro-frontend architecture (which should be that technical architecture optimization should not affect the overall system integrity). Furthermore, as business expands and the number of micro-applications increases, the complexity and management difficulty of data requests also rise. Therefore, how to achieve unified management of data requests in a micro-frontend architecture has become a significant technical challenge.
[0022] Based on this, this application provides a micro-frontend request management system based on dynamic data sources. This system solves the problems of non-unique data request component instances and non-standard data requests in micro-frontend applications, achieves unified management of data requests, improves the consistency and management capabilities of data requests, and enhances the security and stability of the system through a unified permission verification and data processing mechanism.
[0023] Please see Figure 1 , Figure 1 This is a schematic diagram of the structure of a micro-frontend request management system 100 based on a dynamic data source, provided in an embodiment of this application. Figure 1 As shown in the figure, the micro-frontend request management system 100 based on dynamic data source provided in this application embodiment includes a micro-frontend main application 110 and multiple micro-frontend sub-applications 120, wherein each of the micro-frontend sub-applications 120 is communicatively connected to the micro-frontend main application 110.
[0024] Specifically, the micro-frontend main application 110 is used to encapsulate a data request component based on the client library and create a unique data request instance. After sending the data request instance and the interface for registering the data source to the micro-frontend sub-application 120, it receives the data source registration request sent by the micro-frontend sub-application 120, adds the received data source object to the data source registration center, performs permission verification on the first HTTP request of the micro-frontend sub-application 120 based on the data request component, processes the data of the first HTTP request that has passed permission verification, determines the response result of the first HTTP request, and sends the response result to the micro-frontend sub-application 120. The micro-frontend sub-application 120 is used to encapsulate data source information based on the received interface for registering the data source, determine the data source object, send the data source object to the micro-frontend main application 110 for registration, construct a first HTTP request based on the data source object and the data request instance, and send the first HTTP request to the micro-frontend main application 110.
[0025] Here, based on the client, a data request component is encapsulated in the micro-frontend main application 110, and a unique data request instance is created. After sending the data request instance and the interface for registering the data source to the micro-frontend sub-application 120, and receiving the data source registration request sent by the micro-frontend sub-application 120, the micro-frontend sub-application 120 encapsulates the data source information according to the received data source registration interface, determines the data source object, and sends the data source object to the micro-frontend main application 110 for registration. The received data source object is added to the data source registration center. The micro-frontend sub-application 120 constructs a first HTTP request based on the data source object and the data request instance, and sends the first HTTP request to the micro-frontend main application 110. The micro-frontend main application 110 performs permission verification on the first HTTP request from the micro-frontend sub-application 120 according to the data request component, processes the data of the first HTTP request that has passed permission verification, determines the response result of the first HTTP request, and sends the response result to the micro-frontend sub-application 120.
[0026] In this solution, a data request component can be encapsulated using axios or other HTTP client libraries, and a globally unique data request instance can be created to handle all data request operations in the system.
[0027] To support dynamic registration and querying of data sources, the micro-frontend main application 110 needs to maintain a data source registry. This registry can be a global object or a database used to store and manage all registered data sources. When a data source is registered, the micro-frontend sub-application 120 sends a data source registration request ($datasource.register) to the micro-frontend main application 110 via the communication mechanism provided by the micro-frontend framework upon startup. Upon receiving the request, the micro-frontend main application 110 adds the data source object to the registry and returns a successful registration identifier to the micro-frontend sub-application 120. When the micro-frontend sub-application 120 needs to send a data request, it retrieves the corresponding data source object by querying the registry ($datasource.getDatasource). The micro-frontend main application 110 provides an interface for querying data sources; the micro-frontend sub-application 120 can pass in specific identifiers or conditions to obtain the required data source object. When the micro-frontend sub-application 120 needs to send a data request, it only needs to query the corresponding data source and use a unified data request instance to make the request ($datasource.executeHttp).
[0028] This involves creating a globally unique data request instance named `$datasource`. This instance will manage data request operations across the entire system and serve as the unified entry point for requests initiated by the micro-frontend sub-application 120. Core configurations for `$datasource` are performed, including setting default interface timeouts and adding request and response interceptors. Request interceptors can be used for scenarios such as permission verification, while response interceptors are used for data validation and error handling.
[0029] In one possible implementation, when the micro-frontend main application 110 is used to encapsulate a data request component based on a client library, the micro-frontend main application 110 is specifically used for: The data request component is configured with basic functional encapsulation settings, data source functional encapsulation settings, and extended functional encapsulation settings. The basic functional encapsulation settings include request header settings, request timeout settings, request cancellation function settings, and request interceptor function settings. The data source functional encapsulation settings include API interfaces and configuration options. The extended functional encapsulation settings include response data processing settings, error handling settings, and log monitoring settings.
[0030] Here, this data request component will have complete data request functions and configuration options, including but not limited to: (I) Basic function encapsulation settings: support for commonly used HTTP request methods such as GET / PUT / POST / DELETE; configuration support for request headers, request timeout, request parameters (data / params), authentication information (such as token); request cancellation function support (when the browser sends multiple identical requests to the backend simultaneously, only the last request is retained, reducing network resource waste and improving performance); request interceptor function support (including request interceptors and response interceptors, the former is used for scenarios such as permission control, and the latter is used for scenarios such as data verification, encapsulation, and error handling). (II) Data source function encapsulation settings: In traditional data request methods, developers usually define interface request information directly in the code, such as URL, request method, etc. This method is not flexible enough and is not conducive to data reuse and sharing. This invention proposes to adopt a data source approach, abstracting interface request information into data source objects. Each data source object contains complete information required for the request, such as interface address, request parameters, request headers, etc. The micro-frontend sub-application 120 registers data sources with the micro-frontend main application 110 to achieve unified management of interface request information. Data source functions include: API interfaces: data source registration API, data source query API, HTTP request execution API, etc.; Configuration options: represented by a JSON object, with fields including data source code, data source name, data source type (json, data dictionary, interface), request interface address, request method, request parameters, and whether caching is enabled. (III) Extended Function Encapsulation Settings: Response Data Processing: Unified parsing and processing of response data, such as JSON parsing and status code judgment. A unified response data format is provided for easy processing by the caller. Error Handling, Retry Mechanism, and Exception Prompts: Capture and handle network errors, request timeouts, and status code errors; implement an automatic retry mechanism to automatically retry requests that may fail due to network fluctuations. Logs and Monitoring: Record request logs, including request time, request address, request parameters, and response results, for subsequent analysis and troubleshooting; integrate monitoring tools to monitor and alert on requests in real time, ensuring system stability and availability. Extended interfaces: to allow for the addition of new features as needed in the future.
[0031] In this application, the micro-frontend main application 110 creates a data request instance after initialization and passes it to the micro-frontend sub-application 120 through the communication mechanism provided by the micro-frontend framework. When the micro-frontend sub-application 120 needs to send a data request, it directly uses this data request instance without having to create its own. This not only avoids the duplication and waste of resources but also ensures the uniformity and standardization of data requests.
[0032] In one possible implementation, the micro-frontend main application 110 is further used for: A: Check whether the caching option for the data source information is configured during the registration process.
[0033] Here, we check whether the data source information caching option is configured during the registration process.
[0034] B: If so, then the response result of the first HTTP request and the data source information will be cached.
[0035] If so, the response result of the first HTTP request and the data source information will be cached.
[0036] C: When it is detected that the second HTTP request sent by the second micro-frontend application 120 is consistent with the first HTTP request, the data source information and the response result of the first HTTP request are sent to the second micro-frontend application 120 for data sharing.
[0037] Here, when it is detected that the second HTTP request sent by the second micro-frontend application 120 is consistent with the first HTTP request, the data source information and the response result of the first HTTP request are sent to the second micro-frontend application 120 for data sharing.
[0038] Among them, the micro-frontend sub-applications 120 can share data sources to reduce duplicate interface requests and improve the overall system performance. Since the micro-frontend sub-applications 120 are not necessarily loaded when entering the system page, the data source to be shared can also be registered in the main micro-frontend application 110, allowing other applications to query and use it. In this application, by configuring the data source caching option, data can be cached after a data request is returned. Subsequent identical interface requests will directly return the query results, achieving data sharing. This type of data sharing is typically used in scenarios involving full-scale basic data queries, such as aircraft numbers, airlines, and airports in the civil aviation field, where a single interface query can return the full set of data. Caching helps save system resources, improves the speed of data query returns, and optimizes the user experience.
[0039] To achieve the aforementioned data sharing, a corresponding data caching structure can be added when encapsulating the data source component. For example, the core of the following structure consists of the `caches` object, `sources`, and `datas` properties: `caches` is the global cache object for the data source component, containing cached data properties and their operation methods. `sources` is an object used to store cached data source objects. Each data source object is stored using its unique `code` property as the key. `datas` is also an object used to store the data associated with the data source object. Similar to `sources`, the data is also stored using the data source's `code`.
[0040] In one possible implementation, when the micro-frontend main application 110 performs permission verification on the first HTTP request of the micro-frontend sub-application 120 based on the data request component, the micro-frontend main application 110 is specifically used for: I: Before the first HTTP request is sent to the micro-frontend main application 110, the pre-interceptor based on the data request instance performs permission verification on the identity information of the micro-frontend sub-application 120 and the data source object to determine whether the micro-frontend sub-application 120 has the permission to send the first HTTP request.
[0041] Here, before the first HTTP request is sent to the micro-frontend main application 110, the identity information and data source object of the micro-frontend sub-application 120 are verified by the front-end interceptor of the data request instance to determine whether the micro-frontend sub-application 120 has the permission to send the first HTTP request.
[0042] Specifically, it can perform permission verification based on the token, username, and password in the identity information of the micro front-end sub-application 120, and can also perform permission verification based on whether the data source object exists.
[0043] If not, the pre-interceptor of the data request instance interrupts the sending of the first HTTP request of the micro-frontend application 120 and sends an error message to the micro-frontend application 120; if yes, the sending of the first HTTP request of the micro-frontend application 120 is allowed.
[0044] Here, if not, the pre-interceptor of the data request instance interrupts the sending of the first HTTP request of the micro front-end application 120 and sends an error message to the micro front-end application 120; if yes, the sending of the first HTTP request of the micro front-end application 120 is allowed.
[0045] Specifically, a pre-interceptor is set on the data request instance to perform permission verification before the data request is sent. It can determine whether the current request has the necessary permissions based on the data source and the identity information of the micro-frontend sub-application 120. If permission verification fails, the interceptor can abort the request and return the corresponding error message to the micro-frontend sub-application 120.
[0046] In one possible implementation, the micro-frontend main application 110 determines the response result of the first HTTP request in the following way: The post-interceptor based on the data request instance performs JSON parsing, status code judgment, and data format encapsulation on the response data corresponding to the first HTTP request that has passed the permission verification, and determines the response result of the first HTTP request.
[0047] Here, the response data corresponding to the first HTTP request that has passed the authorization verification is processed by the post-interceptor of the data request instance, which performs JSON parsing, status code judgment and data format encapsulation to determine the response result of the first HTTP request.
[0048] Specifically, a post-interceptor is set on the data request instance to execute after the data request returns, for error handling. It can capture exceptions and errors during the request process and handle them accordingly. For example, it can retry the request, log errors, or return a friendly error message to the micro-frontend sub-application 120. Additionally, response data processing can be performed within the post-interceptor, including unified parsing and processing of the response data, such as JSON parsing and status code determination.
[0049] In this application, to achieve global access control and error handling, the present invention utilizes the interceptor feature of data request instances. Pre-interceptors and post-interceptors are set on the data request instances for access control and data processing, respectively, ensuring the security and stability of data requests. Simultaneously, a unified error handling mechanism improves the robustness and maintainability of the system.
[0050] In one possible implementation, when the micro-frontend main application 110 adds the received data source object to the data source registry, the micro-frontend main application 110 is specifically used for: After receiving the data source object, the interface for registering the data source checks and validates the data fields of the data source object, and stores the validated data source object in the data source registration center of the micro-frontend main application 110; wherein, the data source object includes the interface address, request method and request parameters.
[0051] Here, after receiving the data source object, the interface for registering the data source checks and validates the data fields of the data source object, and stores the validated data source object in the data source registration center of the micro-frontend main application 110 for subsequent querying and use.
[0052] In one possible implementation, before constructing the first HTTP request based on the data source object and the data request instance, the micro-frontend application 120 further configures itself to: The micro-frontend main application 110 sends a query request for the data source object in the data source registry. If the micro-frontend main application 110 reports that the data source object exists in the data source registry, a first HTTP request is constructed based on the data source object and the data request instance.
[0053] Here, a query request for the data source object in the data source registry is sent to the micro-frontend main application 110. If the micro-frontend main application 110 reports that the data source object exists in the data source registry, then the first HTTP request is constructed based on the data source object and the data request instance.
[0054] For further details, please refer to Figure 2 , Figure 2 This is an interactive diagram illustrating a micro-frontend request management system based on a dynamic data source, provided as an embodiment of this application. For example... Figure 2 As shown, (1): Load the data request instance provided by the micro-frontend main application, (2): The first micro-frontend sub-application calls the registration interface to register the data source, (3): Query the data source object, and after successful query, use the data request instance and the data source object to construct an HTTP request, (4): Perform global request interception and data processing on the HTTP request, (5): Send the response result of the HTTP request to the first micro-frontend sub-application, (6): The second micro-frontend sub-application sends a data source registration request to the micro-frontend main application, (7): When it is detected that the data source registration request and HTTP request of the second micro-frontend sub-application are consistent with those of the first micro-frontend sub-application, the shared data source and shared data of the first micro-frontend sub-application are sent to the second micro-frontend sub-application.
[0055] In a specific implementation, Step 1: Encapsulate the data request component and create a unique instance in the main micro-frontend application. Step 2: Design and implement an interface for registering data sources in the main micro-frontend application. This interface will provide necessary APIs for the micro-frontend sub-applications to call to register data source information. When implementing the interface, the validity of the data source object should be verified by checking data fields, etc., and stored in the main application's data source registry for subsequent querying and use. Step 3: During initialization, the micro-frontend sub-application uses the communication mechanism provided by the micro-frontend framework to call the data source registration interface using the $datasource instance passed by the main micro-frontend application. The micro-frontend sub-application encapsulates its own data source information into a data source object and passes it as a parameter to the registration interface. The micro-frontend sub-application waits for the response from the registration interface. If registration is successful, it continues with subsequent operations; if registration fails, it handles the error information accordingly. Step 4: After receiving the registration information from the micro-frontend sub-application, the main micro-frontend application updates the data source registry, adding the new data source object to the registry. Step 5: The main micro-frontend application performs global request interception and data processing on the HTTP requests sent by the micro-frontend sub-applications.
[0056] This application achieves unified management, standardization, and enhanced security of data requests in a micro-frontend architecture by encapsulating unified data request instances, implementing interceptor-based access control and error handling, establishing a dynamic data source registration and query mechanism, and enabling data source and data sharing based on dynamic data sources. This will help improve the performance, stability, and user experience of micro-frontend applications, and promote data sharing and collaboration among sub-applications.
[0057] This application provides a micro-frontend request management system based on dynamic data sources. The system includes a main micro-frontend application and multiple micro-frontend sub-applications, each communicating with the main micro-frontend application. The main micro-frontend application encapsulates a data request component based on a client library and creates a unique data request instance. After sending the data request instance and a data source registration interface to the sub-applications, it receives a data source registration request from the sub-applications, adds the received data source object to a data source registration center, performs permission verification on a first HTTP request from the sub-applications based on the data request component, processes the first HTTP request that passes permission verification, determines the response result of the first HTTP request, and sends the response result to the sub-applications. Each sub-application encapsulates data source information based on the received data source registration interface, determines a data source object, sends the data source object to the main micro-frontend application for registration, constructs a first HTTP request based on the data source object and the data request instance, and sends the first HTTP request to the main micro-frontend application. The micro-frontend request management system based on dynamic data sources solves the problems of non-unique data request component instances and non-standard data requests in micro-frontend applications. It achieves unified management of data requests, improves the consistency and management capabilities of data requests, and enhances the security and stability of the system through a unified permission verification and data processing mechanism.
[0058] Please see Figure 3 , Figure 3 This is a flowchart illustrating a micro-frontend request management method based on a dynamic data source, provided as an embodiment of this application. Figure 3 As shown in the figure, the micro-frontend request management method based on dynamic data source provided in this application embodiment includes: S301: Encapsulate a data request component based on the client library and create a unique data request instance.
[0059] In this step, a data request component is encapsulated based on the client library, and a unique data request instance is created.
[0060] S302: Based on the received interface of the registered data source, encapsulate the data source information, determine the data source object, and add the data source object to the data source registration center.
[0061] In this step, the data source information is encapsulated based on the received registration data source interface, the data source object is determined, and the data source object is added to the data source registration center.
[0062] S303: Construct a first HTTP request based on the data source object and the data request instance, perform permission verification on the first HTTP request of the micro front-end sub-application based on the data request component, and perform data processing on the first HTTP request that has passed permission verification to determine the response result of the first HTTP request.
[0063] In this step, a first HTTP request is constructed based on the data source object and the data request instance. The first HTTP request of the micro front-end sub-application is then authenticated by the data request component, and the data of the first HTTP request that has passed the authentication is processed to determine the response result of the first HTTP request.
[0064] In one possible implementation, the micro-frontend request management method based on dynamic data sources further includes: Detect whether the caching option for the data source information is configured during the registration process; If so, the response result of the first HTTP request and the data source information are cached; When it is detected that the second HTTP request sent by the second micro-frontend application is consistent with the first HTTP request, the data source information and the response result of the first HTTP request are sent to the second micro-frontend application for data sharing.
[0065] In one possible implementation, the applicable approach to encapsulating a data request component based on a client library includes: The data request component is configured with basic functional encapsulation settings, data source functional encapsulation settings, and extended functional encapsulation settings. The basic function encapsulation settings include request header settings, request timeout settings, request cancellation function settings, and request interceptor function settings; the data source function encapsulation settings include API interfaces and configuration options; and the extended function encapsulation settings include response data processing settings, error handling settings, and log monitoring settings.
[0066] In one possible implementation, the permission verification of the first HTTP request from the micro-frontend application based on the data request component includes: Before the first HTTP request is sent to the main micro-frontend application, the pre-interceptor based on the data request instance performs permission verification on the identity information of the micro-frontend sub-application and the data source object to determine whether the micro-frontend sub-application has the permission to send the first HTTP request. If not, the pre-interceptor of the data request instance interrupts the sending of the first HTTP request of the micro-frontend application and sends an error message to the micro-frontend application; If so, then the sending of the first HTTP request of the micro frontend application is permitted.
[0067] In one possible implementation, the response result of the first HTTP request is determined in the following manner: The post-interceptor based on the data request instance performs JSON parsing, status code judgment, and data format encapsulation on the response data corresponding to the first HTTP request that has passed the permission verification, and determines the response result of the first HTTP request.
[0068] In one possible implementation, adding the received data source object to the data source registry includes: After receiving the data source object, the interface controlling the registration of the data source checks and validates the data fields of the data source object, and stores the validated data source object in the data source registration center of the micro-frontend main application; wherein, the data source object includes the interface address, request method and request parameters.
[0069] In one possible implementation, before constructing the first HTTP request based on the data source object and the data request instance, the micro-frontend request management method based on the dynamic data source further includes: The micro-frontend main application sends a query request for the data source object in the data source registry. If the micro-frontend main application reports that the data source object exists in the data source registry, then a first HTTP request is constructed based on the data source object and the data request instance.
[0070] This application provides a micro-frontend request management method based on dynamic data sources. The method includes: encapsulating a data request component and creating a unique data request instance based on a client library; encapsulating data source information based on the received interface of the registered data source, determining the data source object, and adding the data source object to the data source registration center; constructing a first HTTP request based on the data source object and the data request instance; performing permission verification on the first HTTP request of the micro-frontend sub-application based on the data request component; processing the data of the first HTTP request that passes permission verification; and determining the response result of the first HTTP request. This dynamic data source-based micro-frontend request management system solves the problems of non-unique data request component instances and non-standard data requests in micro-frontend applications, achieving unified management of data requests, improving data request consistency and management capabilities, and enhancing system security and stability through a unified permission verification and data processing mechanism.
[0071] Please see Figure 4 , Figure 4 This is a schematic diagram of the structure of an electronic device provided in an embodiment of this application. Figure 4 As shown, the electronic device 400 includes a processor 410, a memory 420, and a bus 430.
[0072] The memory 420 stores machine-readable instructions executable by the processor 410. When the electronic device 400 is running, the processor 410 communicates with the memory 420 via the bus 430. When the machine-readable instructions are executed by the processor 410, they can perform the operations described above. Figure 3 The steps of the micro-frontend request management method based on dynamic data source in the method embodiment shown are specifically implemented in the method embodiment and will not be repeated here.
[0073] This application also provides a computer-readable storage medium storing a computer program, which, when executed by a processor, can perform the above-described actions. Figure 3 The steps of the micro-frontend request management method based on dynamic data source in the method embodiment shown are specifically implemented in the method embodiment and will not be repeated here.
[0074] Those skilled in the art will understand that, for the sake of convenience and brevity, the specific working processes of the systems, devices, and units described above can be referred to the corresponding processes in the foregoing method embodiments, and will not be repeated here.
[0075] In the several embodiments provided in this application, it should be understood that the disclosed systems, apparatuses, and methods can be implemented in other ways. The apparatus 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. Furthermore, multiple units or components may be combined or integrated into another system, or some features may be ignored or not executed. Additionally, the shown or discussed mutual couplings, direct couplings, or communication connections may be through some communication interfaces; indirect couplings or communication connections between devices or units may be electrical, mechanical, or other forms.
[0076] 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.
[0077] In addition, 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.
[0078] If the aforementioned functions are implemented as software functional units and sold or used as independent products, they can be stored in a processor-executable, non-volatile, 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 a portion 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, portable hard drives, read-only memory (ROM), random access memory (RAM), magnetic disks, or optical disks.
[0079] Finally, it should be noted that the above-described embodiments are merely specific implementations of this application, used to illustrate the technical solutions of this application, and not to limit them. The scope of protection of this application is not limited thereto. Although this application has been described in detail with reference to the foregoing embodiments, those skilled in the art should understand that any person skilled in the art can still modify or easily conceive of changes to the technical solutions described in the foregoing embodiments, or make equivalent substitutions for some of the technical features, within the scope of the technology disclosed in this application. Such modifications, changes, or substitutions do not cause the essence of the corresponding technical solutions to deviate from the spirit and scope of the technical solutions of the embodiments of this application, and should all be covered within the scope of protection of this application. Therefore, the scope of protection of this application should be determined by the scope of the claims.
Claims
1. A micro-frontend request management system based on dynamic data sources, characterized in that, The micro-frontend request management system based on dynamic data sources includes a main micro-frontend application and multiple micro-frontend sub-applications, each of which is communicatively connected to the main micro-frontend application; wherein... The micro-frontend main application is used to encapsulate a data request component based on the client library and create a unique data request instance. After sending the data request instance and the interface for registering the data source to the micro-frontend sub-application, it receives the data source registration request sent by the micro-frontend sub-application, adds the received data source object to the data source registration center, performs permission verification on the first HTTP request of the micro-frontend sub-application based on the data request component, processes the data of the first HTTP request that has passed permission verification, determines the response result of the first HTTP request, and sends the response result to the micro-frontend sub-application. The micro-frontend sub-application is used to encapsulate data source information based on the received interface of the registered data source, determine the data source object, and send the data source object to the micro-frontend main application for registration. Based on the data source object and the data request instance, a first HTTP request is constructed and sent to the micro-frontend main application.
2. The micro-frontend request management system based on dynamic data sources according to claim 1, characterized in that, The micro-frontend main application is also used for: Detect whether the caching option for the data source information is configured during the registration process; If so, the response result of the first HTTP request and the data source information are cached; When it is detected that the second HTTP request sent by the second micro-frontend application is consistent with the first HTTP request, the data source information and the response result of the first HTTP request are sent to the second micro-frontend application for data sharing.
3. The micro-frontend request management system based on dynamic data sources according to claim 1, characterized in that, When the micro-frontend main application is used to encapsulate a data request component based on a client library, the micro-frontend main application is specifically used for: The data request component is configured with basic functional encapsulation settings, data source functional encapsulation settings, and extended functional encapsulation settings. The basic function encapsulation settings include request header settings, request timeout settings, request cancellation function settings, and request interceptor function settings; the data source function encapsulation settings include API interfaces and configuration options; and the extended function encapsulation settings include response data processing settings, error handling settings, and log monitoring settings.
4. The micro-frontend request management system based on dynamic data sources according to claim 1, characterized in that, When the main micro-frontend application performs permission verification on the first HTTP request of the micro-frontend sub-application based on the data request component, the main micro-frontend application is specifically used for: Before the first HTTP request is sent to the main micro-frontend application, the pre-interceptor based on the data request instance performs permission verification on the identity information of the micro-frontend sub-application and the data source object to determine whether the micro-frontend sub-application has the permission to send the first HTTP request. If not, the pre-interceptor of the data request instance interrupts the sending of the first HTTP request of the micro-frontend application and sends an error message to the micro-frontend application; If so, then the sending of the first HTTP request of the micro frontend application is permitted.
5. The micro-frontend request management system based on dynamic data sources according to claim 1, characterized in that, The micro-frontend main application determines the response result of the first HTTP request in the following way: The post-interceptor based on the data request instance performs JSON parsing, status code judgment, and data format encapsulation on the response data corresponding to the first HTTP request that has passed the permission verification, and determines the response result of the first HTTP request.
6. The micro-frontend request management system based on dynamic data sources according to claim 1, characterized in that, When the micro-frontend main application adds the received data source object to the data source registry, the micro-frontend main application is specifically used for: After receiving the data source object, the interface for registering the data source checks and validates the data fields of the data source object, and stores the validated data source object in the data source registration center of the micro-frontend main application; wherein, the data source object includes the interface address, request method and request parameters.
7. The micro-frontend request management system based on dynamic data sources according to claim 1, characterized in that, Before constructing the first HTTP request based on the data source object and the data request instance, the micro-frontend sub-application is further configured to: The micro-frontend main application sends a query request for the data source object in the data source registry. If the micro-frontend main application reports that the data source object exists in the data source registry, then a first HTTP request is constructed based on the data source object and the data request instance.
8. A micro-frontend request management method based on dynamic data sources, characterized in that, The micro-frontend request management method based on dynamic data sources includes: Encapsulate a data request component based on a client library and create a unique data request instance; Based on the received interface of the registered data source, the data source information is encapsulated, the data source object is determined, and the data source object is added to the data source registration center; A first HTTP request is constructed based on the data source object and the data request instance. The first HTTP request of the micro-frontend sub-application is verified for permissions based on the data request component. Data processing is performed on the first HTTP request that has passed the permission verification to determine the response result of the first HTTP request.
9. An electronic device, characterized in that, include: The device includes a processor, a memory, and a bus. The memory stores machine-readable instructions executable by the processor. When the electronic device is running, the processor communicates with the memory via the bus. The machine-readable instructions are executed by the processor to perform the steps of the micro-frontend request management method based on a dynamic data source as described in claim 8.
10. A computer-readable storage medium, characterized in that, The computer-readable storage medium stores a computer program that, when executed by a processor, performs the steps of the micro-frontend request management method based on a dynamic data source as described in claim 8.