Business processing method, electronic equipment and computer readable storage medium

Abstract

The invention relates to the technical field of micro front ends, and provides a service processing method, electronic equipment and a computer readable storage medium. The method is applied to a business system, the business system comprises a client and a server, the client comprises a front-end main application and a plurality of front-end sub-applications, the server comprises a back-end service, and the back-end service provides services for the plurality of front-end sub-applications. In the method, when a control of a front-end sub-application is triggered, a front-end sub-application delegates a front-end main application to send a request to a server so as to request corresponding service data. As the back-end service in the micro-front-end architecture of the service system is not decoupled, when the Web application of a single architecture is migrated by the micro-front-end architecture corresponding to the service system, only the front-end resource of the Web application needs to be decoupled and transformed into a plurality of front-end sub-applications, and the back-end service of the Web application does not need to be decoupled. Therefore, the progressive migration of the Web application from the single architecture to the micro-front-end architecture can be realized.

Description

Technical Field

[0001] The present application relates to the field of micro-front-end technology, and in particular to a business processing method, an electronic device, and a computer-readable storage medium. Background Art

[0002] As functionality increases, the code size of monolithic web applications increases. Due to the high degree of code coupling in monolithic web applications, the development, deployment, and maintenance efficiency of monolithic web applications with large code sizes is low.

[0003] To improve the development, deployment, and maintenance efficiency of monolithic web applications, you can migrate them to micro-frontend architectures. This involves transforming each business module in the monolithic web application into independent sub-applications, thus decoupling the monolithic web application. Because these independent sub-applications can be independently developed, deployed, and maintained, migrating monolithic web applications to micro-frontend architectures can improve the efficiency of web application development, deployment, and maintenance.

[0004] However, when migrating a Web application from a monolithic architecture to a micro-frontend architecture, existing technologies can only perform a one-time leapfrog migration, and cannot perform a gradual migration. The workload is large and the migration cost is high. Summary of the Invention

[0005] Some embodiments of the present application provide a business processing method, an electronic device, and a computer-readable storage medium. The present application is introduced below from multiple aspects, and the implementation methods and beneficial effects of the following multiple aspects can be referenced to each other.

[0006] In a first aspect, the present application provides a business processing method, which is applied to a business system, wherein the business system includes a client and a server, wherein the client includes a front-end main application and multiple front-end sub-applications, and the server includes a back-end service, and the back-end service provides services for multiple front-end sub-applications, wherein the front-end main application and the front-end sub-applications belong to different domains, and the front-end main application and the back-end service belong to the same domain; and the method includes: The client displays a first interface, which includes controls of multiple front-end sub-applications, including a first front-end sub-application; the client detects a trigger event of a first control of the first front-end sub-application in the first interface; the client sends a first request for the first front-end sub-application to a back-end service of the server, wherein the first request is used to request first business data; the back-end service sends the first business data to the client; wherein the client sends the first request for the first front-end sub-application to the back-end service of the server, including: the first front-end sub-application sends a first parameter to the front-end main application; the front-end main application generates a first request based on the first parameter; and the front-end main application sends the first request to the back-end service.

[0007] Since the front-end sub-application and the back-end service do not belong to the same domain, the front-end sub-application cannot send cross-domain requests directly to the back-end service. Therefore, when the control of the current sub-application is triggered, the front-end sub-application can delegate the front-end main application to send a request to the server to request the corresponding business data to implement the corresponding business. Since the back-end service is not decoupled in the micro-front-end architecture of the business system, when migrating a monolithic Web application to the corresponding micro-front-end architecture of the business system, it is only necessary to decouple its front-end resources and transform its front-end resources into multiple front-end sub-applications without decoupling the back-end services of the Web application. In this way, the gradual migration of Web applications from a monolithic architecture to a micro-front-end architecture can be achieved.

[0008] In some embodiments, the first request includes a first identifier, which is generated based on interface parameters of a first interface. The first interface is the interface called when the front-end main application sends the first request, and the interface parameters include the interface name.

[0009] When the front-end main application generates the first request, it can use the national secret digest algorithm to perform a hash calculation on the interface parameters (such as the interface name and other parameters) of the interface (the first interface) called when the front-end main application sends the actual request. This generates a fixed-length digest value as the requestID (the first identifier) ​​and marks the first request with the requestID. This allows the first request to be identified by the requestID, preventing errors in sending and responding to the first request.

[0010] In some embodiments, the first parameter includes at least one of the following: a parameter for indicating the type of the first business data, a parameter for indicating the length of the first business data, and a parameter for indicating the format of the first business data.

[0011] In some implementations, the first front-end sub-application sending the first parameter to the front-end main application includes: the first front-end sub-application sending the first parameter to the front-end main application through a first data channel, where the first data channel includes a PostMessage channel.

[0012] The front-end main application and the first front-end sub-application belong to different domains, meaning they use different network protocols, port numbers, and domain names. In this case, when a web browser runs the front-end main application and the first front-end sub-application, the web browser's same-origin policy restricts resource access between the front-end main application and the first front-end sub-application, preventing direct communication between the two.

[0013] The PostMessage mechanism is a cross-domain communication mechanism. Applications in different domains can use the window.postMessage() method provided by this mechanism to send data to each other through the PostMessage channel, thus overcoming the cross-domain communication restrictions of the same-origin policy. For example, a main application and a sub-application in different domains can communicate by sending data to each other through the window.postMessage() method. Thus, a main front-end application can send a message to a sub-front-end application through the PostMessage channel.

[0014] In some implementations, the first path corresponding to the front-end main application and the second path corresponding to the first front-end sub-application are different absolute paths.

[0015] For example, the first path corresponding to the front-end main application is "www.aaa.xxx", and the second path corresponding to the first front-end sub-application is "www.bbb / yewu1.xxx".

[0016] In some embodiments, the method further includes: the client creating a first container for displaying an interface corresponding to the first front-end sub-application before receiving the first business data; and after receiving the first business data, the client displaying a second interface corresponding to the first business data in the first container.

[0017] The first container may be the frame container mentioned in this application.

[0018] A frame container is an independent window used to securely load remote resources (not on the same domain). This overcomes the cross-domain resource loading restrictions of the same-origin policy. Under the cross-domain restrictions of the same-origin policy, the front-end main application can load front-end sub-applications that are not on the same domain through an iframe container.

[0019] Because the first front-end sub-application and the front-end main application belong to different domains, the front-end main application cannot directly load the front-end sub-application. In this case, the front-end main application can load the first front-end sub-application through an iframe container.

[0020] In some embodiments, the first container has a second identifier corresponding to the first front-end sub-application, and after the client receives the first business data, the second interface corresponding to the first business data is displayed in the first container, including: determining the first container corresponding to the first business data based on the second identifier; and displaying the second interface in the first container.

[0021] In some embodiments, when the client creates an iframe container for the first front-end sub-application, it can add an iframeID (as a second identifier) ​​to the iframe container, so that the client can identify the corresponding iframe container through the iframeID, thereby avoiding mismatch of the iframe container loaded by the first front-end sub-application.

[0022] In other embodiments, the client may generate a random number according to a random function, then combine the path corresponding to the first control with the random number, and use the combined result as the iframeID of the iframe container that loads the first front-end sub-application.

[0023] In a first aspect, the present application provides a business processing method, which is applied to a system including a front-end device and a back-end device, wherein a client runs on the front-end device, and a server, a front-end main application, and multiple front-end sub-applications are deployed on the back-end device. The server includes a back-end service, and the back-end service provides services for multiple front-end sub-applications, wherein the front-end main application and the back-end service on the back-end device belong to the same domain, and the front-end sub-application on the back-end device belongs to a different domain from the front-end main application. And, the method includes: The front-end device obtains the front-end main application and multiple front-end sub-applications from the back-end device, and displays a first interface, wherein the first interface includes controls for each front-end sub-application; The front-end device detects a triggering event of a first control in the first interface, wherein the first control is a control corresponding to a first front-end sub-application among the plurality of front-end sub-applications; The front-end device sends a first request of the first front-end sub-application to the back-end service of the back-end device, wherein the first request is used to request first service data; The backend service sends the first business data to the frontend device; The front-end device sends a first request of the first front-end sub-application to the back-end service of the back-end device, including: The front-end device sends the first parameter to the front-end main application through the first front-end sub-application; The front-end device generates a first request based on the first parameter through the front-end main application; The front-end device sends the first request to the back-end service of the back-end device through the front-end main application.

[0024] In some embodiments, the backend device includes a first backend device, and the frontend main application, the frontend sub-application, and the backend service are deployed on the first backend device.

[0025] The front-end main application, front-end sub-application, and back-end service in the client are deployed on the same back-end device, that is, deployed in the same domain.

[0026] In some embodiments, the backend device includes a second backend device and at least one third backend device, the frontend main application and backend services are deployed on the second backend device, and at least part of the frontend sub-applications are deployed on at least one third backend device.

[0027] The multiple front-end sub-applications in the client can be partially deployed on the second back-end device, partially deployed on at least one third back-end device, or all deployed on the at least one third back-end device. For example, the number of third back-end devices is greater than or equal to the number of front-end sub-applications. Each front-end sub-application is deployed on a different third back-end device.

