Business processing methods, electronic devices, and computer-readable storage media

Abstract

This application relates to the field of micro-frontend technology, proposing a business processing method, an electronic device, and a computer-readable storage medium. The method is applied to a business system, which includes a client and a server. The client includes a main frontend application and multiple frontend sub-applications, while the server includes a backend service that provides services to the multiple frontend sub-applications. In this method, when a control in a frontend sub-application is triggered, the frontend sub-application delegates a request from the main frontend application to the server to request corresponding business data. Because the backend service is not decoupled in the micro-frontend architecture of the business system, when migrating the micro-frontend architecture corresponding to a monolithic web application, only the frontend resources need to be decoupled and transformed into multiple frontend sub-applications, without needing to decouple the backend service of the web application. This allows for a gradual migration of web applications from a monolithic architecture to a micro-frontend architecture.

Description

Technical Field

[0001] This application relates to the field of micro-frontend technology, and more particularly to a business processing method, electronic device, and computer-readable storage medium. Background Technology

[0002] As functionality increases, the codebase of monolithic web applications grows larger. Due to the high degree of code coupling in monolithic web applications, the development, deployment, and maintenance efficiency is low for large-scale monolithic web applications.

[0003] To improve the efficiency of developing, deploying, and maintaining monolithic web applications, they can be migrated to micro-frontend architectures. This involves transforming the various business modules within a monolithic web application into independent sub-applications, thus decoupling the monolithic architecture. Since these independent sub-applications can be developed, deployed, and maintained independently, migrating a monolithic web application to a micro-frontend architecture significantly improves the efficiency of web application development, deployment, and maintenance.

[0004] However, existing technologies can only perform a one-time, leapfrog migration when migrating web applications from a monolithic architecture to a micro-frontend architecture, rather than a gradual migration, which involves a large workload and high migration costs. Summary of the Invention

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

[0006] Firstly, this application provides a business processing method applied to a business system, which includes a client and a server. The client includes a main front-end application and multiple front-end sub-applications, and the server includes a back-end service that provides services to the multiple front-end sub-applications. The main front-end application and the front-end sub-applications belong to different domains, while the main front-end application and the back-end service belong to the same domain. Furthermore, the method includes:

[0007] The client displays a first interface, which includes controls for multiple front-end sub-applications, including the first front-end sub-application. The client detects a trigger event of a first control in the first front-end sub-application on the first interface. The client sends a first request from 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 back-end service sends the first business data to the client. The client sending the first request from the first front-end sub-application to the back-end service of the server includes: the first front-end sub-application sending a first parameter to the main front-end application; the main front-end application generating a first request based on the first parameter; and the main front-end application sending the first request to the back-end service.

[0008] Because the front-end sub-applications and back-end services belong to different domains, the front-end sub-applications cannot directly send requests to the back-end services across domains. Therefore, when a control in the front-end sub-application is triggered, the front-end sub-application can delegate the request from the main front-end application to the server to request the corresponding business data to implement the corresponding business logic. Since the back-end services are not decoupled in the micro-front-end architecture of the business system, when migrating the corresponding micro-front-end architecture of a monolithic web application to that business system, only the front-end resources need to be decoupled and transformed into multiple front-end sub-applications; the back-end services of the web application do not need to be decoupled. This allows for a gradual migration of web applications from a monolithic architecture to a micro-front-end architecture.

[0009] In some implementations, the first request includes a first identifier, which is generated based on the interface parameters of a first interface, which is the interface called by the front-end main application when sending the first request, and the interface parameters include the interface name.

[0010] When the main front-end application generates the first request, it can use a national cryptographic digest algorithm to hash the interface parameters (such as the interface name and other parameters) of the interface called when sending the actual request (as the first interface). This hashes the parameters to generate a fixed-length digest value, which serves as the requestID (the first identifier). The first request is then marked using this requestID. This allows the first request to be identified through its requestID, preventing errors in sending and responding to the first request.

[0011] In some implementations, the first parameter includes at least one of the following: a parameter indicating the type of the first service data, a parameter indicating the length of the first service data, and a parameter indicating the format of the first service data.

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

[0013] The fact that the main front-end application and the first front-end sub-application belong to different domains indicates that they use different network protocols, port numbers, and domain names. In this case, when a web browser runs the main front-end application and the first front-end sub-application, the web browser's same-origin policy will restrict resource access between the main front-end application and the first front-end sub-application, disallowing them from communicating directly.

[0014] The PostMessage mechanism is a cross-domain communication mechanism. Applications in different domains can send data to each other through the PostMessage channel using the `window.postMessage()` method provided by this mechanism, 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 send data to each other using the `window.postMessage()` method to communicate. Therefore, the main front-end application can send data to the sub-application through the PostMessage channel.

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

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

[0017] In some implementations, 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 service data; and the client displaying a second interface corresponding to the first service data in the first container after receiving the first service data.

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

[0019] An iframe container is a separate window used to securely load remote resources (from different domains), resolving cross-domain resource loading restrictions imposed by the same-origin policy. Under the same-origin policy's cross-domain restrictions, the main front-end application can load sub-applications from different domains using an iframe container.

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

[0021] In some implementations, the first container has a second identifier corresponding to the first front-end application, and after the client receives the first service data, it displays a second interface corresponding to the first service data in the first container, including: determining the first container corresponding to the first service data based on the second identifier; and displaying the second interface in the first container.

[0022] 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, thus avoiding mismatches in loading the iframe container of the first front-end sub-application.

[0023] In other embodiments, the client can generate a random number based on a random function, then combine the path corresponding to the first control with the random number, and use the combination result as the iframeID of the iframe container for loading the first front-end sub-application.

[0024] Firstly, this application provides a business processing method applied to a system including front-end devices and back-end devices. The front-end device runs a client, and the back-end device deploys a server, a main front-end application, and multiple front-end sub-applications. The server includes a back-end service that provides services to the multiple front-end sub-applications. The main front-end application and the back-end service on the back-end device belong to the same domain, while the front-end sub-applications on the back-end device belong to different domains than the main front-end application.

[0025] Furthermore, the methods include:

[0026] The front-end device obtains the main front-end application and multiple front-end sub-applications from the back-end device and displays a first interface, which includes controls for each front-end sub-application.

[0027] The front-end device detects the trigger event of the first control in the first interface, where the first control is the control corresponding to the first front-end sub-application among multiple front-end sub-applications;

[0028] 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 business data;

[0029] The backend service sends the first business data to the frontend device;

[0030] Specifically, the front-end device sends a first request from the back-end service of the back-end device to the first front-end sub-application, including:

[0031] The front-end device sends the first parameter to the front-end main application through the first front-end sub-application;

