Page loading method and device and related equipment

Abstract

The invention provides a page loading method and device and related equipment.The method comprises the steps that a client side responds to loading operation of a page of an application, M loading requests of M services needing to be loaded on the page are obtained, then a merging strategy configured by a user is obtained, N loading requests in the M loading requests are merged according to the merging strategy, and N is a positive integer; a merging request is generated, and N services corresponding to the N requests are provided by the same server side. The client side sends a merging request to the server side to indicate the server side to execute the merging request, then receives an execution result of the merging request returned by the server side, analyzes the execution result into a request result corresponding to each loading request in N loading requests, and sends the request result to the server side; and displaying the request result to the position of the service corresponding to each loading request in the N loading requests in the page. Based on the method provided by the invention, the number of times of interaction between the client and the server can be reduced, and the page loading speed can be improved.

Description

Technical Field

[0001] The present application relates to the field of information technology (IT), and in particular to a page loading method, apparatus, and related equipment. Background Art

[0002] When a user enters a Uniform Resource Locator (URL) on a client to access a website page, the client generates a Hypertext Transfer Protocol (HTTP) request and sends it to the server, requesting the resource data associated with the page. The server retrieves the resource data associated with the page based on the HTTP request and returns the resource data to the client, which then completes the page loading process based on the returned resource data.

[0003] For complex web pages, clients often need to send dozens of HTTP requests to the server to retrieve different resource data. Each HTTP request generates an interaction between the client and the server, so the client needs to interact with the server multiple times to complete the page data loading. This excessive number of interactions between the client and the server results in excessive processing pressure on the server and slow page loading speeds on the client. Summary of the Invention

[0004] The present application provides a page loading method, apparatus, and related equipment, which can reduce the number of interactions between the client and the server and improve the page loading speed.

[0005] In the first aspect, the present application provides a page loading method, which includes: the client responds to the loading operation of the application page, and obtains M loading requests for M services that the page needs to load; the client obtains the merge strategy configured by the user, merges N loading requests among the above M loading requests according to the merge strategy, and generates a merge request, wherein the N services corresponding to the N requests are provided by the same server; the client sends the merge request to the server to instruct the server to execute the merge request, and then receives the execution result of the merge request returned by the server, parses the execution result into the request result corresponding to each of the above N loading requests, and displays the request result to the location of the service corresponding to each of the N loading requests in the page.

[0006] It can be seen that this solution supports users to configure a merge strategy for merging load requests. When a page on the client generates M load requests, the client can determine N load requests from the M load requests according to the merge strategy configured by the user, and then generate a merge request based on the N load requests, and then send the merge request to the server, thereby reducing the number of interactions between the client and the server. Among them, the above M and N are both positive integers greater than 1, and M is greater than or equal to N. The M services can correspond one-to-one with the M load requests, and each load request is used to request data for the corresponding service. When the client receives the execution result of the merge request returned by the server, it completes the page loading by parsing the execution result.

[0007] Based on the first aspect, in a possible implementation, a configuration interface can be provided by the client. The client receives the merge policy input by the user through the configuration interface and then stores the merge policy. In other words, the client can provide the configuration interface to the user so that the user can configure the merge policy through the configuration interface, so that the client can perform a merge operation according to the merge policy.

[0008] Based on the first aspect, in a possible implementation, the merge policy includes a collection time threshold, and the N load requests are generated within the collection time threshold. In other words, the user can configure the collection time threshold for load requests in the merge policy to instruct the client to merge load requests generated within the collection time threshold (such as the N load requests) to generate a corresponding merge request.

[0009] Based on the first aspect, in a possible implementation scheme, the merge strategy includes a collection time threshold, a waiting time threshold of a single load request collected within the collection time threshold, and / or a threshold for the number of load requests. When any of the above thresholds is reached, a merge operation is performed.

[0010] That is, the user can configure a collection time threshold for load requests in the merge policy, and can also configure a waiting time threshold for a single load request and / or a number threshold for load requests in the merge policy, so that the client can instruct under what circumstances to perform a merge operation. Among them, the indication function of the collection time threshold is as follows: if the collection time threshold is reached, the client performs a merge operation based on the multiple load requests collected within the collection time threshold. The indication function of the waiting time threshold is as follows: for multiple load requests collected within the collection time threshold, if the waiting time (generation duration) of any load request in these multiple load requests reaches the waiting time threshold, the client performs a merge operation on these multiple load requests. The indication function of the number threshold is as follows: for multiple load requests collected within the collection time threshold, if the number of these multiple load requests reaches the number threshold, the client performs a merge operation on these multiple load requests. That is, as long as any of the above thresholds is reached, the client performs a merge operation. If any of the above thresholds has not been reached, the client will not perform the merge operation temporarily until any of the above thresholds is reached, at which time the merge operation will be performed.

[0011] Based on the first aspect, in a possible implementation scheme, the merge strategy also includes dependencies between load requests. At this time, the client can identify X load requests that meet the dependency among the above-mentioned N load requests based on the dependency, and then carry the dependency corresponding to these X load requests in the merge request to instruct the server to execute these X load requests based on the dependency. In other words, the user can configure the above-mentioned dependency in the merge strategy to instruct the client to merge different load requests that meet the dependency to generate a merge request, which helps to reduce the number of interactions between the client and the server and improve the page loading speed. In addition, in order for the server to correctly handle the merge request, the client needs to add the dependency in the merge request to instruct the server to execute the corresponding load request based on the dependency.