[0028] In a third aspect, embodiments of the present application provide an electronic device, comprising: a memory for storing instructions executed by one or more processors of the electronic device; and a processor, which, when executing the instructions in the memory, causes the electronic device to perform the method described in the first aspect of the present application. The beneficial effects achieved in the third aspect can be referenced to the beneficial effects of the method provided in any embodiment of the first aspect and are not further elaborated here.

[0029] In a fourth aspect, embodiments of the present application provide a computer-readable storage medium having instructions stored thereon. When executed on a computer, the instructions cause the computer to perform the method described in any embodiment of the first aspect. The beneficial effects achieved in the fourth aspect can be referenced to the beneficial effects of the method described in any embodiment of the first aspect and are not further elaborated here.

[0030] In a fifth aspect, embodiments of the present application provide a computer program product, comprising computer program code. When the computer program code is executed on a computer, the computer implements the method described in any embodiment of the first aspect. The beneficial effects achieved in the fifth aspect can be referenced to the beneficial effects of the method provided in any embodiment of the first aspect and are not further elaborated here. BRIEF DESCRIPTION OF THE DRAWINGS

[0031] Figure 1 A schematic diagram of the structure of a single structure provided in an embodiment of the present application; Figure 2 A schematic diagram of a micro front-end structure provided in an embodiment of the present application; Figure 3 An interaction diagram between the front-end and the back-end provided in an embodiment of the present application; Figure 4A A schematic diagram of a front-end loading service management application provided in an embodiment of the present application; Figure 4B A schematic diagram of a page corresponding to a front-end display service 1 provided in an embodiment of the present application; Figure 5 A schematic diagram of migrating a business management application from a monolithic architecture to a micro-frontend architecture provided in an embodiment of the present application; Figure 6A An interaction diagram of a business management application provided in an embodiment of the present application; Figure 6B A front-end interface diagram of a business management application provided in an embodiment of the present application that is migrated from a monolithic architecture to a micro-front-end architecture; Figure 7A A flowchart of a sub-application loading provided in an embodiment of the present application; Figure 7B A scenario diagram for requesting business data provided in an embodiment of the present application; Figure 8 A schematic diagram of another business management application migration from a monolithic architecture to a micro-frontend architecture provided in an embodiment of the present application; Figure 9A A flowchart of another sub-application loading provided in an embodiment of the present application; Figure 9B A scene diagram for displaying a sub-application page provided in an embodiment of the present application; Figure 10 A schematic diagram of a decoupled backend service provided in an embodiment of the present application; Figure 11 A schematic diagram of another micro-frontend architecture provided in an embodiment of the present application; Figure 12 An interaction diagram of another business management application provided in an embodiment of the present application; Figure 13 A flowchart of a client displaying a sub-application page provided in an embodiment of the present application; Figure 14 An interaction diagram of another business management application provided in an embodiment of the present application; Figure 15 An interaction diagram of another business management application provided in an embodiment of the present application; Figure 16 An interaction diagram of a front-end sub-application, a front-end main application, and a back-end service provided in an embodiment of the present application; Figure 17 A flowchart of a business processing method provided in an embodiment of the present application; Figure 18 A scene diagram of front-end interaction provided in an embodiment of the present application; Figure 19 Another front-end interaction scene diagram provided in an embodiment of the present application; Figure 20 A schematic diagram of the structure of an electronic device provided in an embodiment of the present application. DETAILED DESCRIPTION

[0032] The embodiment of the present application is used to provide a service processing method. The service processing method provided by the embodiment of the present application is introduced below in conjunction with specific embodiments.

[0033] For ease of understanding, the terms involved in this application are explained below.

[0034] (1) Web applications A web application is a computer program stored on a remote server and run by its user through a web browser. It can provide a variety of functions, such as online shopping applications, social networking applications, enterprise resource management applications, business management applications, etc. Web applications consist of two parts: the front-end and the back-end.

[0035] The front-end, or client-side, is the part of a web application that users directly see and interact with. It focuses on aspects such as the user interface design, layout, interaction logic, and user experience. Front-end developers are typically responsible for building the content that users see, including page layout, colors, fonts, buttons, and other elements, as well as the interaction logic that responds to user actions.

[0036] The backend, or server-side, is the part of a web application that handles server-side logic, including data processing, business logic, database interaction, etc. Backend developers are typically responsible for building and maintaining the server, application logic, and interaction with the database.

[0037] It should be noted that the front-end portion of a web application can run on a front-end device, and the back-end portion of a web application can run on a back-end device. Front-end devices include, but are not limited to, computers, mobile phones, tablets, wearable devices (such as smartwatches, smart bands, virtual reality (VR) and augmented reality (AR) headsets), and in-vehicle devices that run the front-end portion of a web application. Back-end devices include, but are not limited to, servers, computers, and other devices that run the back-end portion of a web application. For ease of description, the following text uses computers as an example of a front-end device and servers as an example of a back-end device.

[0038] (2) Monolithic architecture A monolithic architecture is a traditional software architecture that builds and runs the entire application as a single deployable system. In this architecture, all functional modules and business logic of the application are concentrated in a single code base, interacting and collaborating through internal calls and shared databases.

[0039] Monolithic architectures are suitable for simple and small-scale applications, such as internal management systems and small e-commerce websites. In these scenarios, monolithic architectures can be quickly developed, deployed, and maintained to meet business needs. However, due to the limitations of monolithic architectures, such as limited scalability, high coupling, and poor fault tolerance, as business grows and system scale expands, monolithic architectures may face challenges in scalability and maintainability.

[0040] Figure 1 A schematic diagram of a monolithic architecture is shown.

[0041] As shown in the figure, a monolithic web application (hereinafter referred to as a "monolithic web application") includes front-end resources and back-end services. The front-end resources include multiple functional modules for implementing various services.

[0042] Front-end resources refer to all resources and codes running on a web browser, including hypertext markup language (HTML), cascading style sheets (CSS), JavaScript, etc., which together constitute the appearance, interaction, and logic of the user interface.

[0043] Backend services refer to applications and databases running on the server. They are responsible for processing requests sent by the frontend, executing business logic, storing and retrieving data, and returning results to the frontend.

[0044] In some embodiments, front-end resources and back-end services can communicate and interact using protocols such as the Hypertext Transfer Protocol (HTTP). The front-end sends an HTTP request to the back-end, which then executes the corresponding business logic and data processing and returns the result to the front-end in the form of an HTTP response. Upon receiving the response, the front-end updates the page content or performs other operations based on the response.

[0045] (3) Micro-frontend architecture The micro-frontend architecture is a front-end development model that draws on the concepts of the microservices architecture. It aims to split a large front-end application into multiple independent, flexible small applications (also called micro-frontend modules or sub-applications). Each application can be independently developed, deployed, and maintained, and then these small applications can be integrated into a complete application. By splitting a large application into multiple independent small applications, the micro-frontend architecture can improve the efficiency of application development, deployment, and maintenance.

[0046] Figure 2 Shown is Single-Spa ® ,qiankun ® , Unbounded ® Schematic diagram of micro front-end architecture based on micro front-end technologies such as .

[0047] refer to Figure 2 , Single-Spa ® ,qiankun ® , Unbounded ® A web application using a micro-frontend architecture (hereinafter referred to as a "micro-frontend web application"), which uses micro-frontend technologies, consists of a main application (also called a "micro-frontend base application" or "main frontend application") and multiple sub-applications. The main application includes a directory module. Each sub-application consists of a frontend resource and a backend service.

[0048] Among them, the main application is mainly responsible for loading, unloading and managing each sub-application.

[0049] The catalog module is used to manage the paths of the main application and each sub-application. For example, when the catalog module detects that a control is triggered, it can load the corresponding application based on the path corresponding to the control.

[0050] Sub-applications are used to handle various types of business.

[0051] It can be understood that the front-end resources of the sub-application run on the front-end device, and the back-end services of the sub-application run on the back-end device.

[0052] It should be noted that the micro-frontend Web applications in this application include but are not limited to online shopping applications, social networking applications, enterprise resource management applications, business management applications, etc. The business management application of the micro-frontend architecture is described below as an example of a micro-frontend Web application.

[0053] (4) Same-origin strategy, also known as "same-domain strategy" The same-origin policy is a security policy used by web browsers. To ensure resource loading security, this policy only allows the currently running application to load resources from the same domain (meaning the network protocol, domain name, and port number are the same), and does not allow the currently running application to load resources from different domains. For example, a web browser only allows the currently running main application to load sub-applications from the same domain, and not sub-applications from different domains. Another example is that a web browser only allows the currently running sub-application to load backend services from the same domain, and not backend services from different domains.

[0054] In addition, the same-origin policy does not allow two applications in different domains to communicate directly. For example, if the main application and the sub-application do not belong to the same domain, the main application and the sub-application cannot communicate directly.

[0055] Figure 3 An exemplary application scenario of the present application is shown.

[0056] refer to Figure 3 , a business management application with a monolithic architecture runs on the server 20 (as the backend, also called the server). The business management application includes modules A1, A2, A3, ..., module A n , which are used to implement business 1, business 2, business 3, ..., business n respectively.

[0057] In some embodiments, the computer 10 can access the business management application running on the server 20 via the Internet.