[0032] The front-end device generates the first request based on the first parameter through the main front-end application;

[0033] The front-end device sends the first request to the back-end service of the back-end device through the front-end main application.

[0034] In some implementations, the backend device includes a first backend device, and the frontend main application, frontend sub-applications, and backend services are deployed on the first backend device.

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

[0036] In some implementations, the backend devices include a second backend device and at least one third backend device, with the main frontend application and backend services deployed on the second backend device, and at least some of the frontend sub-applications deployed on at least one third backend device.

[0037] Multiple front-end sub-applications in the client can be deployed partly on a second back-end device and partly on at least one third back-end device, or all of them can be deployed on the at least one third back-end device. For example, the number of third back-end devices may be greater than or equal to the number of front-end sub-applications. Each front-end sub-application may be deployed on a different third back-end device.

[0038] Thirdly, embodiments of this application provide an electronic device, including: a memory for storing instructions executable 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 this application. The beneficial effects achievable in this third aspect can be found in the beneficial effects of the method provided in any embodiment of the first aspect, and will not be repeated here.

[0039] Fourthly, embodiments of this application provide a computer-readable storage medium storing instructions that, when executed on a computer, cause the computer to perform the method described in any embodiment of the first aspect. The beneficial effects achievable in this fourth aspect can be found in the beneficial effects of the method provided in any embodiment of the first aspect, and will not be repeated here.

[0040] Fifthly, embodiments of this application provide a computer program product including computer program code. When the computer program code is run on a computer, it causes the computer to implement the method described in any embodiment of the first aspect. The beneficial effects achievable in the fifth aspect can be found in the beneficial effects of the method provided in any embodiment of the first aspect, and will not be repeated here. Attached Figure Description

[0041] Figure 1This is a schematic diagram of the monolithic architecture provided in the embodiments of this application;

[0042] Figure 2 This is a schematic diagram of a micro-front-end structure provided in an embodiment of this application;

[0043] Figure 3 An interaction diagram of a front-end and a back-end provided for an embodiment of this application;

[0044] Figure 4A A schematic diagram illustrating a front-end loaded as a business management application, provided as an embodiment of this application;

[0045] Figure 4B A schematic diagram of a page corresponding to a front-end display service 1 provided in an embodiment of this application;

[0046] Figure 5 A schematic diagram illustrating the migration of a business management application from a monolithic architecture to a micro-frontend architecture, provided as an embodiment of this application;

[0047] Figure 6A An interaction diagram of a business management application provided in an embodiment of this application;

[0048] Figure 6B A front-end interface diagram of a business management application being migrated from a monolithic architecture to a micro-front-end architecture, as provided in an embodiment of this application;

[0049] Figure 7A A flowchart illustrating the loading of a sub-application provided in this application embodiment;

[0050] Figure 7B A scenario diagram illustrating a request for business data is provided in an embodiment of this application.

[0051] Figure 8 A schematic diagram illustrating the migration of another business management application from a monolithic architecture to a micro-frontend architecture, as provided in an embodiment of this application.

[0052] Figure 9A A flowchart illustrating another sub-application loading method provided in this application embodiment;

[0053] Figure 9B A scene diagram illustrating the display of a sub-application page, provided as an embodiment of this application;

[0054] Figure 10 This is a schematic diagram of a decoupled backend service provided in an embodiment of this application;

[0055] Figure 11 A schematic diagram of another micro-frontend architecture provided in an embodiment of this application;

[0056] Figure 12An interaction diagram of another business management application provided in this application embodiment;

[0057] Figure 13 This application provides a flowchart of a client displaying a sub-application page;

[0058] Figure 14 An interaction diagram of another business management application provided in this application embodiment;

[0059] Figure 15 An interaction diagram of another business management application provided in this application embodiment;

[0060] Figure 16 An interaction diagram of a front-end sub-application, a front-end main application, and a back-end service is provided for an embodiment of this application;

[0061] Figure 17 A flowchart illustrating a business processing method provided in an embodiment of this application;

[0062] Figure 18 A scene diagram of front-end interaction provided for an embodiment of this application;

[0063] Figure 19 A scenario diagram of another front-end interaction provided for an embodiment of this application;

[0064] Figure 20 This is a schematic diagram of the structure of an electronic device provided in an embodiment of this application. Detailed Implementation

[0065] This application provides a business processing method. The business processing method provided by this application is described below with reference to specific embodiments.

[0066] To facilitate understanding, the terms used in this application will be explained below.

[0067] (1) Web applications

[0068] Web applications are computer programs stored on remote servers and run by users through web browsers. They can provide a wide variety of functions, such as online shopping applications, social networking applications, enterprise resource management applications, and business management applications. Web applications consist of two parts: the front-end and the back-end.

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

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

[0071] It should be noted that the front-end of a web application can run on a front-end device, and the back-end 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 bracelets, virtual reality (VR) and augmented reality (AR) headsets), and in-vehicle devices, etc., which run the front-end of the web application. Back-end devices include, but are not limited to, servers, computers, etc., which run the back-end of the web application; there are no specific limitations on this. For ease of explanation, the following text will use a computer as an example of a front-end device and a server as an example of a back-end device.

[0072] (2) Monolithic architecture

[0073] 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 centralized in a single codebase and interact and collaborate through internal calls and shared databases.

[0074] Monolithic architecture is suitable for simple and small-scale applications, such as internal management systems and small e-commerce websites. In these scenarios, monolithic architecture can be quickly developed, deployed, and maintained to meet business needs. However, due to its limitations in scalability, high coupling, and poor fault tolerance, monolithic architecture may face problems in scalability and maintainability as the business grows and the system scales up.

[0075] Figure 1 A schematic diagram of the monolithic architecture is shown.

[0076] Referring to the diagram, a monolithic web application (hereinafter referred to as a "monolithic web application") includes front-end resources and back-end services. The front-end resources consist of multiple functional modules used to implement various business functions.

[0077] Front-end resources refer to all resources and code 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.

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

[0079] In some embodiments, front-end resources and back-end services can communicate and interact via protocols such as Hypertext Transfer Protocol (HTTP). The front-end sends HTTP requests to the back-end, which receives the requests, executes the corresponding business logic and data processing, and returns the results 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 content.

[0080] (3) Micro-frontend architecture

[0081] Micro-frontend architecture is a front-end development pattern that borrows from the microservices architecture concept. It aims to break down a large front-end application into multiple independent and flexible smaller applications (also known as micro-frontend modules or sub-applications). Each application can be developed, deployed, and maintained independently, and then these smaller applications are integrated into a complete application. By breaking down a large application into multiple independent smaller applications, micro-frontend architecture can improve the efficiency of application development, deployment, and maintenance.