[0012] Based on the first aspect, in a possible implementation scheme, the merge strategy also includes the correspondence between the service directory on the server and the above-mentioned N services. According to this correspondence, the client can recognize that the services corresponding to the N load requests among the M load requests generated by the page all belong to the same service directory, thereby merging the N load requests corresponding to the same service directory to generate a merge request. It should be noted that the user can configure the correspondence between each service directory and the corresponding service in one or more service directories in the merge strategy, thereby instructing the client to merge different load requests corresponding to services under the same service directory.

[0013] Based on the first aspect, in a possible implementation, the merge request uses the Graph Query Language (GQL). The client generates an HTTP request based on the merge request, with the payload (payload / request body) of the HTTP request including the merge request, and then sends the HTTP request to the server. In other words, the client can generate the merge request based on the GQL syntax, then package the merge request into an HTTP request, and then send the HTTP request to the server.

[0014] In the second aspect, the present application also provides a page loading device, which includes units and / or modules for executing the method of any implementation scheme in the first aspect. For details, please refer to the above introduction and will not be repeated here.

[0015] In a third aspect, the present application further provides a terminal device / computing device, comprising a processor, a memory, and a transceiver. The processor is configured to execute instructions stored in the memory, so that the terminal device / computing device executes the method of any embodiment of the first aspect.

[0016] In a fourth aspect, the present application further provides a computer-readable storage medium comprising computer program instructions. When the computer program instructions are executed by a computing device, the computing device executes the method of any embodiment of the first aspect.

[0017] In a fifth aspect, the present application further provides a computer program product comprising instructions. When the instructions are executed by a computing device, the computing device executes the method according to any one of the embodiments of the first aspect. BRIEF DESCRIPTION OF THE DRAWINGS

[0018] In order to more clearly illustrate the technical solutions in the embodiments of the present application, the following briefly introduces the drawings required for describing the embodiments.

[0019] Figure 1 This is a system architecture diagram provided by an embodiment of the present application;

[0020] Figure 2 This is a flow chart of a page loading method provided by an embodiment of the present application;

[0021] Figure 3 This is a schematic diagram of starting multiple runtime instances to achieve parallel processing, provided by an embodiment of the present application;

[0022] Figure 4 This is a structural diagram of a page loading device provided in an embodiment of the present application;

[0023] Figure 5 It is a structural diagram of a computing device provided in an embodiment of the present application. DETAILED DESCRIPTION

[0024] To facilitate understanding of the technical solutions of the embodiments of the present application, a system architecture involved in the embodiments of the present application is first introduced below.

[0025] See Figure 1 , Figure 1 This is a system architecture diagram provided by an embodiment of the present application, including a client 100 and a server 200. There is a communication connection between the client 100 and the server 200, which can be a wired connection or a wireless connection. The number of clients 100 that establish a communication connection with the server 200 can be one or more ( Figure 1 Taking a client 100 as an example), this embodiment of the present application does not make any specific limitations.

[0026] The client 100 is used to implement human-computer interaction and can be deployed on a terminal device or a computing device. The terminal device can be a smartphone, wearable device, laptop, tablet computer, vehicle-mounted device, or smart conference device, and the computing device can be a server, personal computer (PC), etc., which are not specifically limited in the embodiments of the present application.

[0027] In some specific implementations, the above-mentioned client 100 can be an application (APP) client / mobile client running on a mobile terminal such as a smart phone, wearable device, etc., or it can be software or application running on a computing device (such as a PC client, desktop APP), or it can be a web client accessed based on a web browser, or it can be a front-end console (console) of a cloud platform, and the embodiments of this application do not make specific limitations.

[0028] The above-mentioned server 200 is used to provide the required data to the client 100, and can be deployed on a computing device, a computing device cluster consisting of multiple computing devices, or a terminal device. Among them, the computing device can be a physical computing device, such as a bare metal server (Bare Metal Server, BMS), an edge computing device, or a virtual computing device, such as a virtual machine, a container. BMS refers to a general physical server, for example, an ARM server or an X86 server; a virtual machine refers to a complete computer system with complete hardware system functions that runs in a completely isolated environment simulated by software. Any work that can be done in a physical computer can be achieved in a virtual machine. When creating a virtual machine in a computing device, part of the hard disk and memory capacity of the physical machine needs to be used as the hard disk and memory capacity of the virtual machine. Each virtual machine has an independent basic input / output system (CMOS), hard disk and operating system, and can be operated like a physical machine; a container is a portable software unit that can combine an application and all its dependencies into a software package that is not restricted by the underlying host operating system. This eliminates the need to build a complex environment, simplifying the process from application development to deployment; edge computing devices refer to devices that are closer to data sources and end users and have low latency and high bandwidth characteristics, such as smart routers, edge servers, etc. A computing device cluster may include multiple of the above-mentioned computing devices, such as a data center, which is not specifically limited in this application; the description of the terminal device can refer to the aforementioned content and will not be repeated here.

[0029] In some specific implementations, the server 200 may be a cloud platform that utilizes a serverless architecture, i.e., a serverless platform. Serverless architecture is a cloud computing service model provided by cloud service providers that allows developers to build and / or run their own business code / applications on the cloud platform without having to worry about the operation, maintenance, and management of servers (physical or virtual computing devices). The cloud service provider is responsible for the operation, maintenance, and management of the servers. Serverless architecture offers elastic scaling and strong concurrency capabilities. It can automatically allocate server resources on demand (dynamically expand and shrink), thereby achieving higher resource utilization and cost-effectiveness.

[0030] Optionally, the client 100 and server 200 can be deployed on the same terminal device or computing device; alternatively, the client 100 can be deployed on a terminal device, and the server 200 can be deployed on a single computing device or a cluster of computing devices. It should be understood that the above examples are for illustration only, and the specific deployment of the client 100 and server 200 can be determined based on the actual application scenario.