[0058] Specifically, refer to Figure 4A A web browser is installed on computer 10. When computer 10 detects that a user clicks a web browser icon 11 on desktop H1 with a mouse, computer 10 displays a web browser navigation interface M1. Navigation interface M1 includes a navigation bar 15. When computer 10 receives a web browser uniform resource locator (URL), such as "www.aaa.xxx," entered by the user in navigation bar 15 and detects that the user clicks a search button 16 in navigation bar 15 with a mouse, computer 10 can send a request to the server 20 to access the client side of the business management application based on the network address.

[0059] After receiving the request sent by the computer 10, the server 20 returns the response result of the request to the computer 10 (such as Figure 3As shown), for example, hypertext markup language files (HTML), cascading style sheets files (CSS) files, JavaScript files, static resources, application programming interface (API) data, etc. Then, the computer 10 displays the homepage Q1 of the client of the business management application according to the response result returned by the server 20. The homepage Q1 includes a control bar U1 and a main page M2. The main page M2 is the page of the main application. The control bar U1 includes controls P0~Pn, where control P0 is the homepage control of the business management application, and controls P1~Pn are controls for business 1~business n of the business management application respectively.

[0060] As you can understand, HTML files define the basic structure and content of an application page. CSS files define the application page's style, such as color, layout, and fonts. JavaScript files contain client-side script code that handles user interactions and dynamically updates page content. Static resources include image files, font files, and icon files. These resources enrich the application's visuals.

[0061] In some embodiments, when the computer 10 detects that the user clicks a certain control with a mouse, the computer 10 can call the corresponding API through the business management application and send a request to the server 20 according to the URL corresponding to the control to request the corresponding business data.

[0062] For example, reference Figure 4B When computer 10 detects a mouse click on control P1, it changes the URL in navigation bar 15 from "www.aaa.xxx" to the URL corresponding to control P1, "www.aaa / yewu1.xxx." Then, through the business management application, it calls the corresponding API to request the data of business 1 from the backend service of server 20 based on the changed URL "www.aaa / yewu1.xxx." After server 20 provides computer 10 with the data of business 1, computer 10 can display page G1 corresponding to business 1.

[0063] In some cases, developers add more functionality to business management applications to meet growing business needs. As the functionality of a business management application grows, it can become a monolithic application. A monolithic application is a large application with tightly coupled functions and a monolithic architecture. Once a business management application becomes a monolithic application, it has a large code base and a high degree of coupling, resulting in low development, deployment, and maintenance efficiency.

[0064] As described in the background, to improve the efficiency of business management application development, maintenance, and deployment, you can migrate business management applications from a monolithic architecture to a micro-frontend architecture. This means splitting the business management application into multiple independent sub-applications. Because these sub-applications are independently developed, deployed, and maintained, this can improve the efficiency of business management application development, deployment, and maintenance.

[0065] In some cases, developers add more functionality to business management applications to meet growing business needs. As the functionality of a business management application grows, it gradually becomes a monolithic application. A monolithic application is a large application with tightly coupled functionality and a monolithic architecture. Once a business management application becomes a monolithic application, it has a large code base and a high degree of coupling, resulting in low development, deployment, and maintenance efficiency.

[0066] In some embodiments, the business management application can be moved from the above Figure 1 The monolithic architecture shown above Figure 2 Migrate to the micro frontend architecture shown.

[0067] Specifically, refer to Figure 5 , the main body of the business management application can be transformed into the main application, and the modules A1~A n Transformed into sub-applications a1~a respectively n For example, the entire front-end resources of the business management application are split into front-end resources b1~b n , and split the entire backend service of the business management application into backend services c1~c n , so that the front-end resources and back-end services of the business management application are decoupled based on different businesses. Among them, sub-application a1 includes front-end resources b1 and back-end service c1, sub-application a2 includes front-end resources b2 and back-end service c2, sub-application a3 includes front-end resources b3 and back-end service c3, ..., sub-application a n Including front-end resources b n and backend service a n . And, they are backend services c1~c n Configure different URLs. In this way, sub-applications a1~a n Front-end resources b1 Front-end resources b1~b n The corresponding backend services can be accessed through their respective URLs, ensuring the independence of each sub-application and allowing each sub-application to run independently.

[0068] For example, the front-end resource b1 of the sub-application a1 can send a request to the back-end service c1 through the URL of the back-end service c1, and then the back-end service c1 returns the corresponding business data to the front-end resource b1 according to the request.

[0069] In some embodiments, to ensure resource access security, some web browsers use the same-origin policy to access external resources. To avoid the cross-domain restrictions of the same-origin policy, when migrating a business management application from a monolithic architecture to a micro-frontend architecture, the main application (including frontend resources) and each sub-application (including frontend resources and backend services) must be deployed in the same domain. This ensures normal communication between the main and sub-applications, the main application can load sub-applications, and the sub-applications can load corresponding backend services.

[0070] In this case, the path corresponding to the sub-application's controls needs to be configured as a relative path (also called a "relative path") rather than an absolute path (also called an "absolute path"). In this case, the domain name of the main application and the sub-application is the same.

[0071] An absolute path refers to the complete path from the root directory of the file system to the target file or directory. It contains the complete path information of the file or directory in the file system and can accurately locate the target file or directory.

[0072] A relative path refers to the path from the current working directory or the specified directory to the target file or directory. It does not contain the root directory information. Instead, it uses the current working directory or the specified directory as the starting point and locates the file or directory through a series of directories and subdirectories.

[0073] For example, refer to Figure 6A ,for Figure 2 In the micro-frontend web application shown, the path corresponding to the control P0 of the main application is configured as the absolute path "www.aaa.xxx". The path corresponding to the control P1 of the sub-application a1 is configured as the relative path " / yewu1". The web browser of computer 10 currently displays the homepage Q1 of the client of the business management application based on the URL "www.aaa.xxx" in the navigation bar 15. When computer 10 detects that a user clicks on control P1 through the directory module of the business management application, the URL in the navigation bar 15 is changed to "www.aaa / yewu1.xxx" based on the absolute path "www.aaa.xxx" and the relative path " / yewu1" corresponding to control P1, and based on the changed URL "www.aaa / yewu1.xxx", the currently displayed main page M2 of the main application is switched to page G1 of sub-application a1. When computer 10 detects that the control P0 is clicked through the directory module of the business management application, the directory module changes the URL in the navigation bar to "www.aaa.xxx" and switches the currently displayed page G1 of sub-application a1 back to the main page M2 of the main application.

[0074] It is understandable that after migrating the business management application from a monolithic architecture to a micro-frontend architecture, the frontend page of the business management application does not change and users are unaware of it. Figure 6B As shown in the figure, after migrating the business management application from a monolithic architecture to a micro-frontend architecture, the interface displayed by the computer 10 is the same as the original interface. In addition, the control P0 in the interface corresponds to the main application, and the controls P1~Pn correspond to the sub-applications a1~a respectively. n .

[0075] Since each sub-application's front-end resources have a corresponding back-end service, sub-applications a1~a n The aforementioned modules A1 to A2 can be implemented by requesting the server 20 to provide corresponding backend services through their respective frontend resources. n Responsible for business 1~n.

[0076] Figure 7A An example diagram of a sub-application loading method provided for some embodiments.

[0077] refer to Figure 7A The business management application includes a client and a server. The client runs on a computer 10 and the server runs on a server 20. The client includes a main application and a sub-application a1. The server includes backend services.

[0078] like Figure 7A As shown, the method includes the following steps: S101: The main application on the computer 10 detects that the user clicks on the control P1 of the sub-application a1.

[0079] refer to Figure 7B The client running on the computer 10 detects through the directory module of the main application that the user clicks the control P1 of the sub-application a1 on the homepage Q1 of the client of the business management application displayed on the computer 10.

[0080] S102: The main application loads the sub-application a1.

[0081] After the client running on the computer 10 detects through the directory module of the main application that the user clicks on the control P1 of the sub-application a1, the client running on the computer 10 loads the sub-application a1 through the directory module of the main application.

[0082] S103 : The sub-application a1 sends a request to the backend service on the server 20 .

[0083] refer to Figure 7B After the sub-application a1 is loaded, the client running on the computer 10 sends a request to the backend service of the server on the server 20 through the sub-application a1.

[0084] S104: The backend service returns the data of business 1 to the sub-application a1.

[0085] refer to Figure 7B After receiving the request sent by the sub-application a1, the back-end service running on the server 20 returns the data of the business 1 to the sub-application a1 according to the request.

[0086] S105: Sub-application a1 displays page G1 of service 1.

[0087] refer to Figure 7B After the sub-application a1 receives the data of the business 1 returned by the back-end service, the client on the computer 10 displays the page G1 of the business 1 through the sub-application a1.

[0088] Understandably, according to Figure 7A and Figure 7B It can be seen that for the above Figure 5 The business management application of the micro-frontend architecture shown in the figure can directly request business data from the backend service through its sub-applications.

[0089] It is understandable that for the above Figure 5 The business management application of the micro front-end architecture shown in the figure has sub-applications a1~a n Both include independent front-end resources and back-end services, which can be independently developed, deployed and maintained, splitting the business management application of the monolithic architecture into independent sub-applications a1~a in the micro-front-end architecture n , which can improve the efficiency of development, deployment and maintenance of business management applications.

