A cross-application communication method, system and device based on a micro-frontend architecture and a storage medium

Abstract

The application relates to the technical field of front-end architecture, in particular to a cross-application communication method, system and device based on a micro front-end architecture and a storage medium. The cross-application communication system based on the micro front-end architecture comprises a communication hub module, a protocol standardization module, a security handshake module, a routing distribution module and a state synchronization module. With the development of enterprise-level web applications in the direction of modularization and multi-team cooperation, the micro front-end architecture becomes a key technology for solving the splitting and integration of complex applications.

Description

Technical Field

[0001] This invention relates to the field of front-end architecture technology, and in particular to a cross-application communication method, system, device and storage medium based on a micro-front-end architecture. Background Technology

[0002] As enterprise web applications evolve towards modularity and multi-team collaboration, micro-frontend architecture has become a key technology for solving the decomposition and integration of complex applications. Under this architecture, the communication needs between the base application (main application) and sub-pages (micro-applications), as well as between sub-pages themselves, are becoming increasingly complex. However, existing technical solutions have the following shortcomings: Under browser same-origin policy restrictions, cross-domain communication relies on native APIs such as postMessage, but lacks mandatory identity verification of the message source, resulting in insufficient security and trust verification mechanisms for cross-domain communication (e.g., malicious third-party pages forging the base application's identity and injecting illegal commands into sub-pages via postMessage); the global event bus model does not achieve namespace isolation, and event listeners from different modules may interfere with each other due to events with the same name, leading to logical anomalies caused by event naming conflicts (e.g., in an e-commerce platform, both the product details page and the shopping cart sub-page listen to the cart_update event, but conflicting processing logic leads to incorrect calculation of the shopping cart quantity); micro-frontend sub-pages maintain their state independently, and cross-application state synchronization relies on passive event notifications, lacking proactive consistency guarantees, thus causing data consistency problems due to distributed state management; based on the above problems and a comparative analysis of existing technologies, the core shortcomings of mainstream micro-frontend communication solutions are as follows: Figure 4 As shown. Summary of the Invention

[0003] The present invention aims to solve at least one of the technical problems existing in the prior art, and provides a cross-application communication method and system based on a micro-frontend architecture.

[0004] To achieve the above objectives, the present invention adopts the following technical solution:

[0005] In a first aspect, the present invention provides a cross-application communication method based on a micro-frontend architecture, comprising the following steps:

[0006] The communication hub module filters the external data information collected by the Web top-level base through information type, and sends the filtered and classified data tag information parameters to the protocol standardization module respectively.

[0007] The protocol standardization module integrates and preprocesses the tagged information parameters to generate standard parameters for a standardized message format.

[0008] The secure handshake module filters out the corresponding verification keys according to the different uses of the standard parameters, inputs the verification keys into the computing token for handshake verification, and achieves a trusted handshake through bidirectional verification of the dynamic handshake token. When the handshake fails, the circuit breaker mechanism is triggered and the security log is recorded.

[0009] The standard parameters of the established handshake are identified and recorded by the routing and distribution module, and a unique identifier for the subpage is generated to realize message routing. If the standard parameter is a subbase, it is recursively forwarded according to the registry hierarchy. If the standard parameter is a page, it is relayed through the Web top-level base, and permission verification is added in cross-domain scenarios.

[0010] The state synchronization module adopts a publish-subscribe pattern to broadcast global state change events to all subscribing nodes and embeds version numbers in the data payload to achieve consistency verification.

[0011] In some possible instances, the dynamic handshake token is generated as follows:

[0012] Based on the SHA-256 hash algorithm, a one-time token is generated by concatenating the timestamp, source identifier and pre-shared key, and disappears immediately after message processing is completed.

[0013] In some possible instances, the standard parameters of the established handshake are identified and recorded by the routing and distribution module, and a unique identifier for the subpage is generated to realize message routing. If the standard parameter is a sub-base, it is recursively forwarded according to the registry hierarchy. If the standard parameter is a page, it is relayed through the top-level Web base. In cross-domain scenarios, permission verification is added, and the following steps are also included:

[0014] If the standard parameter is a subbase, it is forwarded recursively according to the hierarchical order of the subbase registry until the target identifier is matched or a timeout exception is triggered.

[0015] If the standard parameter is a page, the subpage registry is queried through the Web top-level base. If the target page exists and its status is connected, the request is forwarded to the target page; otherwise, the "target unreachable" error code is returned.

[0016] In some possible instances, the message types of the protocol standardization module include: initiating a handshake, replying to a handshake, deleting a handshake, method call request, method call response, event broadcast, and exception notification, and each message type is associated with an independent permission whitelist.

[0017] In some possible instances, the data version consistency verification method of the state synchronization module is as follows:

[0018] Embedding a monotonically increasing version number in the data payload, the receiver rejects update requests with version numbers lower than the local cache and returns a "version conflict" error code and the current latest version number.

[0019] In some possible instances, the circuit breaker mechanism of the secure handshake module includes:

[0020] If the standard parameters from the same source send invalid handshake requests continuously for more than a threshold within a set time, then the standard parameters from that source will be added to the blacklist and subsequent communication will be blocked.

[0021] After a successful handshake, the connection is maintained through heartbeat detection. If the heartbeat times out, the handshake deletion process is automatically triggered.

[0022] Secondly, the present invention provides a cross-application communication system based on a micro-frontend architecture, comprising: a communication hub module, a protocol standardization module, a security handshake module, a routing and distribution module, and a state synchronization module.

[0023] The communication hub module collects external data information through the Web top-level base and filters the data information by information type, and marks the filtered and classified data with information parameters.

[0024] The protocol standardization module integrates and preprocesses the tagged data information parameters to generate standard parameters for a standardized message format.

[0025] The secure handshake module obtains the corresponding verification key by filtering the standard parameters for different purposes, and inputs the verification key into the calculation token for handshake verification. A trusted handshake is achieved through bidirectional verification of the dynamic handshake token.

[0026] The routing distribution module generates a unique identifier for the subpage by identifying and recording the standard parameters of the established handshake, recursively forwards the standard parameters of the subbase nature in the order of the registry hierarchy, and forwards the standard parameters of the page nature through the Web top-level base, and adds permission verification in cross-domain scenarios.

[0027] The state synchronization module broadcasts global state change events to all subscribing nodes using a publish-subscribe pattern and embeds version numbers in the data payload.

[0028] In some possible instances, the communication hub module adapts to cross-platform environments in the following ways:

[0029] Standardized messages are converted into the target platform's native communication protocol through a bridging layer, including Uniapp's uni.postMessage, Lark Mini Program's tt.miniProgram.createMessageManager, and the Web environment's window.postMessage.

[0030] Thirdly, the present invention provides an electronic device, comprising:

[0031] One or more processors;

[0032] A storage unit is used to store one or more programs, which, when executed by one or more processors, enable the one or more processors to implement the cross-application communication method based on a micro-frontend architecture as described above.

[0033] Fourthly, the present invention provides a computer-readable storage medium, wherein the computer program, when executed by a processor, can implement the cross-application communication method based on a micro-frontend architecture described above.

[0034] The cross-application communication method based on micro-frontend architecture in this invention has the following advantages:

[0035] 1. Communication security is significantly improved.

[0036] Dynamic token authentication: Based on the SHA-256 token verification mechanism, the unauthorized access interception rate reached 99.97% in the simulated man-in-the-middle attack test (test sample: 10,000 attack requests).

[0037] Fine-grained access control: Supports defining access whitelists by message type, source identifier, and target identifier, reducing the violation rate of access control policies from 12.6% in traditional solutions to 0.2% (data source: stress test of a mining system).

[0038] Secure handshake circuit breaker: Automatically blocks malicious high-frequency handshake requests after 5 consecutive failures, reducing system resource utilization by 83% (comparison: similar solutions without circuit breaker mechanism).

[0039] 2. Optimization of communication efficiency and reliability

[0040] Routing performance: In a scenario with 10 concurrent subpages, the average message routing latency is ≤50ms, which is 84% ​​better than the native postMessage solution (average latency 320ms).

[0041] State synchronization consistency: Through mandatory version number verification, the data consistency guarantee rate in distributed scenarios is 100% (compared to: the conflict rate of no version control scheme is 22%).

[0042] 3. Reduced development and maintenance costs

[0043] Standardized API: Provides Promise-based calling interfaces, reducing communication-related code by 70% (Case study: Modification of the production module of a mining platform).

[0044] Event conflict elimination: The global event registry center implements namespace isolation, and the number of abnormal triggers of event listeners has been reduced from 153 times / day to 0 times (data source: production monitoring of a mining system).

[0045] Fault location efficiency: End-to-end message UUID tracing + structured logs reduce the average fault troubleshooting time from 4.2 hours to 0.5 hours.

[0046] 4. Multi-platform compatibility extension

[0047] Protocol standardization: By adapting to mainstream platforms such as Lark Mini Program, Uniapp, and Web through the bridging layer, the reusability of communication code is increased to 95%.

[0048] Cross-domain scenario coverage: Supports communication topologies such as same-origin, cross-domain, and hybrid nesting (such as mini-programs embedded in web applications), with coverage increased by 300% compared to existing solutions. Attached Figure Description

[0049] Figure 1 This is a schematic diagram of the structure of an example electronic device for the cross-application communication method and system based on micro-frontend architecture of the present invention;

[0050] Figure 2 This is a flowchart of the cross-application communication method based on micro-frontend architecture of the present invention;

[0051] Figure 3 This is a schematic diagram of the cross-application communication system based on a micro-frontend architecture according to the present invention.

[0052] Figure 4 This diagram illustrates the core shortcomings of mainstream micro-frontend communication solutions. Detailed Implementation

[0053] The technical solution of the present invention will now be clearly and completely described with reference to the accompanying drawings. Obviously, the described embodiments are only some, not all, of the embodiments of the present invention. Based on the embodiments of the present invention, all other embodiments obtained by those skilled in the art without creative effort are within the scope of protection of the present invention.

[0054] Figure 1 This is a schematic diagram of the structure of an example electronic device for implementing a cross-application communication method and system based on a micro-frontend architecture, as described in this invention. Figure 1As shown, the electronic device includes one or more processors, one or more storage devices, one or more input devices, one or more output devices, etc., and these components are interconnected via a bus system and / or other forms of connection mechanisms. It should be noted that... Figure 1 The components and structures of the electronic devices shown are merely exemplary and not limiting; other components and structures may be used as needed.

[0055] A processor can be a central processing unit (CPU), or it can be a processing unit consisting of multiple processing cores, or other forms of processing unit with data processing capabilities and / or instruction execution capabilities, and can control other components in an electronic device to perform desired functions.

[0056] The storage device may include one or more computer program products, which may include various forms of computer-readable storage media, such as volatile memory and / or non-volatile memory. The volatile memory may include, for example, random access memory (RAM) and / or cache memory. The non-volatile memory may include, for example, read-only memory (ROM), hard disk, flash memory, etc. One or more computer program instructions may be stored on the computer-readable storage medium, which a processor may execute to implement the client functions (implemented by a processor) in the embodiments of this disclosure described below, and / or other desired functions. Various applications and various data may also be stored in the computer-readable storage medium, such as various data used and / or generated by the applications.

[0057] The input device can be a device used by a user to input instructions, and may include one or more of the following: keyboard, mouse, microphone, and touch screen.

[0058] Output devices can output various information (such as images or sounds) to the outside (e.g., a user) and may include one or more of a display, a speaker, etc.

[0059] Figure 2 This is a flowchart of the cross-application communication method based on a micro-frontend architecture according to the present invention. Figure 2 As shown, a cross-application communication method based on a micro-frontend architecture includes the following steps S1 to S5. Step S1: The communication hub module filters the external data information (in this embodiment, the external data information refers to APP / mini-program and browser data) collected by the Web top-level base (in this embodiment, the Web top-level base refers to the container application at the top level of the micro-frontend architecture, which is responsible for managing the communication routing, state synchronization and security policies of all sub-bases and sub-pages, and has a globally unique identifier) ​​by information type, and sends the filtered and classified data tag information parameters to the protocol standardization module respectively.

[0060] Step S2: The tagged information parameters are integrated and preprocessed through the protocol standardization module to generate standard parameters for a standardized message format;

[0061] Step S3: The secure handshake module filters out corresponding verification keys based on the different uses of the standard parameters, inputs the verification keys into the calculation token for handshake verification, and achieves a trusted handshake through bidirectional verification using the dynamic handshake token. If the handshake fails, a circuit breaker mechanism is triggered and a security log is recorded. In this embodiment, the dynamic handshake token is a temporary identity credential generated based on a cryptographic algorithm, used to verify the legitimacy of both communicating parties. Its generation rule is: Token = Hash(pre-shared key + source identifier + timestamp), and its validity period is a single communication session cycle. The circuit breaker mechanism in this embodiment is an exception handling strategy of the secure handshake module. When N consecutive (default N=5) invalid handshake requests are detected, subsequent communication from that source is automatically blocked and an alarm is triggered until manual intervention is required to reset.

[0062] Step S4 uses the routing distribution module to identify and record the standard parameters of the established handshake, generating a unique identifier for each subpage to achieve message routing. If the standard parameter is a subbase, it is recursively forwarded according to the registry hierarchy; if the standard parameter is a page, it is relayed through the Web top-level base, with additional permission verification in cross-domain scenarios. In this embodiment, the subbase belongs to a nested container application of the Web top-level base and can independently manage its subpages, establishing a parent-child relationship with the Web top-level base through a hierarchical registry. The communication behavior of the subbase is constrained by the routing rules of the Web top-level base. The registry in this embodiment is mainly a data structure used by the base to record pages that have established handshakes, implemented using a hash table. The key is the unique identifier of the page, and the value is metadata including communication status, permission level, and last active timestamp. The page in this embodiment is an independent front-end application embedded in the base (Web top-level base or subbase), interacting with the base and other pages through a standardized communication protocol.

[0063] Step S5 uses the publish-subscribe pattern through the state synchronization module to broadcast global state change events to all subscribing nodes and embeds version numbers in the data payload to achieve consistency verification.

[0064] In this example, the dynamic handshake token is generated as follows:

[0065] Based on the SHA-256 hash algorithm, a one-time token is generated by concatenating the timestamp, source identifier and pre-shared key, and it disappears immediately after message processing is completed;

[0066] The specific steps of the SHA-256 hash algorithm in this embodiment are as follows: Using the crypto-js library, SHA-256 encryption can be implemented through the following code: const hash = CryptoJS.SHA256("string to be encrypted").toString(CryptoJS.enc.Hex).

[0067] In this example, the standard parameters of the established handshake are identified and recorded by the routing and distribution module, and a unique identifier for the subpage is generated to realize message routing. If the standard parameter is a sub-base, it is recursively forwarded according to the registry hierarchy. If the standard parameter is a page, it is relayed through the Web top-level base. In cross-domain scenarios, permission verification is added, and the following steps are also included:

[0068] If the standard parameter is a subbase, it is forwarded recursively according to the hierarchical order of the subbase registry until the target identifier is matched or a timeout exception is triggered.

[0069] If the standard parameter is a page, the subpage registry is queried through the Web top-level base. If the target page exists and its status is connected, the request is forwarded to the target page; otherwise, the "target unreachable" error code is returned.

[0070] In this example, the message types of the protocol standardization module include: initiating a handshake, replying to a handshake, deleting a handshake, method call request, method call response, event broadcast, and exception notification, and each message type is associated with an independent permission whitelist.

[0071] In this example, the data version consistency verification method of the state synchronization module is as follows:

[0072] Embedding a monotonically increasing version number in the data payload, the receiver rejects update requests with version numbers lower than the local cache and returns a "version conflict" error code and the current latest version number.

[0073] In this example, the circuit breaker mechanism of the secure handshake module includes:

[0074] If the standard parameters from the same source send invalid handshake requests continuously for more than a threshold within a set time, then the standard parameters from that source will be added to the blacklist and subsequent communication will be blocked.

[0075] After a successful handshake, the connection is maintained through heartbeat detection. If the heartbeat times out, the handshake deletion process is automatically triggered.

[0076] This example also includes the following operating modes:

[0077] 1. Base initialization:

[0078] Initialize the base at the top level of the page;

[0079] Listen for dispatched message events through the window and wait to receive and process messages;

[0080] If the page is not the top-level page, the child page initiates a handshake with the top-level web page through the window.postMessage method;

[0081] Listen for the load event dispatched by the window and wait for the entire page and all dependent resources (including subframes) to finish loading;

[0082] If the page is not the top-level element, listen for the unload event dispatched by the window. When the page is unloaded, the child base removes the handshake to all the parent bases through the window.postMessage method.

[0083] The base registers methods and listens for events using a hash table, waiting for page interaction.

[0084] When a page is opened via a webview, the top-level base is a uniapp or a mini-program, and the communication between the base and the page is through the Bridge API provided by the uniapp or mini-program.

[0085] 2. Page initialization:

[0086] Initialize the page at the top level;

[0087] Listen for dispatched message events through the window and wait to receive messages;

[0088] The page initiates a handshake with all upper-level bases via the window.postMessage method and waits for a response from the top-level Web base.

[0089] By listening for the unload event dispatched by the window, when the page is unloaded, the page uses the window.postMessage method to remove the handshake to all upper-level bases;

[0090] The page registers methods and listeners for events using a hash table, waiting for the base to interact with it.

[0091] 3. Standardized message format

[0092] Message protocol: Protocol version label;

[0093] Message types include: initiating a handshake, replying to a handshake, deleting a handshake, initiating a request, and replying to a request;

[0094] Message UUID: Serves as a temporary identifier for initiating a message. By including this identifier in the reply message, a message can be initiated and a reply message can be completed.

[0095] Data payload: The data of the message;

[0096] Source types: including base and page;

[0097] Source identifier: The identifier of the page that initiated the message;

[0098] Target identifier: The identifier of the page receiving the message;

[0099] Dynamic token field: Enhances communication security;

[0100] Data version: Data version number (used for status synchronization).

[0101] 4. Message routing:

[0102] Standardized messages are sent using the window.postMessage method, and the window listens for dispatched message events.

[0103] Both the base and the page will verify the message upon receiving it, and only continue processing if the verification is successful.

[0104] When a page sends a message to the base, the message first reaches the top-level Web base. The top-level Web base then finds the target base through the sub-base registry. After processing the message, the target base replies to the page with a message.

[0105] The base sends messages directly to the page via the target identifier;

[0106] When a page is opened via a webview, the page sends a message to the base layer. The message first reaches the top-level web base layer, which then determines whether to forward the message to the upper layer based on the runtime environment.

[0107] Secondly, the present invention provides a cross-application communication system based on a micro-frontend architecture, comprising: a communication hub module, a protocol standardization module, a security handshake module, a routing and distribution module, and a state synchronization module.

[0108] The communication hub module collects external data information through the Web top-level base and filters the data information by information type, and marks the filtered and classified data with information parameters.

[0109] The protocol standardization module integrates and preprocesses the tagged data information parameters to generate standard parameters for a standardized message format.

[0110] The secure handshake module obtains the corresponding verification key by filtering the standard parameters for different purposes, and inputs the verification key into the calculation token for handshake verification. A trusted handshake is achieved through bidirectional verification of the dynamic handshake token.

[0111] The routing distribution module generates a unique identifier for the subpage by identifying and recording the standard parameters of the established handshake, recursively forwards the standard parameters of the subbase nature in the order of the registry hierarchy, and forwards the standard parameters of the page nature through the Web top-level base, and adds permission verification in cross-domain scenarios.

[0112] The state synchronization module broadcasts global state change events to all subscribing nodes using a publish-subscribe pattern and embeds version numbers in the data payload.

[0113] In this example, the communication hub module adapts to cross-platform environments in the following way:

[0114] Standardized messages are converted into the target platform's native communication protocol through a bridging layer, including Uniapp's uni.postMessage, Lark Mini Program's tt.miniProgram.createMessageManager, and the Web environment's window.postMessage.

[0115] This embodiment includes the following signal transmission modes:

[0116] 1. Method call

[0117] The module includes a communication hub module, a protocol standardization module, a secure handshake module, a routing and distribution module, and a state synchronization module.

[0118] When calling method A to the base via a terminal, storage unit, or mini-program, the system's backend first sends a method call request to the top-level Web base. The top-level Web base first determines whether to forward the message to the upper layer by checking if method A is registered there. Then, it searches the registry in hierarchical order. If a base has registered method A, it will call method A and send a response request to the page. If no base has registered method A, it will throw a "method not found" exception.

[0119] When page 1 opens page 2, a connection is established between page 2 and page 1. Page 1 maintains a registry of opened pages through a hash table. When page 1 opens page 2, it registers method A through the opened page registry for page 2 to call. When needed, page 2 finds page 1 and calls method A.

[0120] Launch event

[0121] When a page emits event A to a base, it first sends an event emission request to the top-level Web base. The top-level Web base first forwards the message to all upper-level bases of the page according to the registry, and then forwards the message to the upper layers (Uniapp and mini-program). When a base listens for event A, that base will trigger event A.

[0122] Thirdly, the present invention provides an electronic device, comprising:

[0123] One or more processors;

[0124] A storage unit for storing one or more programs, which, when executed by one or more processors, enable the one or more processors to implement a cross-application communication method based on a micro-frontend architecture as described in any one of claims 1 to 6.

[0125] Fourthly, the present invention provides a computer-readable storage medium having a computer program stored thereon, which, when executed by a processor, can implement the method described above.

[0126] The computer-readable medium may be included in the apparatus, device, or system disclosed herein, or it may exist independently.

[0127] The computer-readable storage medium may be any tangible medium that contains or stores a program, and may be an electrical, magnetic, optical, electromagnetic, infrared, or semiconductor system, apparatus, or device. More specific examples include, but are not limited to, electrical connections having one or more wires, portable computer disks, hard disks, optical fibers, random access memory (RAM), read-only memory (ROM), erasable programmable read-only memory (EPROM or flash memory), portable compact disk read-only memory (CD-ROM), optical storage devices, magnetic storage devices, or any suitable combination thereof.

[0128] The computer-readable storage medium may also include data signals propagated in baseband or as part of a carrier wave, carrying computer-readable program code, specific examples of which include, but are not limited to, electromagnetic signals, optical signals, or any suitable combination thereof.

[0129] Parameter description:

[0130] All parameter values ​​mentioned in this manual are not subjective assumptions, but rather a comprehensive result of the application scenario's security / efficiency requirements, industry standards and specifications, and industry practice experience thresholds. In actual applications, the parameters will be fine-tuned according to the relevant scenarios.

[0131] Finally, it should be noted that the above embodiments are only used to illustrate the technical solutions of the present invention, and not to limit them; although the present invention has been described in detail with reference to the foregoing embodiments, those skilled in the art should understand that modifications can still be made to the technical solutions described in the foregoing embodiments, or equivalent substitutions can be made to some or all of the technical features; and these modifications or substitutions do not cause the essence of the corresponding technical solutions to deviate from the scope of the technical solutions of the embodiments of the present invention.

Claims

1. A cross-application communication method based on a micro-frontend architecture, characterized in that, Includes the following steps: The communication hub module filters the external data information collected by the Web top-level base through information type, and sends the filtered and classified data tag information parameters to the protocol standardization module respectively. The protocol standardization module integrates and preprocesses the tagged information parameters to generate standard parameters for a standardized message format. The secure handshake module filters out the corresponding verification keys according to the different uses of the standard parameters, inputs the verification keys into the computing token for handshake verification, and achieves a trusted handshake through bidirectional verification of the dynamic handshake token. When the handshake fails, the circuit breaker mechanism is triggered and the security log is recorded. The routing and distribution module identifies and records the standard parameters of the established handshake, generates a unique identifier for the subpage to realize message routing. If the standard parameter is a subbase, it is recursively forwarded according to the hierarchical order of the subbase registry until the target identifier is matched or a timeout exception is triggered. If the standard parameter is a page, the subpage registry is queried through the Web top-level base. If the target page exists and its status is connected, it is forwarded to the target page; otherwise, the 'target unreachable' error code is returned. The state synchronization module adopts a publish-subscribe pattern to broadcast global state change events to all subscribing nodes and embeds version numbers in the data payload to achieve consistency verification.

2. The cross-application communication method based on micro-frontend architecture according to claim 1, characterized in that, The dynamic handshake token is generated in the following way: Based on the SHA-256 hash algorithm, a one-time token is generated by concatenating the timestamp, source identifier and pre-shared key, and disappears immediately after message processing is completed.

3. The cross-application communication method based on micro-frontend architecture according to claim 1, characterized in that, The routing and distribution module identifies and records the standard parameters of the established handshake, generates a unique identifier for the subpage to achieve message routing, and if the standard parameter is a subbase, it is recursively forwarded according to the registry hierarchy; if the standard parameter is a page, it is relayed through the top-level Web base. In cross-domain scenarios, permission verification is added, and the following steps are also included: If the standard parameter is a subbase, it is forwarded recursively according to the hierarchical order of the subbase registry until the target identifier is matched or a timeout exception is triggered. If the standard parameter is a page, the subpage registry is queried through the Web top-level base. If the target page exists and its status is connected, the request is forwarded to the target page; otherwise, the "target unreachable" error code is returned.

4. The cross-application communication method based on a micro-frontend architecture according to claim 1, characterized in that, The message types of the protocol standardization module include: initiating a handshake, replying to a handshake, deleting a handshake, method call request, method call response, event broadcast, and exception notification, and each message type is associated with an independent permission whitelist.

5. The cross-application communication method based on a micro-frontend architecture according to claim 1, characterized in that, The data version consistency verification method of the state synchronization module is as follows: Embedding a monotonically increasing version number in the data payload, the receiver rejects update requests with version numbers lower than the local cache and returns a "version conflict" error code and the current latest version number.

6. The cross-application communication method based on a micro-frontend architecture according to claim 1, characterized in that, The circuit breaker mechanism of the secure handshake module includes: If the standard parameters from the same source send invalid handshake requests continuously for more than a threshold within a set time, then the standard parameters from that source will be added to the blacklist and subsequent communication will be blocked. After a successful handshake, the connection is maintained through heartbeat detection. If the heartbeat times out, the handshake deletion process is automatically triggered.

7. A cross-application communication system based on a micro-frontend architecture, characterized in that, include: The communication hub module, protocol standardization module, security handshake module, routing distribution module, and state synchronization module are as follows: The communication hub module collects external data information through the Web top-level base and filters the data information by information type, and marks the filtered and classified data with information parameters. The protocol standardization module integrates and preprocesses the tagged data information parameters to generate standard parameters for a standardized message format. The secure handshake module obtains the corresponding verification key by filtering the standard parameters for different purposes, and inputs the verification key into the calculation token for handshake verification. A trusted handshake is achieved through bidirectional verification of the dynamic handshake token. The routing and distribution module generates a unique identifier for a subpage by identifying and recording the standard parameters of the established handshake. It then recursively forwards the standard parameters of the sub-base nature in the order of the registry hierarchy until a target identifier is matched or a timeout exception is triggered. The standard parameters of the page nature are then relayed through the Web top-level base. If the standard parameters are found to exist on the target page and the status is "connected", the page is forwarded to the target page; otherwise, a "target unreachable" error code is returned. The state synchronization module broadcasts global state change events to all subscribing nodes using a publish-subscribe pattern and embeds version numbers in the data payload.

8. A cross-application communication system based on a micro-frontend architecture according to claim 7, characterized in that, The communication hub module's communication adaptation method in a cross-platform environment is as follows: Standardized messages are converted into the target platform's native communication protocol through a bridging layer, including Uniapp's uni.postMessage, Lark Mini Program's tt.miniProgram.createMessageManager, and the Web environment's window.postMessage.

9. An electronic device, characterized in that, include: One or more processors; A storage unit for storing one or more programs, which, when executed by one or more processors, enable the one or more processors to implement a cross-application communication method based on a micro-frontend architecture as described in any one of claims 1 to 6.

10. A computer-readable storage medium having a computer program stored thereon, characterized in that, When the computer program is executed by the processor, it can implement a cross-application communication method based on a micro-frontend architecture as described in any one of claims 1 to 6.

Images