[0031] Furthermore, the client 100 and the server 200 can be divided into multiple unit modules. Figure 1 An exemplary division method of the client 100 and the server 200 is given. The client 100 includes an interaction module 101, a merging module 102, a transceiver module 103, a parsing module 104 and a storage module 105 (type is not limited), wherein the interaction module 101 is used for human-computer interaction with the user, the merging module 102 is used to perform a merge operation and generate a merge request, the transceiver module 103 is used to communicate with the server 200, the parsing module 104 is used to parse the execution result of the merge request returned by the server 200, and the storage module 105 is used to store page code, merge strategy (described later), etc. The server 200 includes a transceiver module 201 and a parsing execution module 202, wherein the transceiver module 201 is used to communicate with the client 100, and the parsing execution module 202 is used to parse the merge request sent by the client 100, and then call the services deployed on the server 200 (such as the first service, the second service and the third service, which are only used as examples here) to obtain the required service data.

[0032] It should be noted that Figure 1 The division of the client 100 and the server 200 is only an example and does not constitute a specific limitation. In actual application scenarios, Figure 1 The client 100 and the server 200 may also include more or fewer modules, for example, Figure 1 A module in the can be split into multiple functional modules, or Figure 1 Two or more modules in the program can be combined into one functional module. Figure 1 Other functional modules are added to the client 100 and the server 200, which are not specifically limited in the embodiments of the present application.

[0033] based on Figure 1 The system architecture of the present invention is described below. An embodiment of the page loading method provided by this application is introduced below.

[0034] See Figure 2 , Figure 2 This is a flowchart of a page loading method provided in an embodiment of the present application, including steps S201 to S206.

[0035] S201. The client 100 responds to the loading operation of the application page and obtains M loading requests of M services that need to be loaded on the page.

[0036] Specifically, such as Figure 1As shown, a user can perform a loading operation for an application page on the interactive module 101 of the client 100. For example, the user can input the Uniform Resource Locator (URL) address corresponding to the page into the interactive module 101 to implement the loading operation for the page. Then, the interactive module 101 responds to the page loading operation and generates M loading requests corresponding to the M services that need to be loaded based on the page code of the page, and sends these M loading requests to the merging module 102. The merging module 102 obtains these M loading requests to perform a subsequent merging operation (described later).

[0037] The above application can be a web application accessed based on a web browser, a mobile APP running on a mobile device operating system, a desktop APP running on a desktop operating system, etc., and the embodiments of this application do not make specific limitations.

[0038] The above-mentioned M is a positive integer greater than 1, and the M services can correspond one-to-one to the M loading requests, and each loading request is used to request the data of the corresponding service. It should be noted that the above-mentioned service can be a back-end service, a serverless function or a microservice, and each service is an independent and autonomous service unit (i.e., an atomic service), and each service has its own database or data storage for storing and managing the data of this service. The above-mentioned M services may be deployed on the same server 200, or the M services may be deployed on multiple server terminals 200 (each server terminal 200 provides some of the M services), and some of the M services may be deployed separately on traditional servers (not using a serverless architecture), which is not specifically limited in the embodiments of the present application.

[0039] For example, assume that a server 200 has a user service and an order service deployed on it. Each service provides a set of interfaces or application programming interfaces (APIs) for operating and managing the data of the service. The user service is responsible for managing user data, including the user's name, address, and contact information; the order service is responsible for managing order data, including the order number, product list, payment status, etc.

[0040] Assuming that one of the above-mentioned M services is the above-mentioned order service, and one of the above-mentioned M loading requests corresponding to the order service requires the order data provided by the order service, then the loading request may include the API provided by the order service for obtaining order data, so as to request the server 200 to obtain the order data provided by the order service.

[0041] Assuming that another service among the above-mentioned M services serves the above-mentioned user service, and one of the above-mentioned M loading requests corresponding to the user service requires user data provided by the user service, then the loading request may include an API provided by the user service for obtaining order data, so as to request the user data provided by the user service from the server 200.

[0042] It should be noted that the service names, number of services, and data provided by each service in this example are only examples and do not constitute specific limitations. In actual application scenarios, the server 200 can also provide more or fewer services, and the service types are not specifically limited.

[0043] S202: The client 100 obtains a merge strategy configured by the user, merges N load requests among the M load requests according to the merge strategy, and generates a merge request.

[0044] The N services corresponding to the N requests are provided by the same server 200. That is, N of the M services that the page needs to load are deployed on the same server 200. These different load requests corresponding to services on the same server 200 are allowed to be merged (i.e., allowed to be merged into the same merge request) to generate a merge request, which is used to request the data of the services required by these load requests from the above server 200. Conversely, different load requests corresponding to services on different servers 200 are not allowed to be merged and need to be sent to different servers 200 respectively.

[0045] How to determine whether the service corresponding to the loading request is deployed on the server 200 can be achieved in the following ways:

[0046] First, the merging module 102 in the client 100 can obtain the URL address in the load request, which is used to indicate the location of the service corresponding to the load request. Then, the merging module 102 parses the URL address and determines whether the URL address contains the URL address of the server 200. If so, it is determined that the service corresponding to the load request is deployed on the server 200. If not, it is determined that the service corresponding to the load request is not deployed on the server 200 (it may be deployed on another server 200 or other traditional server providing a single service).

[0047] For example, assuming that multiple services are deployed on a certain server 200 , the URL address of each of the multiple services includes the URL address of the server 200 .