[0090] However, when migrating a business management application from a monolithic architecture to a micro-frontend architecture, the migration of the business management application to the micro-frontend architecture can only be completed by decoupling all the front-end resources and back-end services of the business management application at one time. That is, only a one-time leapfrog migration can be performed, and no gradual migration can be performed.

[0091] It is understandable that a one-time leapfrog migration requires decoupling all front-end resources and back-end services at once, which is labor-intensive and has high migration costs. In contrast, a gradual migration does not require decoupling all front-end resources and back-end services at once. Instead, the front-end resources can be decoupled first, and then the back-end services can be decoupled later. Alternatively, the back-end services may not be decoupled at all, which results in less workload, lower migration costs, and greater flexibility.

[0092] Therefore, to address the above-mentioned issues, embodiments of the present application disclose a business processing method. In this method, when migrating a monolithic web application from a monolithic architecture to a micro-frontend architecture, only the monolithic web application's frontend resources can be decoupled, without decoupling the monolithic web application's backend services. Specifically, the monolithic web application's main framework is transformed into a master application, and only the monolithic web application's frontend resources are split into the frontend resources of multiple sub-applications, without splitting the monolithic web application's backend services.

[0093] Understandably, since the main application is derived from the monolithic web application's main framework, it retains the monolithic web application's core resources, such as the original API, and possesses its core functionality, such as requesting backend services to provide corresponding business services. Since the decoupled sub-applications are equivalent to the pre-decoupled functional modules of the monolithic web application, the decoupled sub-applications can share the undecoupled backend services through the main application, thereby implementing the business operations corresponding to the functional modules in the monolithic web application.

[0094] Because each sub-application shares a single, uncoupled backend service with a high degree of code coupling, subsequent development can create significant challenges if developers add new business features to a sub-application directly by developing the shared backend service. Therefore, developers can develop a separate backend service to implement a new business feature, reducing the development effort for the sub-application.

[0095] To facilitate functional adaptation between sub-applications and newly added backend services (for example, adapting the front-end UI to back-end interface data), and to prevent the development of newly added backend services from affecting the normal operation of the original, non-decoupled backend services, it is necessary to deploy the sub-applications and newly added backend services in the same domain, such as on the same server. This facilitates functional adaptation between the sub-applications and newly added backend services and prevents the development of the newly added backend services from affecting the operation of the original, non-decoupled backend services.

[0096] In this case, the original non-decoupled backend service and the newly added backend service will both provide business services for the same sub-application. To avoid confusion, the original non-decoupled backend service and the newly added backend service need to be deployed in different domains. For example, the original non-decoupled backend service and the newly added backend service should be deployed on different servers. This isolates the original non-decoupled backend service from the newly added backend service and prevents them from affecting each other.

[0097] Based on the above reasons, in some embodiments, when migrating a monolithic Web application from a monolithic architecture to a micro-frontend architecture, the frontend resources of the main application and the frontend resources of the sub-application are deployed in different domains.

[0098] Understandably, to facilitate functional adaptation of front-end resources and back-end services, the front-end resources and back-end services of a monolithic web application are typically deployed in the same domain. Because the main application is repurposed from the main body of the monolithic web application, the main application's front-end resources and the monolithic web application's back-end services reside in the same domain. In other words, the main application's front-end resources and the undecoupled back-end services reside in the same domain.

[0099] It is understandable that since the front-end resources of the main application and the front-end resources of the sub-application are not in the same domain, and are subject to the cross-domain restrictions of the aforementioned same-origin policy, for the front-end, the main application cannot directly load the sub-application or communicate directly with the sub-application.

[0100] Based on this, in some embodiments, the main application can load the sub-application through the iframe container and communicate with the sub-application based on the PostMessage mechanism.

[0101] The iframe container is an independent window used to safely load remote resources (not in the same domain). It can solve the cross-domain resource loading restrictions of the same-origin policy. Under the cross-domain restrictions of the same-origin policy, the front-end main application can load the front-end sub-application that is not in the same domain through the iframe container. In addition, using the iframe container to load the sub-application can ensure the consistency of the interaction between the main and sub-applications. The PostMessage mechanism is a cross-domain communication mechanism. Applications in different domains can use the window.postMessage() method provided by this mechanism to send data to each other through the PostMessage channel, thus overcoming the cross-domain communication restrictions of the same-origin policy. For example, a main application and sub-applications in different domains can use the window.postMessage() method to send data to each other to communicate.

[0102] Understandably, the PostMessage mechanism prevents each sub-application from implementing its own set of interaction logic, which would lead to inconsistent user experiences. It also addresses the issue of limited layout within iframe containers (such as style isolation and size restrictions). Global interactive experiences (such as pop-ups and modal boxes) can be implemented uniformly within the main application, providing a unified interface for all sub-applications to call. Furthermore, using the PostMessage mechanism, sub-applications don't need to worry about cross-domain, permission, and other issues. Thus, the request delegation mechanism implemented based on the PostMessage mechanism (sub-applications delegate requests to the main application) not only gives sub-applications flexible front-end module development capabilities, but also fundamentally avoids cross-domain challenges, ensuring seamless consistency between the front-end and back-end docking modes and the main application, significantly reducing the resistance to implementing a micro-frontend architecture.

[0103] Because the sub-application's front-end resources are located in a different domain from the main application's, and the main application's front-end resources are located in the same domain as the undecoupled back-end service, the sub-application's front-end resources are located in a different domain from the undecoupled back-end service. Due to the cross-domain restrictions of the same-origin policy, the sub-application cannot directly request business data from the back-end service.

[0104] Based on this, in some embodiments, the sub-application may delegate the main application to request business data from the undecoupled backend service, rather than directly requesting business data from the undecoupled backend service.

[0105] Specifically, the sub-application can send request parameters indicating the service data (such as the type, quantity, and length of the service data) to the main application. After receiving the request parameters, the main application generates a corresponding request based on the request parameters and sends the request to the corresponding server (such as the server where the non-decoupled backend service is located). The server then responds to the request and returns the corresponding service data to the main application. The main application then returns the service data to the sub-application.

[0106] For example, refer to Figure 8 , the entire front-end resources of the business management application can be split into the front-end resources of multiple sub-applications, such as modules A1~A n The front-end resources are transformed into sub-applications a1~a n Front-end resources b1~b n , but does not split the backend services of the business management application. In addition, the main application and sub-applications a1~a n The front-end resources of the main application are deployed in different domains, and the main application and the unsplit back-end services are deployed in the same domain. In this case, the unsplit back-end services belong to the same domain as the front-end resources of the main application, but not to the sub-applications a1~a n Front-end resources b1~b nDifferent from a domain. At this time, for the front end, sub-applications a1~a n The main application can only be entrusted to request the corresponding business data from the server 20 where the unsplit backend service is located, but cannot directly request the corresponding business data from the server 20.

[0107] Figure 9A This is an example diagram of the sub-application loading method provided in an embodiment of the present application.

[0108] refer to Figure 9A The business management application includes a client and a server, wherein the client runs on a computer 10 and the server runs on a server 20. The client includes a main application and a sub-application a1, wherein the main application includes a directory module. The server includes a backend service. The method includes the following steps: S201: The main application on the computer 10 detects that the user clicks on the control P1 of the sub-application a1.

[0109] refer to Figure 9B The client running on the computer 10 detects through the directory module of the main application that the user clicks the control P1 of the sub-application a1 on the homepage Q1 of the client of the business management application displayed on the computer 10.

[0110] S202: The main application loads the sub-application a1.

[0111] refer to Figure 9B The main application creates an iframe container, window V1, for the sub-application a1 and loads the sub-application a1 in the iframe container.

[0112] S203: The sub-application a1 sends request parameters to the main application.

[0113] refer to Figure 9B , the sub-application a1 can send request parameters for indicating parameters of the data of the service 1 to the main application based on the PostMessage mechanism, such as parameters indicating the type, length, format, etc. of the data of the service 1.

[0114] S204 : The main application sends a request to the backend service on the server 20 .

[0115] refer to Figure 9B After receiving the request parameters sent by the sub-application a1, the main application generates a corresponding request based on the request parameters and sends the request to the backend service on the server 20.

[0116] S205: The backend service returns the data of business 1 to the sub-application a1.

[0117] refer to Figure 9BAfter receiving the request sent by the sub-application a1, the back-end service running on the server 20 returns the data of the business 1 to the sub-application a1 according to the request.

[0118] S206: The main application returns the data of service 1 to the sub-application a1.

[0119] After receiving the data of business 1 returned by the backend service, the main application returns the data to the sub-application a1.

[0120] S207: Sub-application a1 displays page G1 of service 1.

[0121] refer to Figure 9B , sub-application a1 displays page G1 of business 1 in window V1.

[0122] In the embodiment of this application, according to Figure 9A and Figure 9B As you can see, the sub-application doesn't directly request business data from the backend service; instead, it delegates the request to the main application. Furthermore, the main application doesn't load the sub-application directly; instead, it loads the sub-application as a remote resource. Based on this, when migrating a web application from a monolithic architecture to a micro-frontend architecture, you can gradually separate the web application's frontend resources as needed, achieving lightweight migration of the web application.