[0082] Figure 2 Showing Single-Spa ® qiankun ® Boundless ® A schematic diagram of the micro-frontend architecture using micro-frontend technologies.

[0083] refer to Figure 2 Single-Spa ® qiankun ® Boundless ® Web applications built on a micro-frontend architecture using micro-frontend technologies (hereinafter referred to as "micro-frontend web applications") consist of a main application (also known as a "micro-frontend base application" or "main frontend application") and multiple sub-applications. The main application includes a directory module. Each sub-application includes a frontend resource and a backend service.

[0084] The main application is primarily responsible for loading, unloading, and managing the various sub-applications.

[0085] The directory module is used to manage the paths of the main application and its various sub-applications. For example, when the directory module detects that a certain control has been triggered, it can load the corresponding application based on the path of that control.

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

[0087] It is understandable that the front-end resources of the sub-application run on the front-end device, while the back-end services of the sub-application run on the back-end device.

[0088] 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 used as an example of a micro-frontend web application for illustration below.

[0089] (4) Homologous strategy, or "homogeneous strategy"

[0090] The same-origin policy is a security policy adopted by web browsers. To ensure the security of resource loading, this policy only allows currently running applications to load resources from the same domain (meaning the network protocol, domain name, and port number are identical), and prohibits currently running applications from loading resources from different domains. For example, a web browser only allows the currently running main application to load sub-applications from the same domain, but not sub-applications from a different domain. Similarly, a web browser only allows currently running sub-applications to load backend services from the same domain, but not backend services from different domains.

[0091] In addition, the same-origin policy does not allow two applications that are not in the same domain 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.

[0092] Figure 3 An exemplary application scenario of this application is shown.

[0093] refer to Figure 3 Server 20 (acting as the backend, also known as the server) runs a monolithic business management application. This application includes modules A1, A2, A3, ..., A... n These are used to implement business 1, business 2, business 3, ..., business n, respectively.

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

[0095] Specifically, refer to Figure 4AComputer 10 has a web browser installed. When computer 10 detects that the user clicks the web browser icon 11 on the desktop H1, computer 10 displays the web browser's navigation interface M1. Navigation interface M1 includes a navigation bar 15. When computer 10 receives the web browser's Uniform Resource Locator (URL) entered by the user in the navigation bar 15, such as "www.aaa.xxx", and detects that the user clicks the search button 16 in the navigation bar 15, computer 10 can send a request to server 20 to access the business management application client based on that network address.

[0096] After receiving the request sent by computer 10, server 20 returns the response result of the request to computer 10 (such as...). Figure 3 (As shown), for example, Hypertext Markup Language (HTML) files, Cascading Style Sheets (CSS) files, JavaScript files, static resources, Application Programming Interface (API) data, etc. Then, based on the response returned by server 20, computer 10 displays the homepage Q1 of the business management application client. Homepage Q1 includes a control bar U1 and a main page M2. The main page M2 is the main application page. 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 the controls for business 1~business n of the business management application, respectively.

[0097] As you can understand, HTML files define the basic structure and content of the application page. CSS files define the style of the application page, such as colors, layout, and fonts. JavaScript files contain client-side script code used to handle user interactions, dynamically update page content, etc. Static resources include image files, font files, icon files, etc. These resources are used to enrich the application's visual effects.

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

[0099] For example, refer to Figure 4BWhen 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 data for business 1 from the backend service of server 20 based on the changed URL "www.aaa / yewu1.xxx". After server 20 provides the data for business 1 to computer 10, computer 10 can display page G1 corresponding to business 1.

[0100] In some cases, to meet increasing business needs, developers add more features to business management applications. As the functionality of a business management application grows, it gradually becomes a monolithic application. A monolithic application is a large, monolithic application with tightly coupled functionalities. Once a business management application becomes a monolithic application, its codebase is large, its coupling is high, and its development, deployment, and maintenance efficiency is low.

[0101] As described in the background section, to improve the efficiency of developing, maintaining, and deploying business management applications, these applications can be migrated from a monolithic architecture to a micro-frontend architecture, which involves splitting the business management application into multiple independent sub-applications. Since these sub-applications are developed, deployed, and maintained independently, this improves the efficiency of developing, deploying, and maintaining the business management application.

[0102] In some cases, to meet increasing business needs, developers add more features to business management applications. As the functionality of a business management application grows, it gradually becomes a monolithic application. A monolithic application can be understood as a large application with tightly coupled functionalities and a monolithic architecture. Once a business management application becomes a monolithic application, its codebase is large, its coupling is high, and its development, deployment, and maintenance efficiency is low.

[0103] In some embodiments, the business management application can be derived from the above. Figure 1 The monolithic architecture shown above Figure 2 The micro-frontend architecture migration is shown.

[0104] Specifically, refer to Figure 5 This allows the main body of the business management application to be transformed into the main application, and modules A1~A within the business management application to be... n They were respectively transformed into sub-applications a1~a n For example, the entire front-end resources of the business management application can be split into front-end resources b1~b2. n And to split the entire backend service of the business management application into backend services c1~c nThis allows the front-end resources and back-end services of the business management application to be decoupled based on different business logic. Specifically, sub-application a1 includes front-end resource b1 and back-end service c1, sub-application a2 includes front-end resource b2 and back-end service c2, sub-application a3 includes front-end resource b3 and back-end service c3, ..., sub-application a... n Including front-end resources b n and backend service a n Furthermore, backend services c1~c are respectively. n Configure different URLs. This way, sub-applications a1~a2 can use different URLs. n Front-end resource b1 Front-end resource b1~b n Each sub-application can access its corresponding backend service through its own URL, ensuring the independence of each sub-application and enabling each sub-application to run independently.

[0105] For example, the front-end resource b1 of 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 based on the request.

[0106] In some embodiments, to ensure the security of resource access, some web browsers employ the same-origin policy to access external resources. To avoid cross-domain restrictions imposed by the same-origin policy, during the migration of business management applications from a monolithic architecture to a micro-frontend architecture, it is necessary to deploy the main application (including frontend resources) and all sub-applications (including frontend resources and backend services) on the same domain. This ensures normal communication between the main and sub-applications, allows the main application to load sub-applications normally, and enables sub-applications to load their corresponding backend services normally.

[0107] In this case, the paths corresponding to the controls in the sub-application need to be configured as relative paths (or "relative base"), not absolute paths (or "absolute base"). In this case, the main application and the sub-application share the same domain name.

[0108] 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.

[0109] A relative path refers to the path from the current working directory or a specified directory to the target file or directory. It does not include root directory information, but rather uses the current working directory or a specified directory as the starting point and a series of directories and subdirectories to locate the file or directory.

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