[0048] Taking the user service and order service deployed on the server 200 as an example, for the user service, the URL address of the user service is https: / / example.com / api / users, and for the order service, the URL address of the order service is https: / / example.com / api / orders. It can be seen that the URL address of the user service and the URL address of the order service have the same part, namely https: / / example.com / api. This same part is the URL address of the server 200. In other words, for the URL addresses of different services on the same server 200, they have a same part (or a common part) to indicate the same server 200. Since the URL addresses of different servers 200 are different, the URL addresses of different services on different servers 200 do not have a same part to indicate the same server 200, so that the services provided by different servers 200 can be distinguished.

[0049] When the client 100 generates multiple load requests, the service corresponding to each load request and the server 200 where the service is located can be determined based on the URL addresses in the multiple load requests. If the URL addresses in two load requests both contain the URL address of the same server 200, it can be determined that the two load requests correspond to services on the same server 200. If the URL addresses in the two load requests contain the URL addresses of different servers 200, it can be determined that the two load requests correspond to services on different servers 200. It should be understood that if a load request cannot be merged with other load requests, the client 100 can directly send the load request to the location of the service corresponding to the load request, without performing a merge operation based on the load request.

[0050] How to obtain the user-configured merge strategy can be achieved as follows:

[0051] The client 100 provides a configuration interface, and then the client 100 receives the merge strategy input by the user through the configuration interface. This method can be applied to low-code scenarios that are mainly based on configuration. The configured merge strategy can be stored in the storage module 105 of the client 100, and then the client 100 can perform a merge operation based on the merge strategy.

[0052] The following is a detailed introduction to the merge strategy, which can include the following situations:

[0053] Case 1: The merge strategy includes a collection time threshold.

[0054] In this case, the user can configure a collection time threshold for load requests in the merge policy to instruct the client 100 to merge the load requests generated within the collection time threshold and generate a corresponding merge request. For example, assuming that the collection time threshold configured by the user in the merge policy is 100ms, the client 100 can merge the above-mentioned N load requests collected / generated within 100ms according to the merge policy, generate a merge request, and send the merge request to the server 200. Similarly, the client 100 can also merge multiple load requests collected within the next 100ms to generate a corresponding merge request, and then send the merge request to the server 200.

[0055] Case 2: The merging strategy includes a collection time threshold, a waiting time threshold of a single load request collected within the collection time threshold, and / or a threshold of the number of load requests. When any of the above thresholds is reached, a merging operation is performed.

[0056] In this case, the user can configure the collection time threshold for the loading request in the merge strategy, and can also configure the waiting time threshold for a single loading request and / or the number threshold of loading requests in the merge strategy to indicate under what circumstances the client 100 performs the merge operation (equivalent to giving the trigger conditions for the client 100 to perform the merge operation).

[0057] The indicative function of the collection time threshold is as follows: if the collection time threshold is reached, the client 100 performs a merge operation according to multiple load requests collected within the collection time threshold.

[0058] The waiting time threshold indicates the following: for multiple load requests collected within the collection time threshold, if the waiting time of one of the load requests has reached the waiting time threshold (even if the collection time threshold or quantity threshold has not yet been reached), the client 100 performs a merge operation on the multiple load requests. For example, the collection time threshold in the user-configured merge strategy is 100ms, and the waiting time threshold is 50ms. Assuming that three load requests (corresponding to the same service on the server 200) have been collected within the first 60ms of the collection time threshold, and the waiting time of one of the three load requests has reached 50ms, the client 100 will immediately perform a merge operation based on the three load requests, generate a merge request, and send it to the server 200. Subsequently, the client 100 can continue to collect new load requests within the last 40ms of the above-mentioned collection time threshold for performing the merge operation, or the client 100 can start calculating the next time threshold (the next time threshold uses the 60ms of the previous time threshold as the starting time), and collect the corresponding load requests at the next time threshold to perform the merge operation.

[0059] The indication function of the quantity threshold is as follows: for multiple load requests collected within the collection time threshold, if the number of these multiple load requests has reached the quantity threshold (even if the collection time threshold or the waiting time threshold has not yet been reached), the client 100 performs a merge operation on these multiple load requests. For example, the collection time threshold in the user-configured merge strategy is 100ms and the quantity threshold is 6. Assuming that 6 load requests (corresponding to the service on the same server 200) have been collected within the first 80ms of the collection time threshold, and the number of currently collected load requests has reached the quantity threshold, the client 100 will immediately perform a merge operation based on these 6 load requests, generate a corresponding merge request, and then send the merge request to the server 200.

[0060] In other words, the user can set a collection time threshold, a waiting time threshold, or a quantity threshold in the configuration policy. Once any of the thresholds set by the user is reached, the client 100 will perform a merge operation. If any of the thresholds has not been reached, the client 100 will not perform the merge operation until any of the thresholds is reached.

[0061] It should be noted that the above-mentioned collection time threshold, waiting time threshold, and quantity threshold can all be set by the user according to actual usage requirements, and the embodiments of this application do not make specific limitations.

[0062] Optionally, the merge strategy may also include dependencies between load requests. At this time, the client 100 can identify X load requests that meet the dependency among the above-mentioned N load requests based on the dependency configured in the merge strategy, and then carry the dependency of these X load requests in the merge request to instruct the server 200 to execute these X load requests based on the dependency. Wherein, N and X are both positive integers greater than 1, and N is greater than or equal to X. Of course, if there is no load request that meets the dependency among the N load requests, there is no need to carry the dependency in the merge request.

[0063] The above-mentioned dependency can be a result parameter dependency between load requests. A result parameter dependency between two load requests means that one of the two load requests uses the execution result of the other load request as an input parameter. Specifically, one load request can use part of the execution result of the other load request as an input parameter, or one load request can use all of the execution result of the other load request as an input parameter.