[0123] In some embodiments, after the front-end resources of the Web application are decoupled, the back-end services of the Web application may also be decoupled.

[0124] For example, refer to Figure 10 , the front-end resources of the business management application are divided into sub-applications a1~a n Front-end resources b1~b n After that, the backend service can be split into sub-applications a1~a n Backend services c1~c n Among them, the main application and sub-applications a1~a n Belong to different domains.

[0125] It can be understood that in this application, the migration of a web application from a monolithic architecture to a micro-frontend architecture includes the following two stages: Phase 1: Decouple only front-end resources without decoupling back-end services.

[0126] Phase 2: Decoupling backend services.

[0127] Because the decoupling of front-end resources is independent of the decoupling of back-end services, Phase 2 is optional. That is, when migrating a monolithic web application to a micro-frontend architecture, Phase 2 can be performed or omitted. This allows for a gradual migration of web applications to a micro-frontend architecture.

[0128] The following introduces the technical solution of this application by taking the execution of both phase one and phase two as an example.

[0129] Figure 11 A schematic diagram of another micro-frontend architecture provided in an embodiment of the present application.

[0130] refer to Figure 11 The architecture includes the sub-application Web layer, the main application Web layer, the sub-application service layer and the sub-service cluster. The sub-application Web layer and the main application Web layer are located at the front end, while the sub-application service layer and the sub-service cluster are located at the back end.

[0131] The sub-application Web layer includes a sub-application user interface (UI) module and a first request processing module.

[0132] The sub-application UI module is used to provide the UI of the sub-application.

[0133] The first request processing module is integrated with a sub-application request forwarding plug-in, which is used to communicate with the second request module of the main application Web layer, such as sending a simulated request (a request that is not actually sent to the server) to the second request processing module and receiving a response from the second processing module.

[0134] The main application web layer includes a directory module (or called a "tab directory module"), its own routing, a remote container module, and a second request processing module.

[0135] The directory module is integrated with a routing-based traffic parsing plug-in, which is used to parse the path of the directory corresponding to the control clicked by the user and load the application corresponding to the path.

[0136] Own routing is used to manage routing rules, such as unified entrance, definition of public page routing, control of access rights, etc.

[0137] The remote container module is used to create an iframe container and load sub-applications in it. The iframe container can be regarded as an independent window that loads remote resources.

[0138] The second request processing module integrates a main application request processing plug-in. This plug-in is used to communicate with the first request processing module in the sub-application's web layer, for example, receiving simulated requests from the first request processing module and sending responses to the first request processing module. Furthermore, this plug-in is used to communicate with the service routing in the sub-application's service layer, for example, sending real requests (actual requests sent to the server) to the service routing and receiving responses from the service routing.

[0139] The sub-application service layer includes its own interface set and service routing.

[0140] A proprietary interface collection that provides various types of interfaces, including basic authentication (such as login authentication, logout authentication, etc.), user management, permission management, data management, and configuration management.

[0141] The server routing is integrated with a server proxy forwarding plug-in, which is used to communicate with the second request processing module of the main application Web layer, such as receiving the real request sent by the second request processing module, returning a response to the second request processing module, etc.

[0142] The sub-service cluster includes service layer A, service layer B, service layer C, service layer D and service layer E. Service layer A, service layer B, service layer C, service layer D and service layer E are used to provide decoupled back-end services.

[0143] In some embodiments, when the directory module of the sub-application web layer detects that a user clicks on a control of a sub-application, the web application can create an iframe container through the remote container module and load the sub-application in the iframe container. When the sub-application web layer requests business data from a service layer in the sub-service cluster, such as service layer E, the first request processing module of the sub-application web layer can send a simulated request to the second request processing module of the main application web layer through the sub-application request forwarding plug-in. Then, the second request module can send a real request to the service routing of the sub-application service layer through the main application request processing plug-in. Then, the service routing can forward the real request to service layer E through the server proxy forwarding plug-in. Then, service layer E returns the response result of the real request to the second request processing module through the service routing, and the second request processing module then sends the response result to the first request processing module.

[0144] In some embodiments, the aforementioned routing-based traffic parsing plug-in, main application request processing plug-in, and sub-application request forwarding plug-in are less than 10kb in size. Due to their small size, they are less difficult to develop and can be adapted to a wider range of application scenarios.

[0145] It can be understood that in the embodiment of the present application, it is only necessary to insert the sub-application request forwarding plug-in into the first request processing module of the sub-application Web layer, and insert the main application request processing plug-in into the second request processing module of the main application Web layer, so as to realize the communication between the front-end main and sub-applications, and does not involve complex modifications of the main and sub-applications.

[0146] As you can understand, integrating plug-ins to enable data transfer between the main and sub-applications offers strong scalability, and the separate, purely static management console pages are highly similar, allowing for subsequent deployment using open-source, low-code frameworks. Furthermore, migration is supported with routing as the minimum dimension, ensuring a smooth migration process.

[0147] Below Figure 11 The application separation mechanism, application communication mechanism, and data management mechanism adopted by the micro-frontend architecture shown are introduced.

[0148] 1. Application separation mechanism In some embodiments, an iframe container-based loading mechanism may be used to separate front-end resources.

[0149] The iframe container loading mechanism refers to a mechanism whereby the client loads the triggered sub-application as a remote resource through an iframe container. Remote resources are resources in domains other than the domain where the main application resides, such as HTML pages, images, videos, and other media files.

[0150] It is understood that when using the iframe container loading mechanism to separate front-end resources, the main application and sub-application belong to different domains. In this case, the sub-application path should be configured as an absolute path rather than a relative path.

[0151] For example, refer to Figure 12 ,for Figure 11 In the micro-frontend architecture shown, the path corresponding to the control P0 of the main application can be configured as the absolute path "www.aaa.xxx". The path corresponding to the control P1 of the sub-application a1 can be configured as the absolute path "www.bbb / yewu1.xxx".

[0152] like Figure 12 As shown, the web browser on computer 10 runs the client of the business management application based on the URL "www.aaa.xxx" currently displayed in navigation bar 15, and displays the client's homepage Q1. Homepage Q1 displays the main application's main page M2. When the client detects a user click on control P1 through the main application's directory module, it changes the URL in navigation bar 15 to "www.bbb / yewu1.xxx" and creates an iframe container window V1 for displaying sub-application a1. Then, based on the changed URL "www.bbb / yewu1.xxx," page G1 of sub-application a1 is displayed in window V2.

[0153] It is understandable that when the client creates an iframe container for a sub-application, it is necessary to associate the sub-application with the iframe container so that each sub-application can be displayed in its corresponding iframe container to avoid display anomalies.

[0154] In some embodiments, when the client creates an iframe container for a sub-application, a unique identifier of the iframe container can be generated based on the absolute path corresponding to the sub-application and a random function, such as the identity (ID) of the iframe container (hereinafter referred to as "iframeID"), so that the sub-application and the iframe container are associated together through the identifier, thereby avoiding anomalies when multiple sub-applications interact with the main application.

[0155] The following describes the specific process of loading a sub-application through an iframe container on the client.

[0156] Figure 13 A flowchart of a sub-application page display method provided in an embodiment of the present application.

[0157] refer to Figure 13 , the method comprises the following steps: S301: The client detects that the user clicks control A.

[0158] In some embodiments, when the user clicks on control A on the page displayed by the client, the client can detect that the user clicks on control A through the directory module of the main application.

[0159] S302: The client determines whether the path corresponding to the first control is the path of the sub-application.

[0160] In some embodiments, the paths corresponding to the main application and sub-application controls of the client can be set to different absolute paths. Figure 14 The path corresponding to the control P0 of the main application is "www.aaa.xxx", and the path corresponding to the control p1 of the sub-application is "www.aaa / yewu1.xxx".

[0161] It is understood that if the client determines that the path corresponding to control A is not the path of the sub-application, it means that the control A clicked by the user is a control of the main application, and then step S303 is executed. If the client determines that the path corresponding to control A is the path of the sub-application, it means that the control A clicked by the user is a control of the sub-application, and then step S304 is executed.

[0162] S303: The client loads the main application.

[0163] In some embodiments, when the client determines that the path corresponding to the control A clicked by the user is not the path of the sub-application, it means that control A is the control of the main application, and the client loads the main application according to the path of control A.

[0164] For example, refer to Figure 14Computer 10 loads the client of the business management application through a web browser. The client currently displays page G1 of sub-application a1. When the user clicks control P0 (as an example of control A), the client determines that the path corresponding to control P0 is the path of the main application, and displays the main page M2 of the main application according to the path "www.aaa.xxx" of control P0.

[0165] S304: The client creates an iframe container according to the path corresponding to control A, and generates an iframe ID corresponding to the iframe container.

[0166] In some embodiments, when the client determines that the control A clicked by the user is a control of a sub-application, the client can create an iframe container for the sub-application and generate an iframeID corresponding to the iframe container based on the path corresponding to control A.

[0167] For example, the client can directly use the path corresponding to control A as the iframeID of the iframe container.

[0168] For another example, the client may generate a random number based on a random function, then combine the path corresponding to control A with the random number, and use the combined result as the iframeID of the iframe container.