[0111] It's understandable that after migrating the business management application from a monolithic architecture to a micro-frontend architecture, the front-end page of the business management application remains unchanged, and users are unaware of any changes. For example... Figure 6B As shown, after migrating the business management application from a monolithic architecture to a micro-frontend architecture, the interface displayed on computer 10 remains the same as the original. Furthermore, control P0 corresponds to the main application, and controls P1~Pn correspond to sub-applications a1~a1 respectively. n .

[0112] Since each sub-application's front-end resources have a corresponding back-end service, sub-applications a1~a n Each front-end resource can request server 20 to provide corresponding back-end services to implement the aforementioned modules A1~A. n Responsible for business tasks 1 to n.

[0113] Figure 7A Example diagrams of sub-application loading methods provided for some embodiments.

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

[0115] like Figure 7A As shown, the method includes the following steps:

[0116] S101: The main application on computer 10 detected that the user clicked on control P1 of sub-application a1.

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

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

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

[0120] S103: Sub-application a1 sends a request to the backend service on server 20.

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

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

[0123] refer to Figure 7B After receiving a request from sub-application a1, the backend service running on server 20 returns the data for business 1 to sub-application a1 based on the request.

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

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

[0126] Understandable, according to Figure 7A and Figure 7B It can be seen that, for the above Figure 5 The micro-frontend architecture shown in the diagram allows the sub-applications to directly request business data from the backend service.

[0127] It is understandable that, regarding the above Figure 5 The micro-frontend architecture shown is used for business management applications, because its sub-applications a1~a n Each includes independent front-end resources and back-end services, allowing for independent development, deployment, and maintenance. This breaks down monolithic business management applications into independent sub-applications a1~a1 within a micro-front-end architecture. n It can improve the efficiency of developing, deploying and maintaining business management applications.

[0128] However, when migrating business management applications from a monolithic architecture to a micro-frontend architecture, the migration can only be completed by completely decoupling the frontend resources and backend services of the business management application at once. In other words, it can only be a one-time, leapfrog migration, and cannot be a gradual migration.

[0129] It is understandable that a one-time, leapfrog migration requires decoupling all front-end resources and back-end services at once, which involves a large workload and high migration costs. In contrast, a gradual migration does not require decoupling all front-end resources and back-end services at once. Instead, front-end resources can be decoupled first, and back-end services can be decoupled later, or back-end services can be left undecoupled. This approach involves less workload, lower migration costs, and offers greater flexibility.

[0130] Therefore, to address the aforementioned issues, this application discloses a business processing method. In this method, during the migration of a monolithic web application from a monolithic architecture to a micro-frontend architecture, only the frontend resources of the monolithic web application are decoupled initially, without decoupling the backend services. That is, the main framework of the monolithic web application is transformed into a main application, and only the frontend resources of the monolithic web application are split into the frontend resources of multiple sub-applications, without splitting the backend services of the monolithic web application.

[0131] This is understandable, as the main application is derived from the core framework of a monolithic web application. The main application retains the core resources of the monolithic web application, such as the original APIs, and possesses the core functions, such as requesting backend services to provide corresponding business services. Since the decoupled sub-applications are equivalent to the functional modules of the monolithic web application before decoupling, these sub-applications can share the undecoupled backend services through the main application, thereby implementing the business logic corresponding to each functional module in the monolithic web application.

[0132] Because the various sub-applications share a single, undecoupled backend service with high code coupling, adding new business functionalities to a sub-application becomes very difficult if developers directly develop the shared backend service. Therefore, when adding a new business function to a sub-application, developers can create a separate backend service to implement that function, thus reducing the development complexity.

[0133] To facilitate functional adaptation between sub-applications and newly added backend services (such as adapting frontend UI to backend API data), and to prevent the development of new backend services from affecting the normal operation of existing, non-decoupled backend services, it is necessary to deploy the sub-applications and new backend services in the same domain, such as on the same server. This facilitates functional adaptation between the sub-applications and new backend services, and also prevents the development of new backend services from affecting the operation of existing, non-decoupled backend services.

[0134] In this scenario, the previously undecoupled backend services and the newly added backend services will simultaneously provide business services to the same sub-application. To avoid confusion, the previously undecoupled backend services and the newly added backend services need to be deployed in different domains, such as on different servers, so that the previously undecoupled backend services are isolated from the newly added backend services and do not affect each other.

[0135] For the reasons mentioned above, in some embodiments, during the migration of 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-applications are deployed in different domains.

[0136] It's understandable that, to facilitate functional adaptation between 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. Since the main application is derived from the main body of a monolithic web application, the front-end resources of the main application and the back-end services of the monolithic web application are in the same domain; that is, the front-end resources of the main application and the undecoupled back-end services are in the same domain.

[0137] 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 due to the cross-domain restrictions of the aforementioned same-origin policy, the main application cannot directly load the sub-application, nor can it directly communicate with the sub-application.

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

[0139] An iframe container is a separate window used to securely load remote resources (from different domains), resolving the cross-domain resource loading restrictions of the same-origin policy. Under the cross-domain restrictions of the same-origin policy, the main front-end application can load sub-applications from different domains through an iframe container. Furthermore, using an iframe container to load sub-applications ensures consistency in interaction between the main and sub-applications.

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