[0064] For example, assuming that the dependency configured by the user in the merge strategy is a result parameter dependency, the above N is 3, and X is 2, that is, the client 100 identifies that 2 load requests from the 3 load requests are in line with the dependency configured by the user in the merge strategy. Therefore, when the client 100 generates a merge request based on the 3 load requests, the dependency between the 2 load requests will be carried in the merge request to instruct the server 200 to execute the 2 load requests according to the dependency. When the server 200 receives the merge request, by parsing the dependency in the merge request, it can be determined to execute the above 2 load requests according to the dependency, that is, first execute the dependent load request, obtain the data of the service required by the load request, and obtain the execution result of the load request. Then, the server 200 uses the execution result of the previous load request as an input parameter to execute another load request, obtain the data of the service required by the other load request, and thus obtain the execution result of the other load request. When the server 200 completes executing the merge request, that is, obtains the execution results of each of the three loading requests, it can package the execution results of the three loading requests together as the execution result of the merge request and return it to the client 100, thereby reducing the number of interactions between the client 100 and the server 200.

[0065] Optionally, the merging strategy may further include a correspondence between the service directory on the server and the above-mentioned N services.

[0066] It should be understood that the service catalog is a collection of services organized and managed on the server 200. It is a centralized service registration and discovery mechanism for recording and managing available services. There can be one or more service catalogs on the server 200. Different service catalogs can be used to organize and manage services of different types or in different fields. Each service catalog can contain one or more services. The main purpose of distinguishing different service catalogs is to better organize and manage services, as well as to provide better maintainability and scalability. Different service catalogs may have different access rights, resource quotas, monitoring and logging features to meet the needs of different services.

[0067] In order to instruct the client 100 to merge different load requests corresponding to services under the same service directory, the user can configure the correspondence between the service directory and the services under the service directory in the merge policy. It should be understood that the user can configure only the correspondence between one service directory and the services under the service directory in the merge policy, or can configure the correspondence between each service directory in multiple service directories and the services under the service directory in the merge policy. Based on the above correspondence configured in the merge policy, the client 100 can identify (within the collection time threshold) which services corresponding to the load requests among all the collected load requests belong to the same service directory, and then the client 100 can merge the different load requests corresponding to the services under the same service directory, generate a corresponding merge request and send it to the server 200, so that the server 200 can process the merge request under the same service directory.

[0068] For example, assume that a server 200 deploys a first service, a second service, a third service, and a fourth service, where the first and second services belong to service directory A, and the third and fourth services belong to service directory B. The user can configure the correspondence between service directory A and the first and second services in the merge policy, and the correspondence between service directory B and the third service, to instruct the client 100 to merge different load requests corresponding to services under the same service directory.

[0069] For the M load requests, assuming that the client 100 recognizes that the services corresponding to N of the load requests all belong to service directory A, the client 100 can perform a merge operation based on these N load requests, generate a corresponding merge request, and send it to the server 200. For the other load requests other than the N load requests among the M load requests, if the services corresponding to them all belong to service directory B, the client 100 can generate another merge request based on them and send it to the server 200.

[0070] S203: The client 100 sends a merge request to the server 200 to instruct the server to execute the merge request. Correspondingly, the server 200 receives the merge request sent by the client 100.

[0071] S204. The server 200 parses and executes the merge request, and generates an execution result of the merge request.

[0072] As described in step S202 , the merge request is generated based on N load requests among the M load requests, and the merge request may carry dependencies between X load requests among the N load requests.

[0073] If the server 200 does not find any dependency in the merge request after parsing the merge request, it means that none of the N load requests meet the dependency relationship. At this time, the server 200 can start multiple runtime instances to execute the N load requests in parallel, thereby giving full play to the elastic concurrency advantages of the server-less architecture of the server 200.

[0074] If server 200 parses the merge request and discovers that the merge request carries a dependency relationship between X load requests, then X of the N load requests meet the dependency relationship. Server 200 then needs to execute these X load requests according to the dependency relationship, i.e., first executing the dependent load request to obtain the execution result of the dependent load request, and then executing another load request using the execution result of the previous load request as an input parameter to obtain the execution result of the other load request. In other words, for different load requests with dependencies, server 200 will execute them sequentially based on their dependencies, rather than in parallel. For multiple load requests among the N load requests that do not have dependencies, server 200 can execute these multiple load requests in parallel by launching multiple runtime instances, thereby fully leveraging the elastic concurrency advantages of server 200's serverless architecture.

[0075] For example, assuming that the first service, the second service, and the third service are deployed on the server 200, the merge request received by the server 200 is generated by the client 100 based on the first load request, the second load request, and the third load request (N=3 at this time). Among them, the first load request is used to request the first data of the first service, the second request is used to request the second data of the second service, and the third request is used to request the third data of the third service. In addition, the merge request carries the dependency relationship between the first load request and the second load request (X=2 at this time), which specifically indicates that the second load request is based on the execution result of the first load request as an input parameter.

[0076] When the transceiver module 201 in the server 200 receives the above-mentioned merge request sent by the client 100, the parsing and execution module 202 in the server 200 determines that the first loading request and the second loading request need to be executed in sequence by parsing the above-mentioned dependency relationship in the merge request, that is, the first loading request is executed first, and then the second loading request is executed based on the execution result of the first loading request as an input parameter. The execution time of the third loading request is not limited and can be executed concurrently with the first request or the second request.

[0077] Therefore, the server 200 can dynamically and flexibly start two runtime instances to execute the first loading request and the third loading request in parallel, thereby giving full play to the elastic scaling and concurrency advantages of the server-less architecture of the server 200 and improving the processing speed of merged requests. When the execution result of the first loading request is obtained, another runtime instance is started, and the other runtime instance executes the second loading request based on the execution result of the first loading request as an input parameter.