[0169] For example, refer to Figure 15 Computer 10 loads the client of the business management application through a web browser. The client currently displays the main application page M2. After detecting that the user clicks control P1, the client creates a window V2 (as an iframe container) for loading sub-application a1 and sets the path "www.bbb / yewu1.xxx" corresponding to control P1 as the iframe ID corresponding to window V2.

[0170] S305: The client creates a request forwarding instance and associates it with the iframe ID.

[0171] In some embodiments, the client may create an instance in which the sub-application delegates the main application to forward the request, and associate the instance with the iframe ID corresponding to the sub-application.

[0172] It should be noted that each created iframe container needs to be associated with a new instance of request processing to avoid interference when multiple sub-applications interact with the main application.

[0173] S306: The client monitors the loading event of the iframe container.

[0174] In some embodiments, when the client monitors that the iframe container corresponding to the sub-application is created, the client monitors the loading event of the iframe container and needs to load the corresponding sub-application through the created iframe container.

[0175] S307: The client displays the page of the sub-application corresponding to control A.

[0176] In some embodiments, the client may display the page of the sub-application corresponding to the control clicked by the user through the iframe container corresponding to the sub-application.

[0177] For example, refer to Figure 15 , the client can display page G1 of sub-application a1 in window V1.

[0178] In the embodiments of the present application, the client loads a sub-application as a remote resource through an iframe container, thereby achieving front-end separation of the web application. Furthermore, when the client creates an iframe container to load a sub-application, it generates an iframe ID for the iframe container, ensuring that the sub-application is loaded into the correct iframe container. This avoids the exception of mismatched sub-applications loaded by multiple iframe containers when loading sub-applications simultaneously.

[0179] In some embodiments, a client can use a lazy loading mechanism when loading a sub-application through an iframe container. Lazy loading refers to dynamically loading resources based on user needs (such as scrolling to a certain position) rather than immediately loading all resources during page loading. This mechanism is particularly suitable for loading media resources such as images, videos, and scripts, as well as non-media resources such as modules and database queries.

[0180] 2. Request delegation mechanism I understand. Figure 11 In the micro-frontend architecture shown, the main application and each sub-application belong to different domains. In this case, the main application and each sub-application cannot directly communicate across domains.

[0181] Based on this, in some embodiments, a request delegation mechanism based on the PostMessage mechanism may be used to implement communication between the main application and the sub-application.

[0182] It can be understood that when the sub-application requests server data from the server, the sub-application itself does not send a real request to the server, but entrusts the main application to request data from the server.

[0183] In some embodiments, the sub-application may send a simulated request to the main application based on a PostMessage mechanism, and through the simulated request, the main application is delegated to send a real request to the server.

[0184] In some embodiments, the simulated request includes but is not limited to a normal request, a file download request, a file upload request, and the like.

[0185] Normal requests refer to standard HTTP requests.

[0186] In some embodiments, the sub-application can package the request information, such as the interface name and request body, into JSON format and send it to the main application as a normal request. After receiving the normal request, the main application sends the corresponding real request to the server. After receiving the real request, the server returns the corresponding response data to the main application. The main application then returns the response data to the sub-application.

[0187] A file upload request is a request to upload a file to a server over the network.

[0188] In some embodiments, when a sub-application uploads a file, it can generate a file upload request based on the file to be uploaded and send it to the main application. The main application then generates a corresponding real request based on the file upload request and sends it to the server. This real request includes the file data to be uploaded. The main application then sends this real request to the server, which then uploads the file to the server. After the main application completes the upload, it can return the upload result to the sub-application.

[0189] In some embodiments, to prevent reference loss and data integrity loss, the sub-application can convert the file to be uploaded into a Base64-encoded string (this can be achieved by reading the file content and encoding it into Base64) through the first request processing module, and then package the Base64-encoded string of the file and necessary metadata (such as the file name, file type, etc.) into JSON format as a file upload request. The sub-application can then send the file upload request to the main application via the PostMessage mechanism. The main application can then perform binary conversion on the file upload request to obtain the corresponding real request, and upload the file to the server by sending the real request to the server.

[0190] A file download request is a request to obtain a file from a server or other remote location and save it to the local device.

[0191] In some embodiments, when a sub-application needs to download a file, it can send a file download request to the main application via the PostMessage mechanism. This file download request includes the file's URL or other necessary information. After receiving the sub-application's file download request, the main application parses the request and extracts the URL of the file to be downloaded. The main application then constructs a real request based on the URL and sends it to the server. After receiving the real request, the server returns the corresponding file data to the main application, allowing the main application to download the corresponding file from the server.

[0192] In some embodiments, after the main application is downloaded, it only needs to return the download success result to the sub-application.

[0193] It can be understood that the simulated request sent by the sub-application to the main application is not an actual request, but rather the request parameters are sent to the main application, and then the main application generates a corresponding real request based on the request parameters and sends it to the backend.

[0194] In some embodiments, the steps for the sub-application to delegate the main application to send a request to the server are as follows: (1) Package the delegation and response events into Promises, so that the development experience of the sub-application is consistent with the actual request.

[0195] In some embodiments, the event in which the sub-application delegates the main application to send a request to the server and the event in which the server responds to the request delegated by the sub-application to the main application can be packaged into Promise, so that the development experience of the sub-application is consistent with the actual request.

[0196] It can be understood that the sub-application entrusts the main application to send a request to the server, that is, the sub-application sends a simulated request to the main application, and then the main application generates a real request corresponding to the simulated request and sends it to the server.

[0197] (2) Use request parameters and interface name to generate a unique event identifier to ensure single request context association.

[0198] In some embodiments, a unique identifier based on the request parameters and the interface name can be created to ensure that each request and its associated response can be correctly associated.

[0199] Specifically, all relevant parameters can be extracted from the request, followed by the target interface name or path. The extracted parameters are then sorted to ensure that identical parameters always appear in the same order. The sorted parameters are then concatenated with the interface name into a single string. A hash function (such as SHA-256) is then applied to this string to generate a fixed-length hash value.

[0200] Typically, to facilitate transmission and processing, only a portion of the hash value can be used as a unique identifier. When initiating a request, this unique identifier can be included in the request header or body. The response also includes this unique identifier, allowing the host application to match requests and responses based on this identifier.

[0201] The main application can record each unique identifier and its corresponding request status (for example, using a hash table). When the main application receives a response, it uses the unique identifier in the response to find the request status and update or clear the corresponding record.

[0202] (3) Send the iframe ID to the main application, and the main application manages the data channel of the sub-application.

[0203] In some embodiments, when a sub-application delegates a request to the main application, the sub-application can send the iframe ID of the iframe container that loads the sub-application to the main application, allowing the main application to manage the sub-application's data channel based on the iframe ID. For the sake of narrative coherence, the following describes how data transmission is managed.

[0204] (4) Release the corresponding monitor promptly after the request is completed.

[0205] In some embodiments, when the event of the sub-application delegating the main application to send a request to the server is completed, the monitoring event of the sub-application delegating the main application to send a request to the server is released (released).

[0206] 3. Data channel and request management (1) Data channel management between main and sub-applications As you can understand, a web application in a micro-frontend architecture typically consists of a main application and multiple sub-applications. Therefore, the main application needs to send data to multiple sub-applications. To avoid data errors when sending data between the main application and multiple sub-applications, such as the main application mistakenly sending data intended for sub-application a1 to sub-application a2, data channels between the main application and sub-applications must be managed.

[0207] In some embodiments, a unique iframe ID can be added when a sub-application sends a simulation request to a main application and when the main application returns a response to the sub-application. This unique iframe ID can be used to associate the main application with the sub-application, thereby preventing errors in data transmission between the main and sub-applications. The iframe ID is an ID generated by the main application based on the sub-application's path when the main application creates an iframe container for the sub-application.

[0208] (2) Multi-request management It's understandable that when multiple sub-applications send simulated requests to the main application, the main application needs to generate multiple real requests based on these simulated requests and send them to the server. To prevent the main application from mistakenly sending simulated requests from sub-applications to the server, for example, if the main application originally intended to send the real request corresponding to the simulated request from sub-application a1 to the server but mistakenly sent the real request corresponding to the simulated request from sub-application a2 to the server, the sub-application requests (the requests delegated to the main application to send to the server) need to be managed.

[0209] In some embodiments, a publish-subscribe model can be used to manage requests from multiple sub-applications, that is, the requests from multiple sub-applications are managed through a unified event pool, thereby simulating the process of sub-applications calling the server's back-end services to a point-to-point call process similar to a remote procedure call (RPC).

[0210] As you can understand, RPC is a method of inter-process communication (IPC) that allows a computer program to call another program on the network, just like calling a local subroutine, without having to understand the details of the underlying network protocol.

[0211] In some embodiments, when a sub-application delegates a main application to send a real request to a backend service, the main application can add an ID (hereinafter referred to as "requestID") to the real request to distinguish the real requests sent to the server by different sub-applications delegated by the main application through the requestID, thereby avoiding errors in the real requests sent to the server by the sub-application delegated by the main application.

[0212] In some embodiments, the main application may perform a hash calculation on the interface name and other parameters of the interface called when the main application sends a real request using a national secret digest algorithm to generate a fixed-length digest value as the requestID.

