Communication method between micro-front-end master application and micro-front-end slave application, electronic equipment and storage medium
By using the handshake and verification mechanism of Web native API and Promise objects in the micro front-end architecture, the complexity of cross-domain master-slave applications is solved, and secure two-way data exchange and sequential asynchronous processing are realized, which simplifies the development process .
Patent Information
- Application Number
- CN202411219283.9
- Authority / Receiving Office
- CN · China
- Patent Type
- Applications(China)
- Current Assignee / Owner
- Filing Date
- 2024-09-02
- Publication Date
- 2025-01-03
AI Technical Summary
In the micro front-end architecture, in the cross-domain situation based on iframe implementation, the master and slave applications cannot directly access the other party's context information, resulting in complex communication and inconvenient development.
Using a handshake, information verification and two-way communication model based on Web native API and Promise standard objects, we ensure secure communication between master and slave applications by defining packet structure and verification rules, and provide interface objects to realize two-way data exchange.
It realizes secure two-way communication between cross-domain micro front-end applications, and processes asynchronous operations in sequence, simplifies the integration of master and slave applications, and avoids logical splits in native API monitoring mode.
Smart Images

Figure CN119248534A_ABST
Abstract
Description
Technical Field
[0001] The present invention relates to the field of computer application communication technology, and specifically to a communication method between a micro-front-end master and slave application, an electronic device and a storage medium. Background Art
[0002] Micro Frontends is a software architecture pattern that draws on the idea of backend microservice architecture and splits a complex single front-end application into multiple small front-end applications that can be independently developed, deployed, and maintained. Micro Frontends splits large front-end applications into multiple small, independently deployable front-end applications that can coexist and work together in the same host environment to form a unified user experience.
[0003] To implement the micro-frontend architecture, the mutual communication between the master and slave applications (the main application of the micro-frontend framework, hereinafter referred to as the master application; the integrated sub-application, hereinafter referred to as the slave application) is one of the main problems to be solved. Among them, the iframe-based framework is one of the implementation methods of the micro-frontend architecture. In this communication mode, when the master and slave applications are deployed in the same domain, the slave application can directly access the context of the master application, and there is no obstacle to communication; but when deployed across domains, the master and slave applications cannot directly access each other's context. At present, the native API message method is mainly used for communication, but this method belongs to a one-way message dispatching and monitoring mode, the processing logic is separated, and the response cannot be obtained sequentially; using the native API message method, the master application cannot provide a unified context interface to the slave application, which makes the slave application processing logic complicated and inconvenient to develop and integrate during integration. Summary of the invention
[0004] The technical task of the present invention is to provide a communication method, electronic device and storage medium between micro-frontend master and slave applications to solve the problem that in a micro-frontend architecture implemented based on iframe, the slave application cannot call the interface provided by the master application to obtain contextual information such as users and permissions in a cross-domain situation.
[0005] The technical task of the present invention is achieved in the following way: a communication method between a micro-frontend master and slave application, which is based on Web native API and Promise standard object, and realizes secure communication between master and slave applications under the micro-frontend architecture by implementing a communication model including handshake, information verification, two-way communication, and connection termination between the master application and the slave application; the details are as follows:
[0006] Define the message structure for communication between the two parties as the basis for communication between the master and slave applications;
[0007] Define verification rules for communication messages: Verify the message data received by the master and slave applications to ensure communication security between the master and slave applications;
[0008] The interface objects provided by the master application and the slave application to each other are respectively encapsulated, and the interface objects contain function interfaces for direct calls by the other party;
[0009] When the master application successfully loads the slave application instance, a connection is created between the master application and the slave application through handshake to ensure normal communication between the master application and the slave application.
[0010] Two-way communication transmission between master application and slave application;
[0011] When the user ends access to the slave application, the master application disconnects the communication connection with the slave application, uninstalls the slave application within the micro-frontend framework, and reclaims the allocated resources.
[0012] Preferably, the function interface is divided into a request type function interface and a notification type function interface; wherein the calling method of the request type function obtains the response data after the function is processed.
[0013] As a preferred embodiment, the message structure of the communication between the two parties is as follows:
[0014] Message type: used to specify the purpose and function of this communication;
[0015] Message format: specifies a special message format identifier for the communication model to distinguish whether it is receivable message data;
[0016] Message ID: A unique ID assigned to a complete communication, used to define the same request and response message data;
[0017] Message data: specific business data carried by the communication between two parties.
[0018] As a preferred embodiment, the verification rules are as follows:
[0019] Check the Origin parameter of the native API to verify whether the message source is legitimate;
[0020] Verify whether the message has a message body;
[0021] Verify whether the format of the message is legal;
[0022] Verify whether the message has a type field and whether the type is legal;
[0023] For the response message data, verify whether it comes from the same request.
[0024] As a preferred embodiment, the interface objects provided by the master application and the slave application to each other are respectively encapsulated, and the interface objects contain function interfaces for the other party to directly call, which are as follows:
[0025] For the interface objects provided by the master application, the slave application is provided with function interfaces including obtaining current user information and user function permissions, as well as other function interfaces directly accessible to the slave application based on business needs;
[0026] For the interface object provided by the slave application, the application deactivation and application uninstallation function interfaces are provided to the main application, so that the main application can inform the slave application as needed whether to temporarily store the current status data for backup or whether the main application needs to disconnect from the slave application and recycle the allocated resources. Among them, the interface object provides other function interfaces that can be directly accessed by the main application according to business needs.
[0027] Preferably, after the master application successfully loads the slave application instance, a connection is established between the master application and the slave application through a handshake as follows:
[0028] The slave application prepares to send a handshake message to the master application: In the micro-frontend architecture, the slave application is connected by the master application. When the slave application starts its life cycle, the master application is already active, ensuring that the handshake message can be effectively signed when it arrives at the recipient. In addition, a major application scenario for communication between master and slave applications is that the slave application needs to obtain context data of user information and authentication information from the master application during initialization, so the handshake message is initiated by the slave application. The slave application prepares to send a handshake message to the master application, including creating a Promise instance and listening to the handshake response message of the master application. The role of the Promise instance is to converge the sending and listening processes together after successfully receiving the handshake response message of the master application, so as to return the interface object of the master application to the slave application context, thereby processing the business process in a sequential manner.
[0029] The master application prepares to receive handshake messages: The master application's preparation includes creating a Promise instance and listening to handshake messages from the slave application. It also creates a Promise instance to converge the listening process after receiving the handshake message.
[0030] Send a handshake message from the application to the master application: send the predefined handshake message message structure to the master application and wait for the handshake response message from the master application;
[0031] The master application sends a handshake response message to the slave application: After receiving the handshake message from the slave application, the master application sends a handshake response message to the slave application, stores the information and status record of the slave application instance, and then returns the interface object provided by the slave application to the master application context;
[0032] After the slave application receives the response message from the master application, it returns the master application interface object to the slave application context through the fulfilled state of the Promise instance.
[0033] Preferably, the bidirectional communication transmission between the master application and the slave application is as follows:
[0034] Implement context function interface access: including calling the function interface provided by the main application from the application;
[0035] Communication from the slave application to the main application: access the functions in the interface object provided by the main application. For example, when the slave application is loaded and initialized, it is necessary to obtain the token of the currently logged-in user to access the service interface and the business modules that the current user can access from the main application. After obtaining the returned results from the application, further process the subsequent business logic;
[0036] The master application communicates with the slave application by directly accessing the functions in the interface object provided by the slave application, such as obtaining the current activity information and status data of the slave application, which is used to control the routing access and status switching between the slave applications under the micro-frontend framework.
[0037] Preferably, the slave application calls the function interface provided by the master application as follows:
[0038] The slave application calls the function interface provided by the master application interface object, and sends a message with a "function request" type identifier to the master application. The message sent also carries a unique identifier for identification and verification when a response result needs to be received;
[0039] After the main application receives a message of the corresponding "function request" type, it first verifies the message according to the defined verification rules;
[0040] After the verification is passed, the main application further verifies whether the function interface exists:
[0041] If it exists, the corresponding function processing logic is executed;
[0042] If the corresponding function is defined as not needing to return a result, the corresponding interface call ends;
[0043] Otherwise, the master application should send a "function response" type message to the slave application with the result status or result data, together with the message unique identifier in the request message;
[0044] If the slave application needs to pay attention to the function execution result, the slave application needs to listen to the "function response" type message sent by the master application. The process of the slave application executing the function interface and waiting for the execution result is an asynchronous request response process, which is performed in the Promise instance. The final execution result of the function is the response result returned in the fulfilled state of the Promise instance.
[0045] An electronic device comprising: a memory and at least one processor;
[0046] Wherein, the memory stores a computer program;
[0047] The at least one processor executes the computer program stored in the memory, so that the at least one processor executes the communication method between the micro-frontend master and slave applications as described above.
[0048] A computer-readable storage medium having a computer program stored therein, wherein the computer program can be executed by a processor to implement the communication method between micro-frontend master and slave applications as described above.
[0049] The communication method between micro-frontend master and slave applications, electronic device and storage medium of the present invention have the following advantages:
[0050] (1) The present invention can securely perform two-way communication between cross-domain micro-frontend master and slave applications to obtain response results; the micro-frontend framework implemented by the present invention can achieve the effect of sequentially executing asynchronous operations by accessing the interface objects returned by the master and slave applications, avoiding the separation of processing logic in the direct use of the native API monitoring mode, thereby more elegantly realizing the integrated operation between the master and slave applications;
[0051] (II) The present invention is based on the Web native postMessage API and Promise standard object. When the slave application is loaded and initialized, a handshake request is sent to the master application. After receiving the handshake request, the master application saves the sub-application information record and sends a handshake response to the slave application. After the slave application receives the handshake reply, the two parties establish a communication connection. After the communication connection is established, the master application and the slave application respectively obtain the context interface object provided by the other party. The function interface in the context interface object converges the processing process of the interface request and response through the Promise instance, so that the requesting party executes the calling logic of the asynchronous interface sequentially. The master and slave applications conveniently and safely implement two-way communication transmission between the master application and the slave application by accessing the function interface of the other party, and realize a consistent interface access method under the micro-frontend framework. The master and slave applications can process business processes sequentially.
[0052] (III) The present invention defines a special message structure, including message type, message format, message identifier, and message data. After the master and slave applications receive the message, communication security logic verification is performed based on this structure.
[0053] (iv) The master-slave application of the present invention communicates through an interface object obtained after the two parties establish a connection, and the two parties exchange data by accessing the function interface in the object, thereby realizing two-way communication between the two parties;
[0054] (V) The master-slave application of the present invention accesses the asynchronous interface sequentially, thereby avoiding the fragmented processing of the corresponding business logic in the dispatch monitoring mode. BRIEF DESCRIPTION OF THE DRAWINGS
[0055] The present invention is further described below in conjunction with the accompanying drawings.
[0056] Attached Figure 1 It is a schematic diagram of the structure of a message message;
[0057] Attached Figure 2 Schematic diagram of the process of establishing a connection between the master and slave applications;
[0058] Attached Figure 3 This is a schematic diagram of the interface access process;
[0059] Attached Figure 4 A schematic diagram of establishing communication and exchanging data between micro-frontend master and slave applications. DETAILED DESCRIPTION
[0060] The communication method between the micro-frontend master and slave applications, the electronic device and the storage medium of the present invention are described in detail below with reference to the drawings and specific embodiments of the specification.
[0061] Embodiment 1:
[0062] As attached Figure 4 As shown, this embodiment provides a communication method between a micro-frontend master and slave application. The method is based on the Web native API and the Promise standard object. By implementing a communication model including handshake, information verification, two-way communication, and connection termination between the master application and the slave application, secure communication between the master and slave applications under the micro-frontend architecture is achieved; the details are as follows:
[0063] S1. Define the message structure for communication between the two parties as the basis for communication between the master and slave applications;
[0064] S2. Define verification rules for communication messages: verify the message data received by the master and slave applications to ensure communication security between the master and slave applications;
[0065] S3, respectively encapsulate the interface objects provided by the master application and the slave application to each other, wherein the interface objects contain function interfaces for direct calls by the other party;
[0066] S4. After the master application successfully loads the slave application instance, a connection is established between the master application and the slave application through a handshake to ensure normal communication between the master application and the slave application.
[0067] S5, two-way communication transmission between the master application and the slave application;
[0068] S6. When the user's access to the slave application ends, the master application disconnects the communication connection with the slave application, uninstalls the slave application in the micro-frontend framework, and reclaims the allocated resources.
[0069] The function interface in step S3 of this embodiment is divided into a request type function interface and a notification type function interface; among which, the calling method of the request type function obtains the response data after the function is processed.
[0070] As attached Figure 1 As shown in the figure, the message structure of the communication between the two parties is as follows:
[0071] ①Message type: used to specify the purpose and function of this communication;
[0072] ② Message format: specify a special message format identifier for the communication model to distinguish whether it is receivable message data;
[0073] ③Message ID: A unique ID assigned to a complete communication, used to define the same request and response message data;
[0074] ④Message data: specific business data carried by the communication between two parties.
[0075] The verification rules in step S2 of this embodiment are as follows:
[0076] ① Check the Origin parameter of the native API to verify whether the message source is legal;
[0077] ② Verify whether the message has a message body;
[0078] ③Verify whether the format of the message is legal;
[0079] ④Verify whether the message has a type field and whether the type is legal;
[0080] ⑤For the response message data, verify whether it comes from the same request.
[0081] In step S3 of this embodiment, the interface objects provided by the master application and the slave application to each other are respectively encapsulated, and the interface objects contain function interfaces for the other party to directly call, as follows:
[0082] S301. For the interface object provided by the master application, provide the slave application with a function interface for obtaining current user information and user function permissions, as well as other function interfaces that can be directly accessed by the slave application and are provided according to business needs;
[0083] S302. For the interface object provided by the slave application, an application deactivation and application uninstallation function interface is provided to the master application, so that the master application can inform the slave application as needed whether to temporarily store the current status data for backup or whether the master application needs to disconnect from the slave application and reclaim the allocated resources; wherein the interface object provides other function interfaces that can be directly accessed by the master application according to business needs.
[0084] In step S4 of this embodiment, when the master application successfully loads the slave application instance, the master application and the slave application create a connection through handshake as follows:
[0085] S401, the slave application prepares to send a handshake message to the master application: under the micro-frontend architecture, the slave application is accessed by the master application. When the slave application starts its life cycle, the master application is already in an active state, ensuring that the handshake message can be effectively signed when it arrives at the recipient; in addition, a major application scenario for communication between master and slave applications is that the slave application needs to obtain context data of user information and authentication information from the master application during initialization, so the handshake message is initiated by the slave application; the slave application prepares to send a handshake message to the master application, including creating a Promise instance and listening to the handshake response message of the master application. The role of the Promise instance is to converge the sending and listening processes together after successfully receiving the handshake response message of the master application, so as to return the interface object of the master application to the slave application context, thereby processing the business process in a sequential manner;
[0086] S402, the master application prepares to receive the handshake message: the preparation work of the master application includes creating a Promise instance and monitoring the handshake message from the slave application, and creating a Promise instance for converging the monitoring process after receiving the handshake message;
[0087] S403, the slave application sends a handshake message to the master application: sends a predefined handshake message message structure to the master application, and waits for a handshake response message from the master application;
[0088] S404, the master application sends a handshake response message to the slave application: after receiving the handshake message from the slave application, the master application sends a handshake response message to the slave application, stores the information and status record of the slave application instance, and then returns the interface object provided by the slave application to the master application context;
[0089] S405: After receiving the response message from the master application, the slave application returns the master application interface object to the slave application context through the fulfilled state of the Promise instance. At this point, the communication connection between the master and slave applications is successfully established. For a schematic diagram of the handshake connection creation process, see the attached Figure 2 .
[0090] The bidirectional communication transmission between the master application and the slave application in step S5 of this embodiment is specifically as follows:
[0091] S501, implementing context function interface access: including calling the function interface provided by the main application from the application;
[0092] S502, communication from the application to the main application: accessing the functions in the interface object provided by the main application. For example, when the application is loaded and initialized, it is necessary to obtain the token of the currently logged-in user to access the service interface and the business modules that the current user can access from the main application. After obtaining the returned result from the application, further processing of subsequent business logic is performed;
[0093] S503, the master application communicates with the slave application: directly accesses the functions in the interface object provided by the slave application, such as obtaining the current activity information and status data of the slave application, etc., which is used to control the routing access and status switching operations between the slave applications under the micro-frontend framework.
[0094] In step S501 of this embodiment, the slave application calls the function interface provided by the master application as follows:
[0095] ① The slave application calls the function interface provided by the main application interface object, and sends a message with the "function request" type identifier to the main application. The message sent also carries a unique identifier for identification and verification when a response result needs to be received;
[0096] ②After the main application receives the message of the corresponding "function request" type, it first verifies the message according to the defined verification rules;
[0097] ③After the verification is passed, the main application further verifies whether the function interface exists:
[0098] If it exists, the corresponding function processing logic is executed;
[0099] If the corresponding function is defined as not needing to return a result, the corresponding interface call ends;
[0100] Otherwise, the master application should send a "function response" type message to the slave application with the result status or result data, together with the message unique identifier in the request message;
[0101] ④ If the slave application needs to pay attention to the function execution result, the slave application needs to listen to the "function response" type message sent by the master application. The process of the slave application executing the function interface and waiting for the execution result is an asynchronous request response process, which is performed in the Promise instance. The final execution result of the function is the response result returned in the fulfilled state of the Promise instance. The entire calling process of the function interface is shown in the attached Figure 3 .
[0102] Embodiment 2:
[0103] This embodiment also provides an electronic device, including: a memory and a processor;
[0104] Wherein, the memory stores computer-executable instructions;
[0105] The processor executes the computer-executable instructions stored in the memory, so that the processor executes the communication method between the micro-front-end master and slave applications in any embodiment of the present invention.
[0106] The processor may be a central processing unit (CPU), or other general-purpose processors, digital signal processors (DSP), application-specific integrated circuits (ASIC), field-programmable gate arrays (FPGA) or other programmable logic devices, discrete gate or transistor logic devices, discrete hardware components, etc. The processor may be a microprocessor or any conventional processor, etc.
[0107] The memory can be used to store computer programs and / or modules. The processor realizes various functions of the electronic device by running or executing the computer programs and / or modules stored in the memory, and calling the data stored in the memory. The memory can mainly include a program storage area and a data storage area, wherein the program storage area can store an operating system, at least one application required for a function, etc.; the data storage area can store data created according to the use of the terminal, etc. In addition, the memory can also include a high-speed random access memory, and can also include a non-volatile memory, such as a hard disk, a memory, a plug-in hard disk, a smart memory card (SMC), a secure digital (SD) card, a flash memory card, at least one disk storage period, a flash memory device, or other volatile solid-state storage devices.
[0108] Embodiment 3:
[0109] This embodiment also provides a computer-readable storage medium, in which a plurality of instructions are stored, and the instructions are loaded by a processor, so that the processor executes the communication method between the micro-frontend master and slave applications in any embodiment of the present invention. Specifically, a system or device equipped with a storage medium can be provided, on which a software program code that implements the functions of any of the above embodiments is stored, and a computer (or CPU or MPU) of the system or device reads and executes the program code stored in the storage medium.
[0110] In this case, the program code itself read from the storage medium can realize the function of any one of the above-mentioned embodiments, and thus the program code and the storage medium storing the program code constitute a part of the present invention.
[0111] The storage medium embodiments for providing the program code include a floppy disk, a hard disk, a magneto-optical disk, an optical disk (such as CD-ROM, CD-R, CD-RW, DVD-ROM, DVD-RYM, DVD-RW, DVD+RW), a magnetic tape, a non-volatile memory card, and a ROM. Alternatively, the program code can be downloaded from a server computer via a communication network.
[0112] In addition, it should be clear that the functions of any of the above embodiments can be implemented not only by executing the program code read by the computer, but also by enabling an operating system operating on the computer to complete part or all of the actual operations based on instructions from the program code.
[0113] In addition, it can be understood that the program code read from the storage medium is written to a memory provided in an expansion board inserted into the computer or to a memory provided in an expansion unit connected to the computer, and then based on the instructions of the program code, a CPU installed on the expansion board or the expansion unit is enabled to perform part or all of the actual operations, thereby realizing the functions of any of the above-mentioned embodiments.
[0114] Finally, it should be noted that the above embodiments are only used to illustrate the technical solutions of the present invention, rather than to limit it. Although the present invention has been described in detail with reference to the aforementioned embodiments, those skilled in the art should understand that they can still modify the technical solutions described in the aforementioned embodiments, or replace some or all of the technical features therein by equivalents. However, these modifications or replacements 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 communication method between micro-frontend master and slave applications, characterized in that: This method is based on the Web native API and the Promise standard object. By implementing a communication model between the master application and the slave application that includes handshake, information verification, two-way communication, and connection termination, it achieves secure communication between the master and slave applications under the micro-frontend architecture. The details are as follows: Define the message structure for communication between the two parties as the basis for communication between the master and slave applications; Define verification rules for communication messages: Verify the message data received by the master and slave applications to ensure communication security between the master and slave applications; The interface objects provided by the master application and the slave application to each other are respectively encapsulated, and the interface objects contain function interfaces for direct calls by the other party; When the master application successfully loads the slave application instance, a connection is created between the master application and the slave application through handshake to ensure normal communication between the master application and the slave application. Two-way communication transmission between master application and slave application; When the user ends access to the slave application, the master application disconnects the communication connection with the slave application, uninstalls the slave application within the micro-frontend framework, and reclaims the allocated resources.
2. The communication method between micro-frontend master and slave applications according to claim 1, characterized in that: The function interface is divided into a request function interface and a notification function interface; among them, the calling method of the request function obtains the response data after the function is processed.
3. The communication method between micro-frontend master and slave applications according to claim 1, characterized in that: The message structure of the communication between the two parties is as follows: Message type: used to specify the purpose and function of this communication; Message format: specifies a special message format identifier for the communication model to distinguish whether it is receivable message data; Message ID: A unique ID assigned to a complete communication, used to define the same request and response message data; Message data: specific business data carried by the communication between two parties.
4. The communication method between micro-frontend master and slave applications according to claim 1, characterized in that: The validation rules are as follows: Check the Origin parameter of the native API to verify whether the message source is legitimate; Verify whether the message has a message body; Verify whether the format of the message is legal; Verify whether the message has a type field and whether the type is legal; For the response message data, verify whether it comes from the same request.
5. The communication method between micro-frontend master and slave applications according to claim 1, characterized in that: The interface objects provided by the master application and the slave application to each other are encapsulated respectively. The interface objects contain the function interfaces for the other party to call directly as follows: For the interface objects provided by the master application, the slave application is provided with function interfaces including obtaining current user information and user function permissions, as well as other function interfaces directly accessible to the slave application based on business needs; For the interface object provided by the slave application, the application deactivation and application uninstallation function interfaces are provided to the main application, so that the main application can inform the slave application as needed whether to temporarily store the current status data for backup or whether the main application needs to disconnect from the slave application and recycle the allocated resources. Among them, the interface object provides other function interfaces that can be directly accessed by the main application according to business needs.
6. The communication method between micro-frontend master and slave applications according to claim 1, characterized in that: When the master application successfully loads the slave application instance, the master application and the slave application create a connection through a handshake as follows: The slave application prepares to send a handshake message to the master application: In the micro-frontend architecture, the slave application is connected by the master application. When the slave application starts its life cycle, the master application is already active, ensuring that the handshake message can be effectively signed when it arrives at the recipient. In addition, a major application scenario for communication between master and slave applications is that the slave application needs to obtain context data of user information and authentication information from the master application during initialization, so the handshake message is initiated by the slave application. The slave application prepares to send a handshake message to the master application, including creating a Promise instance and listening to the handshake response message of the master application. The role of the Promise instance is to converge the sending and listening processes together after successfully receiving the handshake response message of the master application, so as to return the interface object of the master application to the slave application context, thereby processing the business process in a sequential manner. The master application prepares to receive handshake messages: The master application's preparation includes creating a Promise instance and listening to handshake messages from the slave application. It also creates a Promise instance to converge the listening process after receiving the handshake message. Send a handshake message from the application to the master application: send the predefined handshake message message structure to the master application and wait for the handshake response message from the master application; The master application sends a handshake response message to the slave application: After receiving the handshake message from the slave application, the master application sends a handshake response message to the slave application, stores the information and status record of the slave application instance, and then returns the interface object provided by the slave application to the master application context; After the slave application receives the response message from the master application, it returns the master application interface object to the slave application context through the fulfilled state of the Promise instance.
7. The communication method between micro-frontend master and slave applications according to any one of claims 1 to 6, characterized in that: The bidirectional communication transmission between the master application and the slave application is as follows: Implement context function interface access: including calling the function interface provided by the main application from the application; Communication from the application to the main application: access the functions in the interface object provided by the main application, obtain the returned results from the application, and further process the subsequent business logic; The master application communicates with the slave application by directly accessing the functions in the interface object provided by the slave application.
8. The communication method between micro-frontend master and slave applications according to claim 7, characterized in that: The function interface provided by the main application is called from the application as follows: The slave application calls the function interface provided by the master application interface object, and sends a message with the "function request" type identifier to the master application. The message sent also carries a unique identifier for identification and verification when a response result needs to be received; After the main application receives a message of the corresponding "function request" type, it first verifies the message according to the defined verification rules; After the verification is passed, the main application further verifies whether the function interface exists: If it exists, the corresponding function processing logic is executed; If the corresponding function is defined as not needing to return a result, the corresponding interface call ends; Otherwise, the master application should send a "function response" type message to the slave application with the result status or result data, together with the message unique identifier in the request message; If the slave application needs to pay attention to the function execution result, the slave application needs to listen to the "function response" type message sent by the master application. The process of the slave application executing the function interface and waiting for the execution result is an asynchronous request response process, which is performed in the Promise instance. The final execution result of the function is the response result returned in the fulfilled state of the Promise instance.
9. An electronic device, characterized in that: include: memory and at least one processor; Wherein, the memory stores a computer program; The at least one processor executes the computer program stored in the memory, so that the at least one processor executes the communication method between the micro-frontend master-slave applications as described in any one of claims 1 to 8.
10. A computer-readable storage medium, characterized in that: The computer-readable storage medium stores a computer program, which can be executed by a processor to implement the communication method between the micro-frontend master and slave applications as described in any one of claims 1 to 8.