[0078] Specifically, such as Figure 3 As shown, the parsing execution module 202 can first start the runtime instance 1 and the runtime instance 3, and the runtime instance 1 and the runtime instance 2 can perform corresponding actions in parallel: the runtime instance 1 is responsible for executing the first load request, specifically, it can call the API provided by the first service to obtain the first data required for the first load request from the first service, and the runtime instance 2 is responsible for executing the second load request, specifically, it can call the API provided by the third service to obtain the third data required for the third load request. Then, when the runtime instance 1 obtains the first data (that is, the execution result of the first request), the first data is returned to the parsing execution module 202, and then the parsing execution module 202 starts the runtime instance 2. The runtime instance 2 is responsible for executing the second load request, specifically, it can call the API provided by the second service, and use part or all of the first data obtained previously (that is, part or all of the execution result of the first load request) as the input parameter of the API, thereby obtaining the second data required for the second load request from the second service. The above-mentioned runtime instance 1, runtime instance 2 and runtime instance 3 can be automatically closed after executing the corresponding actions. Subsequently, when the parsing execution module 202 obtains the first data, the second data and the third data (that is, obtains the execution results of the first loading request, the second loading request and the third loading request respectively), the execution result of the merged request (including the above-mentioned first data, second data and third data) can be generated, and then the transceiver module 201 returns the execution result of the merged request to the client 100.

[0079] S205: The server 200 returns the execution result of the merge request to the client 100. Accordingly, the client 100 receives the execution result of the merge request returned by the server.

[0080] S206. The client 100 parses the execution result of the merged request into the request result corresponding to each of the N loading requests, and displays the request result to the location of the service corresponding to each of the N loading requests in the page.

[0081] Specifically, when the transceiver module 103 in the client 100 receives the execution result of the merge request returned by the server 200, it sends the execution result of the merge request to the parsing module 104. The parsing module 104 parses the execution result of the merge request into the request result corresponding to each of the N load requests (the execution result corresponding to each load request), and then sends the request result corresponding to each of the N load requests to the interaction module 101. The interaction module 101 displays the request result corresponding to each of the N load requests at the location of the service corresponding to each load request on the page.

[0082] Optionally, the merge request may be implemented in Graph Query Language (GQL). Specifically, the merge module 102 in the client 100 may first generate a merge request according to the syntax of GQL, and then the transceiver module 103 may generate / package an HTTP request based on the merge request, wherein the payload portion (request body / payload) of the HTTP request includes the merge request, and then the HTTP request is sent to the server 200.

[0083] For example, assume that the server 200 provides an order service, a user service, and a product service. Each service provides a set of interfaces or APIs for operating and managing the data of the service. The order service is responsible for managing order data, including order identifiers (IDs), user IDs, and product IDs; the user service is responsible for managing user data, including user IDs, names, and ages; and the product service is responsible for managing product data, including product IDs, product names, and prices.

[0084] The user enters an order identifier (ID) through the interactive module 101 on the client 100, assuming it is 123. According to the business logic of the page code, the above user operation will trigger the interactive module 101 in the client 100 to generate the following three loading requests: the first loading request represents a request to the order service to obtain the order data (including order ID, user ID and product ID) with order ID 123; the second loading request represents using the user ID in the execution result of the first loading request (i.e., order data with order ID 123) as an input parameter to request the user service to obtain the user data (including user ID, name, age) corresponding to the input parameter; the third loading request represents using the product ID in the response result of the first loading request (i.e., order data with order ID 123) as an input parameter to request the product service to obtain the product data (including product ID, product name, price) corresponding to the input parameter. It can be seen that the above third loading request and the second loading request both have a dependency relationship with the first loading request, and the first loading request is the dependent loading request.

[0085] Then, the merge module 102 in the client 100 generates a merge request based on the three load requests, and carries the above dependency relationship in the merge request. Assuming that the merge request uses GQL syntax, the content of the merge request is as follows:

[0086]

[0087]

[0088] Subsequently, the merge module 102 in the client 100 sends the merge request to the transceiver module 103. The transceiver module 103 then generates an HTTP request based on the merge request. The payload of the HTTP request includes the merge request. The HTTP request is then sent to the server 200 to instruct the server 200 to execute the merge request. The server 200 parses and executes the merge request to obtain the execution result of the merge request, and then returns the execution result of the merge request to the client 100. The content of the execution result of the merge request is as follows:

[0089]

[0090] When the transceiver module 103 of the client 100 receives the execution result of the merge request returned by the server 200, the execution result of the merge request is sent to the parsing module 104. The parsing module 104 can determine the services corresponding to these fields by parsing the fields in the execution result of the merge request, and then determine which fields of data belong to the execution result of the first loading request, which fields of data belong to the execution result of the second loading request, and which fields of data belong to the execution result of the third loading request based on the correspondence between the service and the loading request, thereby parsing the execution result of the merge request into the request result of the first loading request, the request result of the second loading request, and the execution result of the third loading request. Then, the interactive module 101 displays the execution results of the three loading requests at corresponding positions on the page, thereby completing the page loading.

[0091] It should be noted that the names, quantities, fields, and data contents of the various services in the above examples are merely examples and do not constitute specific limitations. The contents of the various load requests in the above examples (including the manner in which dependencies between load requests are described) are also merely examples and do not constitute specific limitations.