[0213] It's understood that the sub-applications and main application mentioned above run on front-end devices (such as terminal devices), while back-end services run on back-end devices (such as back-end services). For ease of understanding, the sub-applications running on front-end devices are referred to as front-end sub-applications, and the main application on the front-end device is referred to as the front-end main application.

[0214] Figure 16 An interaction diagram of a front-end sub-application, a front-end main application, and a back-end service provided in an embodiment of the present application.

[0215] refer to Figure 16When the front-end sub-application sends a request to the back-end service, it doesn't send the request directly to the back-end service. Instead, it sends a simulated request to the front-end main application's second request module through the first request processing module. The front-end main application's second request processing module then generates a real request based on the simulated request and sends it to the back-end service. After receiving the real request, the back-end service returns the corresponding response to the front-end main application. The front-end main application then returns the response to the front-end sub-application through the second request module.

[0216] In some embodiments, when the simulated request sent by the front-end sub-application to the front-end main application is a file download request, the main application sends a real request to the back-end service to download the file, and the back-end service then returns the corresponding file data to the main application. In this case, the front-end main application handles the file download through the external layer, that is, the front-end sub-application downloads the corresponding file data through the front-end main application.

[0217] In some embodiments, common requests sent by the front-end sub-application to the front-end main application can be sent in the form of an object. File requests sent by the front-end sub-application to the front-end main application, such as file download requests and file upload requests, can be sent in base64 format.

[0218] Figure 17 A flowchart of a business processing method provided in an embodiment of the present application. The business processing method is used in a business system, and the business system includes a client and a server. The client includes a front-end main application and multiple front-end sub-applications, and the server includes a back-end service. The client runs on the front-end device, and the server runs on the back-end device. The following continues to illustrate the example of a computer as a front-end device and a server as an example of a back-end device. In some embodiments, the business management system can be the aforementioned Figure 11 Web applications using the micro-frontend architecture shown include, but are not limited to, online shopping applications, social networking applications, enterprise resource management applications, and business management applications. The following uses a business management system as an example of a business management application.

[0219] refer to Figure 17 , the method comprises the following steps: S401: The front-end device loads the client.

[0220] It can be understood that the client data is deployed on the back-end device.

[0221] In some embodiments, the front-end device may request the client data of the business system from the back-end device through a web browser based on the URL of the business system, and load the client of the business system according to the data.

[0222] For example, Figure 18As shown, the computer 10 can request the client data of the business management application from the server 20 based on the URL "www.aaa.xxx" of the business management application through a web browser, and load the client of the business management application according to the client data.

[0223] In some embodiments, the client includes a front-end main application and multiple front-end sub-applications. Furthermore, the front-end main application and the front-end sub-applications belong to different domains. In other words, the front-end main application and the front-end sub-applications use different network protocols, port numbers, and domain names. In this case, when a web browser runs the front-end main application and the front-end sub-applications, the web browser's same-origin policy restricts resource access between the front-end main application and the front-end sub-applications, preventing direct communication between the front-end main application and the front-end sub-applications.

[0224] In some embodiments, the URL of the business system is consistent with the URL of its front-end main application. Figure 18 As shown, the URL of the business management application is "www.aaa.xxx", and the URL of its front-end main application is also "www.aaa.xxx".

[0225] S402: The client on the front-end device displays a first interface, where the first interface includes controls of a plurality of front-end sub-applications, including a first front-end sub-application.

[0226] In some embodiments, after the front-end device loads the client of the business system, the client displays a first interface including controls of multiple front-end sub-applications, including the first front-end sub-application.

[0227] For example, Figure 18 As shown, after the computer 10 loads the client of the business management application, the client displays the home page Q1 (as an example of the first interface). The home page Q1 includes the control P0 of the front-end main application and the front-end sub-applications a1~a n Controls P0~Pn.

[0228] S403: The client of the front-end device detects a triggering event of a first control of a first front-end sub-application in a first interface.

[0229] In some embodiments, the client of the front-end device detects a triggering event of a first control of a first front-end sub-application in a first interface, such as detecting that a user clicks on the first control.

[0230] For example, Figure 19 As shown, the client of the business management application on the computer 10 detects through the main application that the user clicks on the control P1 (as an example of the first control) of the front-end sub-application a1 (as an example of the first front-end sub-application) in the home page Q1.

[0231] S404: The client on the front-end device sends a first request for a first front-end sub-application to the server.

[0232] The first request is used to request first service data.

[0233] In some embodiments, a client on a front-end device sends a first request for a first front-end sub-application to a service end of a server.

[0234] For example, Figure 19 As shown, the client of the business management application on the computer 10 sends a real request (as a first request) to the server 20 through the main application to request data of business 1 (as first business data).

[0235] In some embodiments, step S404 includes the following sub-steps: S4041: The first front-end sub-application sends a first parameter to the front-end main application.

[0236] It can be understood that since the first front-end sub-application and the front-end main application belong to different domains, the first front-end sub-application and the front-end main application will be subject to the cross-domain restrictions of the same-origin policy adopted by the Web browser, resulting in the first front-end sub-application and the front-end main application not being able to communicate directly.

[0237] In some embodiments, the first front-end sub-application may send the first parameter as the aforementioned simulation request to the front-end main application based on the PostMessage mechanism. In some embodiments, the first parameter may be a parameter indicating the type, length, format, etc. of the first business data.

[0238] For example, Figure 19 As shown, when the control P1 of the front-end sub-application a1 is triggered, the front-end sub-application a1 may send a parameter indicating the data of service 1 (as a first parameter) as a simulation request to the front-end main application.

[0239] S4042: The front-end main application generates a first request based on the first parameter.

[0240] In some embodiments, after receiving the first parameter, the front-end main application can generate a first request (as a real request) according to the first parameter.

[0241] In some embodiments, when the front-end main application generates the first request, it can use a national secret digest algorithm to perform a hash calculation on the interface parameters (such as the interface name and other parameters) of the interface (serving as the first interface) invoked when the front-end main application sends the actual request. This generates a fixed-length digest value as the requestID (serving as the first identifier), and tags the first request with the requestID. This allows the first request to be identified by the requestID, preventing errors in sending and responding to the first request.

[0242] S4043: The front-end main application sends a first request to the back-end service.

[0243] In some embodiments, after the front-end main application generates a first request based on the first parameter, the front-end main application sends the first request to the back-end service.

[0244] For example, Figure 19 As shown, the front-end main application running on the computer 10 can send a corresponding real request to the back-end service running on the server 20 to request data of business 1.

[0245] S405: The server on the backend device sends first service data to the client on the frontend device.

[0246] In some embodiments, after the server on the backend device receives the first request sent by the client, the server on the backend device sends the first service data to the client on the frontend device. Figure 19 As shown, after the service end of the business management application on the server 20 receives the real request sent by the client of the business management application on the computer 10, it sends the data of business 1 to the client of the business management application on the computer 10.

[0247] S406: The client on the front-end device displays a second interface corresponding to the first business data.

[0248] In some embodiments, the client on the front-end device may create an iframe container for the first front-end sub-application, and display the second interface corresponding to the first business data in the iframe container.

[0249] For example, Figure 19 As shown, the client of the business management application on the computer 10 can create an iframe container - window V1 for the sub-application a1, and then display the page Q1 corresponding to the data of business 1 in the window V1 (as an example of the second interface).

[0250] In some embodiments, when the client creates an iframe container for the first front-end sub-application, it can add an iframeID (as a second identifier) ​​to the iframe container, so that the client can identify the corresponding iframe container through the iframeID, thereby avoiding mismatch of the iframe container loaded by the first front-end sub-application.

[0251] In some embodiments, the client may directly use the path corresponding to the first control as the iframe ID of the iframe container for loading the first front-end sub-application.

[0252] In other embodiments, the client may generate a random number according to a random function, then combine the path corresponding to the first control with the random number, and use the combined result as the iframeID of the iframe container that loads the first front-end sub-application.

[0253] It should be noted that the specific method of generating the iframe ID by the client can be found in the relevant introduction of the above step S304, which will not be repeated here.

[0254] In an embodiment of the present application, the front-end sub-application can realize cross-domain communication between the sub-application and the back-end service by entrusting the front-end main application to send a request to the back-end service, so that the front-end sub-application can request corresponding business data from the back-end service to process the corresponding business.

[0255] In some embodiments, the backend device includes a first backend device, and the frontend main application, the frontend sub-application and the backend service are deployed on the first backend device.

[0256] In other embodiments, the backend device includes a second backend device and at least one third backend device, the frontend main application and backend services are deployed on the second backend device, and at least part of the frontend sub-applications are deployed on at least one third backend device.

[0257] It is understood that the multiple front-end sub-applications in the client may be partially deployed on the second back-end device, partially deployed on at least one third back-end device, or all deployed on the at least one third back-end device. For example, the number of third back-end devices is greater than or equal to the number of front-end sub-applications, and each front-end sub-application is deployed on a different third back-end device.

[0258] The embodiment of the present application achieves the coexistence of sub-applications in multi-tab mode (parallel coexistence in a multi-tab environment) and efficient interaction by subdividing the categories of delegation requests and accurately managing the data channels and events between the main and sub-applications.

[0259] Figure 20According to some embodiments of the present application, a schematic structural diagram of an electronic device 100 is shown. The electronic device 100 can be the aforementioned front-end device or the aforementioned back-end device.