[0141] It's understandable that using the PostMesage mechanism can prevent inconsistent user experiences caused by each sub-application implementing its own set of interaction logic. It also solves the problem of layout limitations within iframe containers (such as style isolation and size restrictions), allowing global interactive experiences (such as pop-ups and modals) to be uniformly implemented in the main application, providing a unified interface for all sub-applications to call. Furthermore, sub-applications using the PostMesage mechanism don't need to worry about cross-domain issues or permissions. Thus, the request delegation mechanism implemented based on PostMesage (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 integration mode and the main application, significantly reducing the resistance to implementing a micro-frontend architecture.

[0142] Because the front-end resources of the sub-application are not in the same domain as the front-end resources of the main application, while the front-end resources of the main application are in the same domain as the undecoupled back-end service, and the front-end resources of the sub-application are not in the same domain as the undecoupled back-end service, the sub-application cannot directly request business data from the back-end service due to the cross-domain restrictions of the aforementioned same-origin policy.

[0143] Based on this, in some embodiments, a sub-application may delegate the request for business data from an undecoupled backend service to the main application, instead of directly requesting business data from that undecoupled backend service.

[0144] Specifically, the sub-application can send request parameters indicating business data (such as the type, quantity, and length of the business data) to the main application. Upon receiving these request parameters, the main application generates a corresponding request based on them and sends it to the appropriate server (such as the server hosting an undecoupled backend service). The server then responds to the request by returning the corresponding business data to the main application. Finally, the main application returns this business data to the sub-application.

[0145] For example, refer to Figure 8 The entire front-end resources of a business management application can be split into the front-end resources of multiple sub-applications, such as modules A1~A1 in the business management application. n The front-end resources are respectively transformed into sub-applications a1~a nFront-end resources b1~b n However, the backend services of the business management application are not split. Furthermore, the main application and sub-applications a1~a1 are separated. n The front-end resources are deployed in different domains, while 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~a1. n Front-end resources b1~b n Unlike a domain, from the perspective of the frontend, sub-applications a1~a2 are different. n The application can only delegate the request to the server 20 where the unsplit backend service is located, and cannot directly request the corresponding business data from the server 20.

[0146] Figure 9A This is an example diagram of the sub-application loading method provided in the embodiments of this application.

[0147] refer to Figure 9A The business management application includes a client and a server. The client runs on computer 10, and the server runs on server 20. The client includes a main application and a sub-application a1, where the main application includes a directory module. The server includes backend services. The method includes the following steps:

[0148] S201: The main application on computer 10 detected that the user clicked on control P1 of sub-application a1.

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

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

[0151] refer to Figure 9B The main application creates an iframe container—window V1—for the child application a1, and loads the child application a1 into this iframe container.

[0152] S203: Sub-application a1 sends request parameters to the main application.

[0153] refer to Figure 9B Sub-application a1 can send request parameters to the main application based on the PostMesage mechanism to indicate the parameters of the data of business 1, such as the type, length, and format of the data of business 1.

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

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

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

[0157] refer to Figure 9B After receiving a request from sub-application a1, the backend service running on server 20 returns the data for business 1 to sub-application a1 based on the request.

[0158] S206: The main application returns data for business 1 to the sub-application a1.

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

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

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

[0162] In this embodiment of the application, according to Figure 9A and Figure 9B As can be seen, the sub-application does not directly request business data from the backend service, but instead delegates the request to the main application. Furthermore, the main application does not directly load the sub-application, but loads it as a remote resource. Based on this, when migrating a web application from a monolithic architecture to a micro-frontend architecture, the frontend resources of the web application can be gradually separated as needed, achieving a lightweight migration of the web application.

[0163] In some embodiments, after the front-end resources of a web application are decoupled, the back-end services of the web application can also be decoupled.

[0164] For example, refer to Figure 10 The front-end resources of the business management application are split into sub-applications a1~a1. n Front-end resources b1~b n Then, its backend service can be split into sub-applications a1~a2. n Backend services c1~c n Among them, the main application and sub-applications a1~a n They belong to different domains.

[0165] It is 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:

[0166] Phase 1: Decouple front-end resources only, without decoupling back-end services.

[0167] Phase Two: Decoupling Backend Services.

[0168] Since the decoupling of front-end resources does not depend on the decoupling of back-end services, Phase Two is optional. That is, when migrating a monolithic web application to a micro-frontend architecture, Phase Two can be executed or not. In this way, a gradual migration of web applications to a micro-frontend architecture can be achieved.

[0169] The technical solution of this application will be introduced below, taking the execution of both Phase 1 and Phase 2 as an example.

[0170] Figure 11 This is a schematic diagram of another micro-frontend architecture provided for an embodiment of this application.

[0171] refer to Figure 11 The architecture comprises a sub-application web layer, a main application web layer, a sub-application service layer, and a 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.

[0172] The sub-application web layer includes the sub-application user interface (UI) module and the first request processing module.

[0173] The sub-application UI module is used to provide the UI for sub-applications.

[0174] The first request processing module integrates a sub-application request forwarding plugin. This plugin is used to communicate with the second request module of the main application's web layer, such as sending simulated requests (requests that are not actually sent to the server) to the second request processing module and receiving responses from the second processing module.

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

[0176] The directory module integrates a route-based traffic parsing plugin, which is used to parse the path of the directory corresponding to the control clicked by the user and load the application corresponding to that path.

[0177] Customized routes are used to manage routing rules, such as a unified entry point, defining routes for public pages, and controlling access permissions.

[0178] The remote container module is used to create iframe containers and load child applications within them. An iframe container can be viewed as a separate window that loads remote resources.

[0179] The second request processing module integrates a main application request processing plugin. This plugin communicates with the first request processing module in the sub-application's web layer, such as receiving simulated requests from the first request processing module and sending responses to it. Additionally, this plugin also communicates with the service routing in the sub-application's service layer, such as sending real requests (actual requests sent to the server) to the service routing and receiving responses from it.

[0180] The sub-application service layer includes its own set of interfaces and service routes.

[0181] It has its own set of interfaces to provide various types of interfaces, such as basic authentication (e.g., login authentication, logout authentication), user management, permission management, data management, and configuration management.

[0182] The server routing system integrates a server proxy forwarding plugin, which is used to communicate with the second request processing module of the main application's web layer. This includes receiving actual requests sent by the second request processing module and returning responses to it.

[0183] The sub-service cluster includes service layers A, B, C, D, and E, which are used to provide decoupled backend services.

[0184] In some embodiments, when the directory module of the sub-application's web layer detects that a user clicks on a control in the sub-application, the web application can create an iframe container through the remote container module and load the sub-application within that iframe container. When the sub-application's 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's web layer can send a simulated request to the second request processing module of the main application's web layer through the sub-application request forwarding plugin. Then, the second request module can send the real request to the service route of the sub-application's service layer through the main application request processing plugin. Then, the service route can forward the real request to service layer E through the server proxy forwarding plugin. Then, service layer E returns the response result of the real request to the second request processing module through the service route, and the second request processing module then forwards the response result to the first request processing module.

[0185] In some embodiments, the aforementioned route-based traffic splitting and parsing plugin, main application request processing plugin, and sub-application request forwarding plugin are all less than 10kb in size. Due to their small size, they are easier to develop and can be adapted to a wide range of application scenarios.

[0186] It is understood that in this embodiment of the application, communication between the main and sub-applications can be achieved simply by inserting a sub-application request forwarding plugin into the first request processing module of the sub-application Web layer and a main application request processing plugin into the second request processing module of the main application Web layer, without involving complex modifications to the main and sub-applications.

[0187] It's understandable that using integrated plugins to achieve data transfer between the main and sub-applications offers strong scalability, high similarity between the separate, purely static management console pages, and the ability to build upon them using open-source low-code frameworks. Furthermore, it supports migration based on routes as the smallest unit, resulting in a relatively smooth migration process.

[0188] The following is about Figure 11 The micro-frontend architecture shown here employs an application separation mechanism, an application communication mechanism, and a data management mechanism.

[0189] 1. Apply separation mechanism

[0190] In some embodiments, front-end resources can be separated using an iframe container loading mechanism.

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

[0192] It's understandable that when using an iframe container-based loading mechanism to separate front-end resources, the main application and sub-applications belong to different domains. In this case, the sub-application's path should be configured as an absolute path, not a relative path.

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

[0194] like Figure 12As shown, the web browser on computer 10 runs the client of the business management application based on the URL "www.aaa.xxx" in the current navigation bar 15, and displays the homepage Q1 of the business management application client. The homepage Q1 displays the main page M2 of the main application. When the client detects that the user clicks on the control P1 through the directory module of the main application, it changes the URL in the navigation bar 15 to "www.bbb / yewu1.xxx", and creates an iframe container for the sub-application a1—window V1—to display it. Then, based on the changed URL "www.bbb / yewu1.xxx", it displays the page G1 of the sub-application a1 in window V2.

[0195] It is understandable that when creating an iframe container for a sub-application on the client side, the sub-application needs to be associated with the iframe container so that each sub-application can be displayed in its corresponding iframe container and to avoid display abnormalities.

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

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

[0198] Figure 13 A flowchart illustrating the sub-application page display method provided in this application embodiment.

[0199] refer to Figure 13 The method includes the following steps:

[0200] S301: The client detected that the user clicked on control A.

[0201] In some embodiments, when a user clicks on control A on the page displayed by the client, the client can detect that the user has clicked on control A through the main application's directory module.

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

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

[0204] It is understandable that if the client determines that the path corresponding to control A is not a path of a 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 a path of a sub-application, it means that the control A clicked by the user is a control of a sub-application, and then step S304 is executed.

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

[0206] 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 indicates that control A is a control of the main application, and the client loads the main application according to the path of control A.

[0207] For example, refer to Figure 14 Computer 10 loads the client of the business management application through a web browser. The client is currently displaying 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 of control P0 "www.aaa.xxx".

[0208] S304: The client creates an iframe container based on the path corresponding to control A and generates the iframeID corresponding to the iframe container.

[0209] 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 the iframeID corresponding to the iframe container based on the path corresponding to control A.

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

[0211] For example, the client can 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.

[0212] For example, refer to Figure 15Computer 10 loads the client of the business management application through a web browser. The client is currently displaying the main page M2 of the main application. After the client detects that the user clicks on control P1, it creates window V2 (as an iframe container) to load the sub-application a1, and uses the path "www.bbb / yewu1.xxx" corresponding to control P1 as the iframeID of window V2.

[0213] S305: The client creates a request forwarding instance and associates it with the iframeID.

[0214] In some embodiments, the client can create an instance of a sub-application delegating a request to the main application and associate that instance with the iframeID corresponding to the sub-application.

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

[0216] S306: The client listens for the loading event of the iframe container.

[0217] In some embodiments, when the client detects that the iframe container corresponding to the sub-application has been created, the client listens for the iframe container's loading event and needs to load the corresponding sub-application through the created iframe container.

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

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

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

[0221] In this embodiment, the client loads the sub-application as a remote resource through an iframe container, enabling front-end separation of the web application. Furthermore, when the client creates the iframe container for loading the sub-application, it generates an iframeID for that iframe container, ensuring that the sub-application is loaded into the correct iframe container and avoiding the anomaly of mismatched sub-applications loaded by multiple iframe containers simultaneously.

[0222] In some embodiments, when a client loads a sub-application through an iframe container, a lazy loading mechanism can be used. Lazy loading refers to loading resources dynamically based on the user's actual needs (such as scrolling to a certain position) instead of 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.

[0223] 2. Request Delegation Mechanism

[0224] Understandable. Figure 11 In the micro-frontend architecture shown, the main application and each sub-application belong to different domains. Under these circumstances, the main application and each sub-application cannot communicate directly across domains.

[0225] Therefore, in some embodiments, a request delegation mechanism based on the PostMessage mechanism can be used to realize communication between the main and sub-applications.

[0226] It is understandable that when a sub-application requests data from the server, the sub-application itself does not send the actual request to the server, but instead delegates the request to the main application.

[0227] In some embodiments, a sub-application can send a simulated request to the main application based on the PostMessage mechanism, and then delegate the main application to send a real request to the server through the simulated request.

[0228] In some embodiments, simulated requests include, but are not limited to, normal requests, file download requests, file upload requests, and other similar requests.

[0229] A normal request refers to a standard HTTP request.

[0230] In some embodiments, the sub-application can package the interface name and request body, etc., into JSON format and send it as a regular request to the main application. Upon receiving this regular request, the main application sends the corresponding actual request to the server. Upon receiving the actual request, the server returns the corresponding response data to the main application. The main application then returns this response data to the sub-application.

[0231] A file upload request refers to a request to upload a file to a server over a network.

[0232] 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 this file upload request and sends it to the server. This real request includes the file data to be uploaded. Once the main application sends this real request to the server, the file can be uploaded. After the main application completes the upload, it can return the upload result to the sub-application.

[0233] In some embodiments, to prevent reference loss and data integrity breaches, the sub-application can convert the file to be uploaded into a Base64 encoded string using the first request processing module (this can be achieved by reading the file content and encoding it into Base64), and then package the Base64 encoded string of the file along with necessary metadata (such as filename, file type, etc.) into JSON format as a file upload request. The sub-application can then send this 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 this real request to the server.

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

[0235] 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 download request includes the file's URL or other necessary information. Upon receiving the sub-application's file download request, the main application parses the request content and extracts the URL of the file to be downloaded. Then, the main application constructs a real request based on this URL and sends it to the server. Upon receiving this real request, the server returns the corresponding file data to the main application; that is, the main application downloads the corresponding file from the server.

[0236] In some embodiments, once the main application has finished downloading, it only needs to return the successful download result to the sub-application.

[0237] It is understandable that the simulated request sent by the sub-application to the main application is not the actual request, but rather the request parameters sent to the main application. The main application then generates the corresponding real request based on these request parameters and sends it to the backend.

[0238] In some embodiments, the steps for a sub-application to delegate a request to the server to the main application are as follows:

[0239] (1) Wrap the delegate and response events into Promise to make the development experience of the sub-application consistent with the real request.

[0240] In some embodiments, events where a sub-application delegates a request to the main application to send a request to the server, and events where the server responds to the request delegated by the sub-application to the main application, can be wrapped with Promises to make the development experience of the sub-application consistent with that of a real request.

[0241] It can be understood that the sub-application delegates 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 the real request corresponding to the simulated request and sends it to the server.

[0242] (2) Use request parameters and interface name to generate unique event identifiers to ensure the context association of a single request.

[0243] In some embodiments, each request and its associated response can be correctly associated by creating a unique identifier based on request parameters and interface name.

[0244] Specifically, you can first extract all relevant parameters from the request, and then obtain the target interface name or path of the request. Next, sort the extracted parameters to ensure that identical parameters always produce the same order, and concatenate the sorted parameters with the interface name to form a string. Then, apply a hash function (such as SHA-256) to this string to generate a fixed-length hash value.

[0245] Typically, for ease of transmission and processing, only a portion of the hash value can be used as a unique identifier. This unique identifier can be included in the request header or body when initiating a request. The response also includes this unique identifier, allowing the main application to match requests and responses based on it.

[0246] The main application can record each unique identifier and its corresponding request status (e.g., using a hash table). When the main application receives a response, it uses the unique identifier in the response to look up the request status and updates or clears the corresponding record.

[0247] (3) Send the iframeID to the main application, and the main application manages the data channel of the sub-application.

[0248] In some embodiments, when a sub-application delegates a request to the main application, the sub-application can send the iframeID 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 iframeID. For the sake of coherence, the data transmission management method will be described below.

[0249] (4) Release the corresponding listener promptly after the request is completed.

[0250] In some embodiments, when the event in which the sub-application delegates the request to the main application to send a request to the server is completed, the listening event for the sub-application delegating the request to the main application to send a request to the server is released (released).

[0251] 3. Data Channel and Request Management

[0252] (1) Data channel management between main and sub-applications

[0253] It's understandable that a micro-frontend architecture web application typically includes a main application and multiple sub-applications. Therefore, the main application needs to send data to multiple sub-applications. To prevent data transmission errors—for example, the main application might mistakenly send data intended for sub-application a1 to sub-application a2—it's necessary to manage the data channels between the main and sub-applications.

[0254] In some embodiments, a unique iframeID can be added to the simulated request sent by the sub-application to the main application and the response returned by the main application to the sub-application. This unique iframeID associates the main application and the sub-application, preventing errors in data transmission between the main and sub-applications. The iframeID is an ID generated by the main application based on the sub-application's path when creating the iframe container for the sub-application.

[0255] (2) Multi-request management

[0256] 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 needed 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—it needs to manage the requests from sub-applications (requests delegated by the main application to the server).

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

[0258] As we can understand, RPC is a form of inter-process communication (IPC) that allows a computer program to call a program on another network as if it were a local subroutine, without needing to know the details of the underlying network protocol.

[0259] In some embodiments, when a sub-application delegates a real request to the main application to send 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 that different sub-applications delegate to the main application to send to the server, thereby avoiding errors in the real requests that sub-applications delegate to the main application to send to the server.

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

[0261] As can be understood, 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 the front-end devices will be referred to as front-end sub-applications, and the main application on the front-end devices will be referred to as front-end main applications.

[0262] Figure 16 An interaction diagram of a front-end sub-application, a front-end main application, and a back-end service is provided for an embodiment of this application.

[0263] refer to Figure 16 When the front-end sub-application sends a request to the back-end service, it does not send the request directly. Instead, it sends a simulated request to the second request module of the front-end main application through the first request processing module. The second request processing model of the front-end main application then generates a real request based on this 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. Then, the front-end main application returns the response to the front-end sub-application through the second request module.

[0264] In some embodiments, when the simulated request sent by the current sub-application to the main frontend application is a file download request, the main application sends a real request to the backend service to download the file, and then the backend service returns the corresponding file data to the main application. In this case, the main frontend application handles the file download through an outer layer; that is, the frontend sub-application downloads the corresponding file data through the main frontend application.

[0265] In some embodiments, ordinary requests sent from a front-end subapplication to a main front-end application can be sent in the form of an object. File requests sent from a front-end subapplication to a main front-end application, such as file download requests and file upload requests, can be sent in base64 format.

[0266] Figure 17This is a flowchart illustrating a business processing method provided in an embodiment of this application. The business processing method is used in a business system, which includes a client and a server. The client includes a main front-end application and multiple front-end sub-applications, while the server includes a back-end service. The client runs on a front-end device, and the server runs on a back-end device. The following description continues by using a computer as an example of a front-end device and a server as an example of a back-end device. In some embodiments, the business management system may be as described above. Figure 11 The micro-frontend architecture shown includes, but is not limited to, online shopping applications, social networking applications, enterprise resource management applications, and business management applications. The following section will continue with a business management system as an example of a business management application.

[0267] refer to Figure 17 The method includes the following steps:

[0268] S401: The front-end device loads the client.

[0269] It's understandable that the client's data is deployed on the backend device.

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

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

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

[0273] In some embodiments, the URL of the business system is the same as the URL of its main front-end application. For example, such as Figure 18 As shown, the URL of the business management application is "www.aaa.xxx", and the URL of its main front-end application is also "www.aaa.xxx".

[0274] S402: The client on the front-end device displays a first interface, which includes controls for multiple front-end sub-applications, including the first front-end sub-application.

[0275] In some embodiments, after the front-end device loads the client of the business system, the client displays a first interface. The first interface includes controls for multiple front-end sub-applications, and the multiple front-end sub-applications include a first front-end sub-application.

[0276] For example, such as Figure 18 As shown, after the client of the business management application is loaded on computer 10, the client displays the homepage Q1 (as an example of the first interface). Homepage Q1 includes the control P0 of the main front-end application and the front-end sub-applications a1~a1. n The controls P0~Pn.

[0277] S403: The client of the front-end device detected the trigger event of the first control of the first front-end sub-application in the first interface.

[0278] In some embodiments, the client of the front-end device detects a trigger event of a first control of a first front-end sub-application in a first interface, such as detecting a user clicking the first control.

[0279] For example, such as Figure 19 As shown, the client of the business management application on computer 10 detects 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 through the main application.

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

[0281] The first request is used to request the first business data.

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

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

[0284] In some embodiments, step S404 includes the following sub-steps:

[0285] S4041: The first front-end application sends the first parameter to the front-end main application.

[0286] It is understandable that, since the first front-end sub-application and the main front-end application belong to different domains, they are subject to the cross-domain restrictions of the same-origin policy adopted by the web browser, which prevents them from communicating directly.

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

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

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

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

[0291] In some embodiments, when the main front-end application generates the first request, it can use a national cryptographic digest algorithm to hash the interface parameters (such as the interface name and other parameters) of the interface called when sending the actual request (as the first interface), generating a fixed-length digest value as the requestID (as the first identifier), and marking the first request using the requestID. This allows the first request to be identified through the requestID, preventing errors in sending and responding to the first request.

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

[0293] 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.

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

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

[0296] 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 business data to the client on the frontend device. For example, as shown... Figure 19 As shown, after receiving the real request sent by the client of the business management application on computer 10, the server of the business management application on server 20 sends the data of business 1 to the client of the business management application on computer 10.

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

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

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

[0300] 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, thus avoiding mismatches in loading the iframe container of the first front-end sub-application.

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

[0302] In other embodiments, the client can generate a random number based on a random function, then combine the path corresponding to the first control with the random number, and use the combination result as the iframeID of the iframe container for loading the first front-end sub-application.

[0303] It should be noted that the specific method for the client to generate the iframeID can be found in the relevant introduction of step S304 above, and will not be repeated here.

[0304] In this embodiment of the application, the front-end sub-application can send requests to the back-end service by delegating the front-end main application, thereby enabling cross-domain communication between the sub-application and the back-end service. This allows the front-end sub-application to request the corresponding business data from the back-end service to process the corresponding business.

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

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

[0307] It is understandable that multiple front-end sub-applications in the client can be deployed partly on a second back-end device and partly on at least one third back-end device, or all of them can be 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.

[0308] This application's embodiments achieve the coexistence and efficient interaction of sub-applications in a multi-tab mode (parallel coexistence in a multi-tab environment) by subdividing delegate requests into specific categories and precisely managing data channels and events between master and sub-applications.

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

[0310] 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 processors 110, memories 120, and communication interfaces 130 can be coupled via a bus (not shown), which can provide a pathway for transmitting information between the various components of the device 100 (e.g., processors 110, memories 120, and communication interfaces 130).

[0311] The processor 110 may include any one or more of the following processors: central processing unit (CPU), graphics processing unit (GPU), microprocessor (MP), digital signal processor (DSP), baseband processor (BP), application processor (AP).

[0312] 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, hard disk drive (HDD), or solid state drive (SSD).

[0313] 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 front-end / back-end device, thereby implementing the aforementioned business processing method. That is, the memory 106 stores instructions for executing the business processing methods provided in the embodiments of this application.

[0314] In some embodiments, the processor 110 can execute the business processing method by executing instructions of the business processing method stored in the memory 120. For example, the processor 110 detects a trigger event of a first control of a first front-end application, generates a first request of the first front-end application, generates a first identifier based on the interface parameters of a first interface, marks the first request with the first identifier, and obtains the first identifier by hashing the interface parameters of the first interface using a national cryptographic digest algorithm.

[0315] 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.

[0316] It should be noted that the terminology used in the implementation section of the embodiments of this application is only used to explain the specific embodiments of this application and is not intended to limit this application. In the description of the embodiments of this application, unless otherwise stated, " / " means "or", for example, A / B can mean A or B; "and / or" in this document is merely a description of the association relationship of related obstacles, indicating that three relationships can exist. For example, A and / or B can represent: A alone, A and B simultaneously, and B alone. In addition, in the description of the embodiments of this application, unless otherwise stated, "multiple" means two or more, "at least one" or "one or more" means one, two or more.

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

[0318] Hereinafter, the terms "first" and "second" are used for descriptive purposes only and should not be construed as indicating or implying relative importance or implicitly specifying the number of technical features indicated. Thus, a feature defined as "first" or "second" may explicitly or implicitly include one or more of that feature.

[0319] References to "one embodiment" or "some embodiments" as used in this specification mean that one or more embodiments of this application include a specific feature, structure, or characteristic described in connection with that embodiment. Therefore, the phrases "in one embodiment," "in some embodiments," "in other embodiments," "in still other embodiments," etc., appearing in different parts of 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 "comprising," "including," "having," and variations thereof mean "including but not limited to," unless otherwise specifically emphasized.

[0320] In the above embodiments, implementation can be achieved entirely or partially through software, hardware, firmware, or any combination thereof. When implemented using software, it can be implemented entirely or partially 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 through 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, fiber optic, digital subscriber line) or wireless (e.g., infrared, wireless, microwave, etc.) means. The computer-readable storage medium can be any available medium that a computer can access or a data storage device such as a server or data center that integrates one or more available media. The available medium can be a magnetic medium (e.g., floppy disk, hard disk, magnetic tape), an optical medium, or a semiconductor medium (e.g., a solid-state disk (SSD)).