[0092] In summary, the page loading method provided in the embodiment of the present application supports users to configure a merge strategy for merging loading requests, so that how the client 100 performs the merge operation can be controlled according to the user's usage requirements, and can be applied to low-code scenarios based on configuration. During the page code / application development stage, developers can focus on writing the business logic in the page code / application code without paying attention to how to merge requests, that is, developers do not need to write anything related to request merging in the code, which does not affect the original development efficiency. The merge strategy can be configured outside the page code without intrusion into the page code. In addition, different pages can reuse the same set of merge strategies, and the load requests generated when each page on the client 100 is running can be automatically merged according to the merge strategy.

[0093] When a page on client 100 generates M load requests, the client can determine N load requests that can be merged from the M load requests based on the user-configured merge strategy, then generate a merge request based on these N load requests, and then send the merge request to server 200, thereby reducing the number of interactions between client 100 and server 200. When client 100 receives the execution result of the merge request returned by server 200, it can complete page loading by parsing the execution result, which helps to improve page loading speed and user experience.

[0094] The method provided in the embodiment of the present application also supports merging different load requests with dependencies to generate a merged request. By carrying the dependency between the load requests in the merged request, the server 200 is instructed to execute the corresponding load request according to the dependency. Since different load requests with dependencies can be merged into one merged request and sent to the server 200, the number of interactions between the client 100 and the server 200 can be reduced, the processing pressure of the server 200 can be reduced, and the data acquisition efficiency of the client 100 can be improved, thereby improving the page loading speed and user experience of the client 100.

[0095] Based on the above, the following describes the Figure 2 Embodiments of the method and related apparatus.

[0096] See Figure 4 , Figure 4 4 is a structural diagram of a page loading device 400 provided in an embodiment of the present application, which includes an interaction module 101, a merging module 102, a transceiver module 103 and a parsing module 104.

[0097] Merging module 102 is configured to respond to an application page load operation and obtain M load requests for M services that the page needs to load. Merging module 102 is also configured to obtain a user-configured merge strategy and merge N of the M load requests according to the merge strategy to generate a merge request, where the N services corresponding to the N requests are provided by the same server.

[0098] The transceiver module 103 is used to send a merge request to the server to instruct the server to execute the merge request. The transceiver module 103 is also used to receive the execution result of the merge request returned by the server.

[0099] The parsing module 104 is configured to parse the execution result into a request result corresponding to each of the N load requests.

[0100] The interaction module 101 is used to display the request result to the location of the service corresponding to each of the N loading requests in the page.

[0101] Optionally, the interaction module 101 is further configured to provide a configuration interface and receive a merge strategy input by a user through the configuration interface. The page loading device 400 further includes a storage module 105, which is configured to store the above-mentioned merge strategy.

[0102] Optionally, the merging strategy includes a collection time threshold, and the N load requests are generated within the collection time threshold.

[0103] Optionally, the merging strategy includes a collection time threshold, a waiting time threshold of a single load request collected within the collection time threshold, and / or a threshold of the number of load requests. When any of the above thresholds is reached, the merging operation is performed.

[0104] Optionally, the merge strategy also includes dependencies between load requests. In this case, merge module 102 is specifically configured to identify X load requests that meet the dependencies among N load requests based on the dependencies. The merge request includes the dependencies between the X load requests, instructing the server to execute the X load requests based on the dependencies.

[0105] Optionally, the merging strategy also includes the correspondence between the service directory on the server and the above N services.

[0106] Optionally, the transceiver module 103 is specifically used to: generate an HTTP request according to the merge request, and then send the HTTP request to the server 200, wherein the payload part of the above HTTP request includes the above merge request, and the merge request adopts the GQL language.

[0107] It should be noted that the interaction module 101, merging module 102, transceiver module 103, and parsing module 104 can be implemented via software, hardware, or a combination of both. For example, the implementation of merging module 102 will be described below using merging module 102 as an example. Similarly, the implementation of the other modules described above can refer to the implementation of merging module 102.

[0108] As an example of a software functional unit, the merging module 102 may include code running on a computing instance. The computing instance may include at least one of a physical host (computing device), a virtual machine, and a container. Furthermore, the computing instance may be one or more. For example, the merging module 102 may include code running on multiple hosts / virtual machines / containers. It should be noted that the multiple hosts / virtual machines / containers used to run the code may be distributed in the same region or in different regions. Furthermore, the multiple hosts / virtual machines / containers used to run the code may be distributed in the same availability zone (AZ) or in different AZs, each AZ including one data center or multiple geographically close data centers. Typically, a region may include multiple AZs.

[0109] Similarly, multiple hosts / virtual machines / containers running the code can be distributed within the same virtual private cloud (VPC) or across multiple VPCs. Typically, a VPC is set up within a region. Cross-region communication between two VPCs within the same region, or between VPCs in different regions, requires a communication gateway within each VPC to interconnect the VPCs.

[0110] As an example of a hardware functional unit, the merging module 102 may include at least one computing device, such as a server. Alternatively, the merging module 102 may be implemented using an application-specific integrated circuit (ASIC) or a programmable logic device (PLD). The PLD may be a complex programmable logical device (CPLD), a field-programmable gate array (FPGA), a generic array logic (GAL), or any combination thereof.

[0111] The multiple computing devices included in the merging module 102 can be distributed in the same region or in different regions. The multiple computing devices included in the merging module 102 can be distributed in the same AZ or in different AZs. Similarly, the multiple computing devices included in the merging module 102 can be distributed in the same VPC or in multiple VPCs. The multiple computing devices can be any combination of servers, ASICs, PLDs, CPLDs, FPGAs, GALs, and other computing devices.