[0260] like Figure 20 As shown, the electronic device 100 includes one or more processors 110, one or more memories 120, and one or more communication interfaces 130. The processor 110, the memory 120, and the communication interface 130 may be coupled via a bus (not shown), which may be a path for transmitting information between the various components of the device 100 (e.g., the processor 110, the memory 120, and the communication interface 130).

[0261] The processor 110 may include any one or more processors such as a central processing unit (CPU), a graphics processing unit (GPU), a microprocessor (MP), a digital signal processor (DSP), a baseband processor (BP), and an application processor (AP).

[0262] The memory 120 may include volatile memory, such as random access memory (RAM). The processor 104 may also include non-volatile memory, such as read-only memory (ROM), flash memory, a hard disk drive (HDD), or a solid state drive (SSD).

[0263] The memory 120 stores executable program code, and the processor 110 executes the executable program code to implement the functions of the aforementioned front-end device or the front-end and back-end devices, thereby implementing the above-mentioned business processing method. In other words, the memory 106 stores instructions for executing the business processing method provided in each embodiment of the present application.

[0264] In some embodiments, the processor 110 may execute a business processing method by executing instructions of the business processing method stored in the memory 120. For example, the processor 110 detects a triggering event of a first control of a first front-end sub-application, generates a first request of the first front-end sub-application, generates a first identifier based on interface parameters of a first interface, marks the first request with the first identifier, performs a hash calculation on the interface parameters of the first interface using a national secret digest algorithm to obtain the first identifier, and the like.

[0265] It should be noted that Figure 20 The structure of the device 100 shown is only an example. In other embodiments, the device 100 may include more or fewer modules, which is not limited here.

[0266] It should be noted that the terms used in the implementation methods section of the embodiments of the present application are only used to explain the specific embodiments of the present application, and are not intended to limit the present application. In the description of the embodiments of the present application, unless otherwise specified, " / " means or, for example, A / B can mean A or B; "and / or" in this article is merely a way to describe the association relationship of associated obstacles, indicating that there can be three relationships, for example, A and / or B can mean: A exists alone, A and B exist at the same time, and B exists alone. In addition, in the description of the embodiments of the present application, unless otherwise specified, "multiple" means two or more than two, "at least one" and "one or more" mean one, two or more than two.

[0267] It should be noted that in the embodiments of the present application, "equal to" and "less than" can be used together. For example, indicating that a parameter corresponds to situation B when it is greater than or equal to A and corresponds to situation C when it is less than A can also be understood as indicating that the parameter corresponds to situation B when it is greater than A and corresponds to situation C when it is less than or equal to A.

[0268] In the following, the terms "first" and "second" are used for descriptive purposes only and should not be understood as indicating or implying relative importance or implicitly specifying the number of the technical features indicated. Therefore, the definition of "first" and "second" features may explicitly or implicitly include one or more of the features.

[0269] References to "one embodiment" or "some embodiments" in this specification mean that a particular feature, structure, or characteristic described in conjunction with that embodiment is included in one or more embodiments of the present application. Thus, phrases such as "in one embodiment," "in some embodiments," "in other embodiments," and "in yet other embodiments" appearing in various places in this specification do not necessarily refer to the same embodiment, but rather mean "one or more, but not all, embodiments," unless otherwise specifically emphasized. The terms "including," "comprising," "having," and variations thereof mean "including but not limited to," unless otherwise specifically emphasized.

[0270] In the above embodiments, all or part of the embodiments can be implemented using software, hardware, firmware, or any combination thereof. When implemented using software, all or part of the embodiments can be implemented in the form of a computer program product. The computer program product includes one or more computer instructions. When the computer program instructions are loaded and executed on a computer, all or part of the processes or functions described in the embodiments of this application are generated. The computer can be a general-purpose computer, a special-purpose computer, a computer network, or other programmable device. The computer instructions can be stored in a computer-readable storage medium or transmitted via the computer-readable storage medium. The computer instructions can be transmitted from one website, computer, server, or data center to another website, computer, server, or data center via wired (e.g., coaxial cable, optical fiber, digital subscriber line) or wireless (e.g., infrared, wireless, microwave, etc.) means. The computer-readable storage medium can be any available medium that can be accessed by a computer, or a data storage device such as a server or data center that integrates one or more available media. The available medium can be magnetic media (e.g., floppy disk, hard disk, tape), optical media, or semiconductor media (e.g., solid-state drive (SSD)).

[0271] Those skilled in the art can understand that to implement all or part of the processes in the above-mentioned embodiment method, the process can be completed by a computer program to instruct the relevant hardware, and the program can be stored in a computer-readable storage medium. When the program is executed, it can include the processes of the above-mentioned method embodiments.

[0272] The above description is merely a specific embodiment of the present invention, but the scope of protection of the present invention is not limited thereto. Any changes or substitutions within the technical scope disclosed in the present invention should be included in the scope of protection of the present invention. Therefore, the scope of protection of the present invention should be based on the scope of protection of the claims.

Claims

1. A business processing method, applied to a business system, characterized in that: The business system includes a client and a server. The client includes a front-end main application and multiple front-end sub-applications. The server includes a back-end service. The back-end service provides services for the multiple front-end sub-applications. The front-end main application and the front-end sub-application belong to different domains, and the front-end main application and the back-end service belong to the same domain; Furthermore, the method comprises: The client displays a first interface, the first interface including controls of the plurality of front-end sub-applications, the plurality of front-end sub-applications including the first front-end sub-application; The client detects a triggering event of a first control of the first front-end sub-application in the first interface; The client sends a first request of the first front-end sub-application to the back-end service of the server, wherein the first request is used to request first business data; The backend service sends the first business data to the client; The client sends a first request for the first front-end sub-application to the back-end service of the server, including: The first front-end sub-application sends a first parameter to the front-end main application; The front-end main application generates the first request based on the first parameter; The front-end main application sends the first request to the back-end service.

2. The method according to claim 1, characterized in that The first request includes a first identifier, which is generated based on interface parameters of a first interface. The first interface is the interface called when the front-end main application sends the first request, and the interface parameters include an interface name.

3. The method according to claim 2, characterized in that The first front-end sub-application sends a first parameter to the front-end main application, including: The first front-end sub-application sends the first parameter to the front-end main application through a first data channel, where the first data channel includes a PostMessage channel.

4. The method according to any one of claims 1 to 3, characterized in that The method further comprises: The client creates a first container for displaying an interface corresponding to the first front-end sub-application before receiving the first service data; After receiving the first business data, the client displays a second interface corresponding to the first business data in the first container.

5. The method according to claim 4, characterized in that The first container has a second identifier corresponding to the first front-end sub-application, and after the client receives the first business data, the second interface corresponding to the first business data is displayed in the first container, including: determining, based on the second identifier, the first container corresponding to the first business data; The second interface is displayed in the first container.

6. The method according to claim 1 or 3, characterized in that The first parameter includes at least one of the following: A parameter used to indicate the type of the first business data, a parameter used to indicate the length of the first business data, and a parameter used to indicate the format of the first business data.

7. A business processing method, applied to a system including a front-end device and a back-end device, characterized in that: A client is running on the front-end device, and a server, a front-end main application, and multiple front-end sub-applications are deployed on the back-end device. The server includes a back-end service, and the back-end service provides services for the multiple front-end sub-applications. The front-end main application and the back-end service on the back-end device belong to the same domain, and the front-end sub-application and the front-end main application on the back-end device belong to different domains. Furthermore, the method comprises: The front-end device obtains the front-end main application and the plurality of front-end sub-applications from the back-end device, and displays a first interface, wherein the first interface includes controls for each of the front-end sub-applications; The front-end device detects a triggering event of a first control in the first interface, wherein the first control is a control corresponding to a first front-end sub-application among the multiple front-end sub-applications; The front-end device sends a first request of the first front-end sub-application to the back-end service of the back-end device, wherein the first request is used to request first service data; The backend service sends the first business data to the front-end device; The front-end device sending a first request of the first front-end sub-application to the back-end service of the back-end device includes: The front-end device sends a first parameter to the front-end main application through the first front-end sub-application; The front-end device generates the first request based on the first parameter through the front-end main application; The front-end device sends the first request to the back-end service of the back-end device through the front-end main application.

8. The method according to claim 7, characterized in that The backend device includes a first backend device, and the frontend main application, the frontend sub-application and the backend service are deployed on the first backend device.

9. The method according to claim 7, characterized in that The backend device includes a second backend device and at least one third backend device, the frontend main application and the backend service are deployed on the second backend device, and at least part of the frontend sub-application is deployed on the at least one third backend device.

10. An electronic device, characterized in that: include: a memory for storing instructions to be executed by one or more processors of the electronic device; A processor, when the processor executes the instructions in the memory, causes the electronic device to perform the method according to any one of claims 1 to 6 or claims 7 to 9.

11. A computer-readable storage medium, characterized in that The computer-readable storage medium stores instructions, which, when executed on a computer, cause the computer to perform the method of any one of claims 1 to 6 or claims 7 to 9.

12. A computer program product, characterized in that The method comprises a computer program / instructions which, when executed, cause a computer to perform the method of any one of claims 1 to 6 or claims 7 to 9.

Images