[0321] Those skilled in the art will understand that all or part of the processes in the methods of the above embodiments can be implemented by a computer program instructing related hardware. The program can be stored in a computer-readable storage medium, and when executed, it can include the processes of the above method embodiments.

[0322] The above description is merely a specific implementation of the embodiments of this application, but the protection scope of the embodiments of this application is not limited thereto. Any changes or substitutions within the technical scope disclosed in the embodiments of this application should be covered within the protection scope of the embodiments of this application. Therefore, the protection scope of the embodiments of this application should be determined by the protection scope 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 main front-end application and multiple front-end sub-applications. The server includes a back-end service that provides services to the multiple front-end sub-applications. The main front-end application and the sub-application belong to different domains, while the main front-end application and the back-end service belong to the same domain. Furthermore, the method includes: The client displays a first interface, which includes controls for the plurality of front-end sub-applications, including the first front-end sub-application. The client detects a trigger event of the 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 first request from the client to the backend service of the server, which is the first request from the first frontend sub-application, includes: The first front-end application sends a first parameter to the front-end main application; The main front-end application generates the first request based on the first parameter; The front-end 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 the interface parameters of a first interface. The first interface is the interface called by the front-end main application when sending the first request, and the interface parameters include the interface name.

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

4. The method according to any one of claims 1 to 3, characterized in that, The method further includes: Before receiving the first service data, the client creates a first container for displaying the interface corresponding to the first front-end sub-application. After receiving the first service data, the client displays the second interface corresponding to the first service 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 application, and after the client receives the first service data, it displays a second interface corresponding to the first service data in the first container, including: Based on the second identifier, the first container corresponding to the first service data is determined; 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: Parameters for indicating the type of the first business data, parameters for indicating the length of the first business data, and parameters for indicating the format of the first business data.

7. A business processing method, applied to a system including front-end devices and back-end devices, characterized in that, The front-end device runs a client, and the back-end device deploys a server, a main front-end application, and multiple front-end sub-applications. The server includes a back-end service that provides services to the multiple front-end sub-applications. The main front-end application and the back-end service on the back-end device belong to the same domain, while the front-end sub-applications on the back-end device belong to different domains than the main front-end application. Furthermore, the method includes: The front-end device obtains the main front-end application and the multiple 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 trigger event of a first control in the first interface, wherein the first control is a control corresponding to the 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 business data; The backend service sends the first business data to the frontend device; The first request sent by the front-end device to the back-end service of the back-end device for the first front-end sub-application 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 main front-end 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 devices include 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 some of the frontend sub-applications are deployed on the at least one third backend device.

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

11. A computer-readable storage medium, characterized in that, The computer-readable storage medium stores instructions that, 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, Includes a computer program / instruction that, when executed, causes a computer to perform the method of any one of claims 1 to 6 or claims 7 to 9.

Images