[0112] In other embodiments, the above-mentioned interaction module 101, merging module 102, transceiver module 103 and parsing module 104 can all be used to perform Figure 2 The steps performed by the client 100 in the above modules can be specified as needed, and they can be used to implement Figure 2 The client 100 executes different steps to realize all functions of the page loading device 400.

[0113] It should also be noted that the page loading device 400 may correspond to the client 100 described above, and is used to execute Figure 2 For details on the method steps performed by the client 100, see Figure 2 The relevant description is not repeated here. Figure 4 The page loading device 400 is only used as an example to illustrate the division of the above-mentioned functional modules. In actual applications, the above-mentioned functions can be assigned to different functional modules as needed, that is, the internal structure of the page loading device 400 can be divided into other different functional modules to complete all or part of the functions described above.

[0114] See Figure 5 The present application also provides a computing device 500, including a bus 502, a processor 504, a memory 506, and a communication interface 508. The processor 504, the memory 506, and the communication interface 508 communicate with each other via the bus 502. The computing device 500 can be a server, a laptop computer, a desktop computer, an edge device, etc., and the embodiments of the present application do not specifically limit this. The embodiments of the present application do not limit the number of processors and memories in the computing device 500.

[0115] The bus 502 may be a peripheral component interconnect (PCI) bus or an extended industry standard architecture (EISA) bus. The bus may be divided into an address bus, a data bus, a control bus, etc. For ease of representation, Figure 5 The fact that only one line is used in the figure does not mean that there is only one bus or only one type of bus. Bus 502 may include a path for transmitting information between various components of computing device 500 (eg, memory 506, processor 504, communication interface 508).

[0116] The processor 504 may include any one or more processors such as a central processing unit (CPU), a graphics processing unit (GPU), a microprocessor (MP), or a digital signal processor (DSP).

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

[0118] The memory 506 stores executable program codes. The processor 504 executes the executable program codes to implement Figure 5 The functions of the interaction module 101, the merging module 102 and the transceiver module 103 in the present application are realized. Figure 2 The communication interface 508 uses a transceiver module such as, but not limited to, a network interface card or a transceiver to implement communication between the computing device 500 and other devices or a communication network.

[0119] The present application also provides a terminal device, comprising a processor, a memory and a transceiver. The processor is used to execute instructions stored in the memory, so that the terminal device executes Figure 2 Method steps on the client 100 side.

[0120] The present application also provides a computer-readable storage medium. The computer-readable storage medium can be any available medium that can be stored by a computing device or a data storage device such as a data center that contains one or more available media. The available medium can be a magnetic medium (e.g., a floppy disk, a hard disk, a tape), an optical medium (e.g., a DVD), or a semiconductor medium (e.g., a solid-state drive). The computer-readable storage medium includes instructions that instruct the computing device to execute Figure 2 The method on the client 100 side.

[0121] The present application also provides a computer program product containing instructions. The computer program product may be a software or program product containing instructions that can be run on a computing device or stored in any available medium. When the computer program product is run on at least one computing device, the at least one computing device executes Figure 2 The method of the client 100.

[0122] Finally, it should be noted that the above embodiments are only used to illustrate the technical solutions of the present application, rather than to limit them. Although the present application has been described in detail with reference to the aforementioned embodiments, those skilled in the art should understand that they can still modify the technical solutions described in the aforementioned embodiments, or make equivalent replacements for some of the technical features therein. However, these modifications or replacements do not deviate the essence of the corresponding technical solutions from the protection scope of the technical solutions of the embodiments of the present application.

Claims

1. A page loading method, characterized in that: The method is applied to a client, and includes: In response to a page load operation of an application, M load requests of M services that need to be loaded by the page are obtained; Get the user-configured merge strategy; Merging N load requests from the M load requests according to the merging strategy to generate a merged request, wherein the N services corresponding to the N requests are provided by the same server; Sending the merge request to the server to instruct the server to execute the merge request; Receive the execution result of the merge request returned by the server; The execution result is parsed into a request result corresponding to each of the N loading requests, and the request result is displayed on the page.

2. The method according to claim 1, characterized in that The method further comprises: Providing a configuration interface through the client; receiving the merging strategy input by the user through the configuration interface; The merge strategy is stored.

3. The method according to claim 1 or 2, characterized in that The merging strategy includes a collection time threshold, and the N load requests are generated within the collection time threshold.

4. The method according to claim 1 or 2, characterized in that The merging strategy includes a collection time threshold, a waiting time threshold of a single load request collected within the collection time threshold, and / or a threshold of the number of load requests. When any of the above thresholds is reached, a merging operation is performed.

5. The method according to any one of claims 1 to 4, characterized in that The merge strategy also includes dependencies between load requests; Generating a merge request includes: Identifying, according to the dependency relationship, X load requests among the N load requests that meet the dependency relationship; The dependency relationship between the X load requests is carried in the merge request to instruct the server to execute the X load requests according to the dependency relationship.

6. The method according to any one of claims 1 to 5, characterized in that The merging strategy also includes the correspondence between the service directory on the server and the N services.

7. The method according to any one of claims 1 to 6, characterized in that The sending the merge request to the server includes: A Hypertext Transfer Protocol (HTTP) request is sent to the server, wherein a payload portion of the HTTP request includes the merge request, and the merge request adopts the graph query language (GQL).

8. A page loading device, characterized in that: The method comprises means for performing the method according to any one of claims 1 to 7.

9. A computer-readable storage medium, characterized in that The method comprises computer program instructions, which, when executed by a computing device, causes the computing device to perform the method according to any one of claims 1 to 7.

10. A computer program product comprising instructions, characterized in that When the instructions are executed by a computing device, the computing device is caused to perform the method according to any one of claims 1 to 7.

Images