Method for processing interface call request, electronic device, and storage medium

Abstract

The present disclosure relates to the technical field of computers. Disclosed are a method for processing an interface call request, an electronic device, and a storage medium. The method comprises: receiving an interface call request from a client, wherein the interface call request is used for requesting to call a plurality of application service interfaces of a server to obtain application service data corresponding to an application service requirement; on the basis of a preset interface orchestration mode, performing graphical orchestration on target encapsulation functions corresponding to the interface call request to obtain an orchestration result, wherein the preset interface orchestration mode is used for performing graphical orchestration on the target encapsulation functions and a connection relationship between the target encapsulation functions so as to obtain the application service data from the plurality of application service interfaces; on the basis of the orchestration result, obtaining the application service data from the plurality of application service interfaces; and feeding back the application service data to the client. The present disclosure solves the technical problems in the related art of difficulty in operation and maintenance and high research and development costs and high operation and maintenance costs caused by using a serverless cloud framework as an intermediate layer.

Description

[0001] TECHNICAL FIELD The present disclosure relates to the field of computer technology, and more specifically, to a method for processing interface call requests, an electronic device, and a storage medium. BACKGROUND Generally, enterprises have their own data management systems that manage development and operations, allowing users to perform operations such as data development, task scheduling, and monitoring through programming. However, since the applications managed by data management systems often develop in a vertically divided manner, as the number of applications continues to increase, dependencies between different applications begin to exist, leading to numerous problems in front-end and back-end collaboration. Currently, a backend for frontend (BFF) architecture is used to address front-end and back-end collaboration. One approach, using a serverless cloud framework as a BFF, has been proposed. However, the design of this architecture presents difficulties in R&D and operations, as well as high R&D and operations costs. Currently, no effective solution has been proposed to address these issues. SUMMARY OF THE INVENTION Embodiments of the present disclosure provide a method, electronic device, and storage medium for processing interface call requests, aiming to at least address the technical issues in related technologies related to using a serverless cloud framework as an intermediate layer, which leads to operational difficulties, high R&D costs, and high operational costs. According to one aspect of an embodiment of the present disclosure, a method for processing interface call requests is provided, comprising: receiving an interface call request from a client, wherein the interface call request is for invoking multiple application service interfaces on a server to obtain application service data corresponding to application service requirements; graphically orchestrating target encapsulated functions corresponding to the interface call request according to a preset interface orchestration method to obtain an orchestration result, wherein the preset interface orchestration method is for obtaining application service data from multiple application service interfaces by graphically orchestrating target encapsulated functions and the connections between the target encapsulated functions, wherein the target encapsulated functions are used to define interface information for the multiple application service interfaces; and the orchestration result is used to describe the process of obtaining application service data by graphically orchestrating the target encapsulated functions and the connections between the target encapsulated functions; obtaining application service data from the multiple application service interfaces based on the orchestration result; and feeding the application service data back to the client.According to another aspect of an embodiment of the present disclosure, a method for processing an interface call request is provided, comprising: sending an interface call request to a server, wherein the interface call request is used to request calling multiple application service interfaces of the server to obtain application service data corresponding to application service requirements; and receiving application service data fed back by the server, wherein the application service data is obtained by the server from the multiple application service interfaces based on an orchestration result, wherein the orchestration result is obtained by graphically orchestrating target encapsulation functions corresponding to the interface call request according to a preset interface orchestration method, wherein the preset interface orchestration method is used to obtain application service data from the multiple application service interfaces by graphically orchestrating target encapsulation functions and connection relationships between the target encapsulation functions, wherein the target encapsulation functions are used to define interface information of the multiple application service interfaces, and the orchestration result is used to describe a process of obtaining the application service data by graphically orchestrating the target encapsulation functions and the connection relationships between the target encapsulation functions. According to another aspect of an embodiment of the present disclosure, a system for processing interface call requests is provided, comprising: a front-end and back-end collaborative server, configured to receive an interface call request from a front-end and back-end collaborative client, graphically orchestrate a target encapsulated function corresponding to the interface call request according to a preset interface orchestration method to obtain an orchestration result, obtain application service data from multiple application service interfaces based on the orchestration result, and feed the application service data back to the front-end and back-end collaborative client; and a front-end and back-end collaborative client, configured to send an interface call request to the front-end and back-end collaborative server and receive application service data fed back by the server. The interface call request is used to request calling multiple application service interfaces of the server to obtain application service data corresponding to application service requirements, the preset interface orchestration method is used to graphically orchestrate target encapsulated functions and connection relationships between the target encapsulated functions to obtain application service data from the multiple application service interfaces, the target encapsulated functions are used to define interface information of the multiple application service interfaces, and the orchestration result is used to describe a process of obtaining application service data by graphically orchestrating the target encapsulated functions and the connection relationships between the target encapsulated functions. According to another aspect of an embodiment of the present disclosure, an electronic device is provided, comprising: a memory storing an executable program; and a processor configured to execute the program, wherein when the program executes, any one of the aforementioned methods for processing an interface call request is executed. According to another aspect of an embodiment of the present disclosure, a computer-readable storage medium is provided, wherein the computer-readable storage medium includes a stored executable program, wherein when the executable program executes, the computer-readable storage medium controls the device containing the computer-readable storage medium to execute any one of the aforementioned methods for processing an interface call request.In an embodiment of the present disclosure, an interface call request is received from a client, and then graphically orchestrates the target encapsulated functions corresponding to the interface call request according to a preset interface orchestration method to obtain an orchestration result. Specifically, the target encapsulated functions and the connection relationships between the target encapsulated functions are graphically orchestrated to obtain an orchestration result describing a process for obtaining application service data through the graphical orchestration of the target encapsulated functions and the connection relationships between the target encapsulated functions. Based on the obtained orchestration result, the target encapsulated functions corresponding to the interface call request are called to obtain application service data corresponding to the application service requirements from multiple application service interfaces of the server. Finally, the obtained application service data is fed back to the client. As can be seen, this disclosure considers the data security risks associated with users using GraphQL to directly operate databases. Therefore, by restricting GraphQL's capabilities, users are not allowed to write GraphQL to directly access databases. Instead, GraphQL is used as an intermediary layer, achieving the goal of visually orchestrating interfaces and accessing server-side interfaces through functions. This ensures data security while also preventing R&D costs from increasing due to the introduction of new technologies, thereby reducing R&D and operation and maintenance costs. This addresses the technical issue in related technologies where the use of serverless cloud frameworks as an intermediary layer leads to operational difficulties and high R&D and operation and maintenance costs. It should be noted that the general description above and the detailed description that follow are merely illustrative and illustrative of the present disclosure and do not constitute limitations of the present disclosure. BRIEF DESCRIPTION OF THE DRAWINGS The accompanying drawings described herein are provided to provide a further understanding of the present disclosure and constitute a part of the present disclosure. The illustrative embodiments of the present disclosure and their descriptions are provided to explain the present disclosure and do not constitute undue limitations of the present disclosure.In the accompanying drawings: Figure 1 is a hardware structure block diagram of a computer terminal (or mobile device) for implementing a method for processing an interface call request according to Example 1 of the present disclosure; Figure 2 is a flow chart of a method for processing an interface call request according to Example 1 of the present disclosure; Figure 3 is a design schematic diagram of a function management module according to Example 1 of the present disclosure; Figure 4 is a design schematic diagram of an interface orchestration module according to Example 1 of the present disclosure; Figure 5 is a schematic diagram of a new interface according to Example 1 of the present disclosure; Figure 6 is a schematic diagram of a visual orchestration mode according to Example 1 of the present disclosure; Figure 7 is a design schematic diagram of a publishing module according to Example 1 of the present disclosure; Figure 8 is a flow chart of an interface call failure according to Example 1 of the present disclosure; Figure 9 is a schematic diagram of an error message display according to Example 1 of the present disclosure; Figure 10 is a flow chart of a method for processing an interface call request according to Example 2 of the present disclosure; Figure 11 is a schematic diagram of the design idea of ​​a toolkit according to Example 2 of the present disclosure; Figure 12 is a first screen rendering flow chart according to Example 2 of the present disclosure; Figure 13 is a schematic diagram of a first screen rendering page according to Example 2 of the present disclosure; Figure 14 is a schematic diagram of a system for processing interface call requests according to Example 3 of the present disclosure; Figure 15 is a diagram of a BFF system architecture according to Example 3 of the present disclosure; Figure 16 is a schematic diagram of a BFF capability according to Example 3 of the present disclosure; Figure 17 is a schematic diagram of an API documentation page according to Example 3 of the present disclosure; Figure 18 is a schematic diagram of a static resource management page according to Example 3 of the present disclosure; Figure 19 is a schematic diagram of a create and edit file page according to Example 3 of the present disclosure; Figure 20 is a schematic diagram of a monitoring dashboard page according to Example 3 of the present disclosure; Figure 21 is a schematic diagram of the structure of a device for processing interface call requests according to Example 4 of the present disclosure; Figure 22 is a schematic diagram of the structure of another device for processing interface call requests according to Example 4 of the present disclosure; and Figure 23 is a block diagram of the structure of a computer terminal according to an embodiment of the present disclosure. DETAILED DESCRIPTION OF THE PREFERRED EMBODIMENTS To help those skilled in the art better understand the present disclosure, the technical solutions in the embodiments of the present disclosure will be clearly and completely described below in conjunction with the accompanying drawings. It should be understood that the described embodiments are merely a portion of the embodiments of the present disclosure, and not all of them. All other embodiments derived by persons of ordinary skill in the art based on the embodiments of the present disclosure without inventive effort shall fall within the scope of protection of the present disclosure. It should be noted that the terms "first", "second", etc. in the specification and claims of the present disclosure and the above-mentioned drawings are used to distinguish similar objects, and are not necessarily used to describe a specific order or sequence.It should be understood that the terms used in this manner are interchangeable where appropriate, so that the embodiments of the present disclosure described herein can be implemented in sequences other than those illustrated or described herein. Furthermore, the terms "including," "having," and any variations thereof, are intended to cover non-exclusive inclusions. For example, a process, method, system, product, or apparatus comprising a series of steps or elements need not be limited to those steps or elements explicitly listed, but may include other steps or elements not explicitly listed or inherent to such process, method, product, or apparatus. First, some nouns or terms that appear in the description of the embodiments of the present disclosure are subject to the following interpretations: Backend for Frontend (BFF): An architectural pattern primarily used to address front-end and back-end collaboration issues, providing specialized back-end services for front-end applications to meet the specific needs and functionality of such front-end applications. Graph Query Language (GraphQL): A query language and runtime environment for application programming interfaces (APIs), which provides a flexible and efficient way to define and use APIs, enabling clients to more precisely control data acquisition and manipulation. Hypertext Transfer Protocol (HTTP): A protocol used to transmit and receive hypertext data on the internet. HTTP is a client-server protocol in which clients send requests and receive responses from servers. It is commonly used for accessing web pages, transferring files, and sending data. Hypertext Transfer Protocol Secure (HTTPS): A communications protocol for securely transmitting data over computer networks, it is an encrypted version of HTTP. GET: A request method in the HTTP protocol that requests data from a server, commonly used to retrieve resources such as web pages and images. POST: A request method in the HTTP protocol that submits data to a server, commonly used to create, update, or delete resources on the server.

[0002] REST (Representational State Transfer) calls: A method for sending requests and receiving responses over the HTTP protocol, used to access web services and APIs. REST is a resource-based architectural style whose design principles include the use of uniform interfaces, stateless communication, unique resource identifiers, and self-describing messages. Through REST calls, clients can use HTTP methods (such as GET and POST) to operate on remote server resources, enabling the reading, creation, updating, and deletion of data.

[0003] JSON (JavaScript Object Notation): A lightweight data exchange format that's easy to read and write. Form-data: A format used to transmit data in HTTP requests, commonly used to transmit form data during form submission. Data in form-data format consists of a series of key-value pairs (field name and field value), each separated by a newline character. Each key-value pair has the format "field name: field value," and field values ​​can be text, files, and other types of data. Virtual Operators (VOCs): VOCs deeply refine services based on their core business strengths, ultimately providing services to consumers under their own brand and self-built customer service systems. Data Management System Tenants: Tenants are the foundation of user management in the data management system. One primary account corresponds to one data management system tenant, and tenants can manage permissions for their members. Data Management System Roles: The disclosed data management system offers several roles: Project Owner, Space Administrator, Data Analyst, Developer, Operations and Maintenance, Deployer, Guest, Security Administrator, and Model Designer. Different roles have varying operational permissions.

[0004] JSON Schema: A specification for describing the structure of JSON data. It allows you to define the structure, data types, and constraints of JSON data and can be used to verify the validity of JSON data.

[0005] TypeScript: An open-source programming language, a superset of JavaScript, encompasses all JavaScript features and adds a static type system and other extended capabilities. A Content Delivery Network (CDN) is a distributed content delivery network built on a data network. It utilizes streaming media server cluster technology to overcome the shortcomings of single-server systems in terms of output bandwidth and concurrency. This can significantly increase the number of concurrent streams supported by the system and reduce or avoid the adverse effects of single points of failure.

[0006] Node Package Manager (npm): It is a software package management system preset for Node.js and written in JavaScript.

[0007] Incremental Static Regeneration (ISR): ISR is a technology used to generate static web pages. It is widely used in modern static website generators and frameworks to improve the efficiency and performance of website generation.

[0008] Postinstall: In npm, postinstall 1 is a specific lifecycle script used to execute specific commands or operations after the package installation is complete.

[0009] JSONP (JSON with Padding): is a "usage mode" of JSON that allows web pages to obtain information from other domain names (websites), that is, cross-domain reading of data.

[0010] Webpack: A static module packaging tool that can bundle multiple modules into one or more files, and compress, transform and optimize resources.

[0011] Vite: A new generation of front-end building tools that uses the native module system (ES Module) of modern browsers to achieve rapid development and hot updates, aiming to provide a faster development experience and higher performance. Vite is faster than Webpack in some scenarios. As the number of applications continues to increase and dependencies between different applications begin to exist, the data management system has encountered many front-end and back-end collaboration problems, such as: (1) Difficulty in using cross-product line code, gateway functions are implemented separately, and it is difficult to jump between applications. It is necessary to maintain a list of application domain names, resulting in high development costs;

[0012] (2) There are several domain names on the user link, which are difficult to remember, and users have to wait a long time to access cross-region interfaces and files, resulting in a poor user experience;

[0013] (3) Interface calls that rely on other product lines require upper-level encapsulation by the backend, resulting in poor flexibility;

[0014] (4) Interface security capabilities are maintained by each product line, which may lead to problems such as untimely updates. In addition, since all products have independent domain names, cross-domain access is risky and poses security risks.

[0015] (5) Some products do not allow inline frames (iframes), while some products have no restrictions, resulting in inconsistent configurations;

[0016] (6) Failure to strictly follow the specifications has resulted in uneven implementation of interface specifications;

[0017] (7) The high cost of security and quality assurance leads to the lack of unified monitoring and alarm. Currently, a method of using the Serverless Cloud Framework as a BFF has been proposed. However, since the Serverless Cloud Framework is based on a containerized service that provides a Node or Python environment to run code, the front-end usually has weak capabilities for underlying operation and maintenance. Therefore, the cost of operation and maintenance is high, which makes the BFF solution difficult to implement in enterprises. In addition, the Serverless Cloud Framework is a container service and only provides basic capabilities for the application process in the container, such as gateways and storage buckets. As for other capabilities required in the production process, such as service orchestration, simulation (Mock), network acceleration, etc., developers need to develop and add them in the container themselves, which makes the labor cost high and the coverage of production link functions poor. A BFF framework has also been proposed, combining the API Gateway and BFF models with the concept of a package manager. However, due to its architectural design, this framework adopts a backend orchestration model, with backend code performing the orchestration process and the frontend providing a lightweight remote procedure call protocol for invocation. While this reduces frontend code complexity, it increases backend code complexity, resulting in high orchestration costs. Furthermore, this framework interferes with the frontend compilation environment, leading to migration costs for existing applications, especially for older versions. Related technologies, such as BFFs based on serverless cloud frameworks and BFFs that combine the API Gateway and BFF models with the concept of a package manager, suffer from the following drawbacks. Drawback 1: The BFF proposed based on the serverless cloud framework only provides basic capabilities such as gateway and cloud object storage. Developers must build monitoring, alerting, and network acceleration capabilities on their own. They also need to build front-end and back-end collaboration capabilities. The BFF, which combines the API Gateway and BFF models with the concept of a package manager, also requires developers to develop more advanced usage links, such as mock data, network acceleration, and resource hosting. Consequently, its production coverage is limited. Drawback 2: The BFF design architecture proposed based on the serverless cloud framework is heavily front-end-oriented, resulting in high operation and maintenance costs. Drawback 3: The BFF, which combines the API Gateway and BFF models with the concept of a package manager, adopts a back-end orchestration model, increasing back-end code complexity, resulting in high orchestration costs, and high front-end migration costs. Prior to this disclosure, no effective solution to these drawbacks had been proposed.Embodiment 1 According to an embodiment of the present disclosure, a method for processing an interface call request is provided. It should be noted that the steps illustrated in the flowcharts of the accompanying drawings can be executed in a computer system, such as a set of computer-executable instructions. Furthermore, although the flowcharts illustrate a logical sequence, in some cases, the steps illustrated or described may be executed in a different order. The method embodiment provided in Embodiment 1 of the present disclosure can be executed in a mobile terminal, a computer terminal, or a similar computing device. Figure 1 shows a hardware block diagram of a computer terminal (or mobile device) for implementing the method for processing an interface call request. As shown in Figure 1, the computer terminal 10 (or mobile device) may include one or more processors 102 (illustrated as 102a, 102b, 102n) (the processor 102 may include, but is not limited to, a processing device such as a microprocessor (MCU) or a programmable logic device (FPGA), a memory 104 for storing data, and a transmission device 106 for communication functions. In addition, it may also include: a display, an input / output interface (I / O interface), a universal serial bus (USB) port (which may be included as one of the ports of a BUS), a network interface, a power supply, and / or a camera. Those skilled in the art will appreciate that the structure shown in FIG1 is merely illustrative and does not limit the structure of the electronic device described above. For example, the computer terminal 10 may include more or fewer components than shown in FIG1 , or have a configuration different from that shown in FIG1 . It should be noted that the one or more processors 102 and / or other data processing circuits described above may generally be referred to herein as "data processing circuitry." This data processing circuitry may be embodied in whole or in part as software, hardware, firmware, or any other combination thereof. Furthermore, the data processing circuitry may be a single, independent processing module, or may be fully or partially integrated into any of the other components of the computer terminal 10 (or mobile device). As described in the embodiments of the present disclosure, this data processing circuitry serves as a processor control (for example, selecting a variable resistor terminal path connected to an interface). The memory 104 may be used to store software programs and modules of application software, such as program instructions / data storage devices corresponding to the method for processing interface call requests in the embodiments of the present disclosure. The processor 102 executes various functional applications and data processing by running the software programs and modules stored in the memory 104, thereby implementing the aforementioned method for processing interface call requests.Memory 104 may include high-speed random access memory (RAM) and non-volatile memory, such as one or more magnetic storage devices, flash memory, or other non-volatile solid-state memory. In some instances, memory 104 may further include memory located remotely from processor 102, which can be connected to computer terminal 10 via a network. Examples of such networks include, but are not limited to, the Internet, corporate intranets, local area networks (LANs), mobile communication networks, and combinations thereof. Transmission device 106 is used to receive or transmit data via a network. Specific examples of such networks may include a wireless network provided by the computer terminal 10's communications provider. In one instance, transmission device 106 includes a network interface controller (NIC), which can connect to other network devices via a base station to communicate with the Internet. In one instance, transmission device 106 may be a radio frequency (RF) module for wireless communication with the Internet. The display may be, for example, a touchscreen liquid crystal display (LCD), which enables a user to interact with the user interface of computer terminal 10 (or mobile device). In the above-described operating environment, the present disclosure provides a method for processing interface call requests, as shown in FIG2 . FIG2 is a flowchart of a method for processing interface call requests according to Embodiment 1 of the present disclosure. As shown in FIG2 , the method may include the following steps: Step S21: Receiving an interface call request from a client, wherein the interface call request is used to request to call multiple application service interfaces on a server to obtain application service data corresponding to the application service requirements; Step S22: Graphically orchestrating the target encapsulated functions corresponding to the interface call request according to a preset interface orchestration method to obtain an orchestration result. The preset interface orchestration method is used to graphically orchestrate the target encapsulated functions and the connection relationships between the target encapsulated functions to obtain application service data from multiple application service interfaces. The target encapsulated functions are used to define interface information for multiple application service interfaces. The orchestration result describes the process of obtaining application service data by graphically orchestrating the target encapsulated functions and the connection relationships between the target encapsulated functions; Step S23: Acquiring application service data from the multiple application service interfaces based on the orchestration result; and Step S24: Feeding the application service data back to the client.The client can be understood as the client (BFF client) corresponding to the backend for frontend (BFF), i.e., the front-end application corresponding to the BFF. The server can be understood as the server (BFF server) corresponding to the BFF, i.e., the server that provides various application services to the BFF client. It is understood that the BFF is used to coordinate between the front-end application and the server, providing specialized back-end services for the front-end application. In the embodiments of the present disclosure, a BFF service layer is added to the server, enabling better interaction with the client based on the BFF service layer and achieving coordination between the front-end application and the server. An interface call request can be understood as a call request from the client, i.e., a call request from the front-end application. An interface call request is used to request to call multiple application service interfaces on the server to obtain application service data corresponding to the application service requirements. By way of example, an interface call request can be an application programming interface call (API call) or a BFF interface request, used to obtain data, perform operations, or obtain specific functions, without limitation herein. Application service requirements can be understood as the operational requirements or functional requirements that users need to perform during project development, management, and use. For example, these requirements may be service requirements related to data development or operations management. They may also be information requirements that require querying the server, such as basic user information or operational information. It is understood that application service requirements are determined based on actual user needs and are not limited here. Application service data refers to data, operations, or functions corresponding to application service requirements. For example, if the application service requirement is to query user information, the application service data is user information. If the application service requirement is to call a function, the application service data is the corresponding function, which is not limited here. The target encapsulated function is a function that executes the functions required by the interface call request. It can be a packaged function so that the function can be called multiple times and used independently, improving the reusability and maintainability of the code. The target encapsulated function is used to define interface information for multiple application service interfaces to ensure that they meet the requirements of the interface definition. For example, the interface information may include the interface name, interface function description, parameter list, return result, error code list, etc., which is not limited here.It is understandable that an interface call request typically invokes one or more interfaces. Therefore, reasonable orchestration and planning are required between these interfaces to ensure correct data exchange, message passing, and call relationships between them, ensuring that all parts of the system can work together effectively. The BFF service layer proposed in the embodiments of this disclosure improves the design of the Graph Query Language (GraphQL) and restricts some of GraphQL's functions. Considering the data security risks associated with users using GraphQL to directly operate databases in related technologies, this disclosure does not allow users to write GraphQL to directly operate databases. Instead, this disclosure accesses server-side interfaces through functions, ensuring data security while also minimizing the increase in R&D costs associated with the introduction of new technologies. The preset interface orchestration method can be understood as a method for graphically orchestrating target encapsulated functions and the connections between them, i.e., orchestrating the target encapsulated functions and the connections between them through a visual orchestration model. For example, the interface orchestration page can be used for orchestration. Users can add new call interfaces through the directory tree within the interface orchestration page, adding new query or change operations to the API to expand API functionality to meet client needs. Furthermore, each interface can be graphically represented. Users can drag and drop functions, compose, and rename elements within the canvas to expand API functionality to meet client needs. In the disclosed embodiments, the graphical function elements can display information such as the function's application name, function name, input parameters, and output parameters, without limitation. The orchestration result obtained by graphically orchestrating the target encapsulated function corresponding to the interface call request according to the preset interface orchestration method can achieve the effect of obtaining the required application service data from multiple application service interfaces by calling the target encapsulated function corresponding to the interface call request. In other words, the encapsulated function corresponding to the interface call request can be used to call multiple application service interfaces on the server side to obtain application service data.In the embodiment of the present disclosure, steps S21 to S24 can be applied to the BFF service layer, i.e., the server, which receives an interface call request from a client and then graphically orchestrates the target encapsulated function corresponding to the interface call request according to a preset interface orchestration method to obtain an orchestration result. That is, graphically orchestrates the target encapsulated function and the connection relationship between the target encapsulated functions to obtain an orchestration result describing a process of obtaining application service data through the graphical orchestration of the target encapsulated function and the connection relationship between the target encapsulated functions. Based on the obtained orchestration result, the target encapsulated function corresponding to the interface call request can be called to obtain application service data corresponding to the application service demand from multiple application service interfaces of the server, and finally the obtained application service data is fed back to the client. As can be seen, this disclosure takes into account the data security risks associated with users using GraphQL to directly operate on databases. Therefore, by restricting GraphQL's capabilities, GraphQL is not allowed to directly access databases. Instead, GraphQL is used as an intermediate layer, with visual interface orchestration employed. Server-side interfaces are accessed through functions. This ensures data security while also preventing the increase in R&D costs associated with the introduction of new technologies, thereby reducing both R&D and operational costs. The methods for processing interface call requests provided in the embodiments of this disclosure can be applied, but are not limited to, to application scenarios involving application service data queries in fields such as e-commerce services, educational services, legal services, medical services, conference services, social networking services, financial product services, logistics services, and navigation services. Examples of these scenarios include application service data queries for e-commerce services, academic interpretation services, and medical treatment services, though these are not intended to be limiting.According to an embodiment of the present disclosure, an interface call request from a client is received, and then graphically orchestrates the target encapsulated function corresponding to the interface call request according to a preset interface orchestration method to obtain an orchestration result. Based on the obtained orchestration result, namely, graphically orchestrates the target encapsulated function and the connection relationship between the target encapsulated functions, an orchestration result describing the process of obtaining application service data through the graphical orchestration of the target encapsulated function and the connection relationship between the target encapsulated functions is obtained. By calling the target encapsulated function corresponding to the interface call request, application service data corresponding to the application service demand is obtained from multiple application service interfaces on the server side. Finally, the obtained application service data is fed back to the client. This achieves the purpose of using GraphQL as an intermediary layer, performing interface orchestration in a visual orchestration method, and accessing the server-side interface through a function method. This ensures data security while preventing R&D costs from increasing due to the introduction of new technologies, thereby reducing R&D costs and operation and maintenance costs. This further solves the technical problem in related technologies of using a serverless cloud framework as an intermediary layer, which leads to operational difficulties and high R&D and operation and maintenance costs. In an optional embodiment, the method for processing interface call requests further includes the following steps: Step S251: Creating an initial program code block for multiple application service interfaces; Step S252: Configuring function information for the initial program code block to obtain a target program code block, wherein the function information defines at least some or all of the following information: function name, calling method, server access points corresponding to the multiple application service interfaces, function description, and parameter configuration; Step S253: Encapsulating the target program code block to obtain a target encapsulated function. Functions define the interface information to which the server will connect and are an important module in BFF design. The BFF service layer proposed in the present embodiment also improves the function management module. Figure 3 is a schematic diagram of a function management module according to Example 1 of the present disclosure. Figure 3 uses directory management and file differentiation by application name as an example. API management in the BFF service layer includes functions such as interface orchestration, function management, and error code management. The interface orchestration function includes function management, which is not limited here. As shown in FIG3 , according to the search function in the function management page of FIG3 , the required files can be quickly found by setting different search conditions. For example, files can be quickly found by file name, which is not limited here.The right side of the function management page displays detailed function information, including but not limited to the function's endpoint. These include the function name, invocation method, description, Uniform Resource Locator (URL), input and output parameter definitions, and other configurations. Users can modify the function by modifying these details. The left side of the function management page displays a directory tree, where new functions can be created. As you can understand, creating a new function requires defining the function name, invocation method, server-side access point, description, input and output parameters, and other configurations. Regarding the server-side access point, the underlying system provides a variable service. Users can fill in the endpoint domain name by entering variables and then concatenating the interface name. There are two main ways to configure input parameters: automatically parsing input parameters by pasting server-side code, and manually entering input parameters. For output parameters, users can create a domain model to establish and select the output parameter type. Considering the practicality of actual system products, generic types such as object are available. For other configurations, users can enter additional configuration content, such as validation logic and Procedural Oriented Programming (POP) versions. The release and rollback modes for function management are similar to those for interface orchestration and will not be elaborated on here. A configuration tab can also be designed within function management, including interface timeout control and rate limiting policies for access control. Furthermore, the page in Figure 3 also includes a user documentation feature to help users quickly get started with the system. The documentation includes features such as a quick start guide, practical guides, and API specifications, which are not limited here. Referring to the functional design of the function management module shown in Figure 3, the present disclosure can encapsulate functions and obtain the target encapsulated function by creating initial program code blocks for multiple application service interfaces and then configuring function information for these initial program code blocks. Function information can be understood as the detailed function information shown on the right side of the function management page in Figure 3. Specifically, function information defines at least some or all of the following information: function name, calling method, server-side access points corresponding to multiple application service interfaces, function description, and parameter configuration. By configuring function information for the initial program code block, a target program code block is generated. Finally, the target program code block is encapsulated to obtain the target encapsulated function.In an optional embodiment, in step S22, graphically orchestrates the target encapsulated functions corresponding to the interface call request according to a preset interface orchestration method to obtain an orchestration result. The method includes the following steps: Step S221: Selecting a target encapsulated function corresponding to the interface call request from candidate encapsulated functions according to the preset interface orchestration method, and determining the connection relationship between the target encapsulated functions based on the interface relationships of multiple application service interfaces; Step S222: Graphically orchestrating the target encapsulated functions and the connection relationships to obtain an orchestration result. The BFF service layer proposed in this embodiment of the present disclosure also improves the interface orchestration module design. Considering the data security risks associated with users using GraphQL to directly operate on databases in related technologies, encapsulated functions are used to call server-side interfaces to obtain data. Figure 4 is a schematic diagram of the design of an interface orchestration module according to Example 1 of the present disclosure. As shown in Figure 4, the interface orchestration function in the API management of the BFF service layer includes a search function, allowing users to quickly find required files by entering a file name. The right side of the interface orchestration page displays detailed information about the GraphQL interface, including the corresponding status, contact, version, and description. It also includes features such as analysis, operation history, and settings. Users can modify the GraphQL interface through editing, which also includes publishing and rollback functions, which are not limited here. As can be seen, the interface orchestration module's primary function is to call functions and assemble and trim them. Users can create new GraphQL call interfaces through the directory tree on the interface orchestration page. Figure 5 is a schematic diagram of creating a new interface according to Example 1 of the present disclosure. As shown in Figure 5, when creating a new GraphQL interface, users need to enter the interface name, call method (e.g., GET, POST, etc.), content type (e.g., JSON, form-data, etc.), contact, call instructions, GraphQL statement, and sample call parameters. Optionally, users can be required to complete call testing before submitting the release. Users can also enter mock data in the edit box and decide whether to enable mock data. In addition to the aforementioned orchestration using GraphQL syntax, this embodiment of the present disclosure also proposes another visual orchestration mode for orchestrating target encapsulated functions, as shown in Figure 6 . Figure 6 is a schematic diagram of a visual orchestration mode according to Example 1 of the present disclosure. Users can drag and drop functions, compose, and rename elements within the canvas. The function element displays the function's application name, function name, and function input and output parameters.In an embodiment of the present disclosure, when graphically orchestrating target encapsulated functions corresponding to interface call requests according to a preset interface orchestration method, the target encapsulated function corresponding to the interface call request can be selected from candidate encapsulated functions in the interface orchestration function according to the preset interface orchestration method, and the connection relationship between the target encapsulated functions can be determined based on the interface relationships of multiple application service interfaces. Specifically, the connection relationship between multiple function elements in the canvas can be determined based on whether a dependency relationship exists between the multiple application service interfaces. The target encapsulated functions are then graphically orchestrated in the canvas based on the determined connection relationship, thereby obtaining an orchestration result. In an optional embodiment, in step S221, determining the connection relationship between the target encapsulated functions based on the interface relationships of the multiple application service interfaces includes the following method steps: Step S2211: In response to the interface relationship indicating that a dependency relationship exists between the multiple application service interfaces, determining the connection relationship as a serial connection relationship between the target encapsulated functions; Step S2212: In response to the interface relationship indicating that no dependency relationship exists between the multiple application service interfaces, determining the connection relationship as a parallel connection relationship between the target encapsulated functions. In the embodiments of the present disclosure, connection relationships may include serial and parallel connection relationships. These relationships can be determined based on the interface relationships between multiple application service interfaces, which can be understood as being determined based on the dependency relationships between the multiple application service interfaces. Serial connection of multiple interfaces generally occurs when there are dependencies between the interfaces. For example, when querying a user's node instance list, the user's tenant identifier (ID) is required. In this case, the user ID is first used to query the tenant interface to obtain the tenant ID, and then the tenant ID is used to query the node instance list. This process can be understood as a serial process. Parallel connection of multiple interfaces generally occurs when there are no dependencies between the interfaces. For example, when querying a user's node instance list, the node's basic attributes and engine information are required. These two pieces of information are provided by two independent interfaces, and the query conditions are independent of each other. In this case, the two interfaces can be requested simultaneously to obtain the data. This process can be understood as a parallel process. In the embodiments of the present disclosure, when determining the connection relationship between target encapsulated functions based on the interface relationships between multiple application service interfaces, whether the target encapsulated functions are connected in a serial or parallel manner can be determined by determining whether there is a dependency relationship between the multiple application service interfaces. If there is a dependency relationship between the multiple application service interfaces, it is determined that the target encapsulation functions are in a serial connection relationship; if there is no dependency relationship between the multiple application service interfaces, it is determined that the target encapsulation functions are in a parallel connection relationship.Optionally, if the target encapsulated functions are serially connected, multiple application service interfaces can be connected using arrows. Specifically, arrows can be used to connect the input and output parameters of dependent functions. As shown in Figure 6, the input parameter of getPermission in the workbench depends on the base ID output parameter of getUsetInfo. Therefore, an arrow connects the base ID output and the input parameter of getPermission, indicating the dependency relationship between getPermission and getUsetInfo. In this disclosed embodiment, the orchestrated image is automatically converted into GraphQL syntax for underlying execution. In an optional embodiment, in step S222, graphically orchestrating the target encapsulated function and the connection relationships to obtain an orchestration result includes the following method steps: Step S2221: In response to obtaining application service data from multiple data sources on the server side via multiple application service interfaces, aggregating the input parameters and output parameters of the target encapsulated function based on the connection relationships to obtain a first orchestration result; Step S2222: In response to the current data content obtained from the server side via the multiple application service interfaces exceeding the data content of the application service data, trimming the input parameters and output parameters of the target encapsulated function based on the connection relationships to obtain a second orchestration result. Considering that when the data required by the client involves two or more data sources, the data obtained through the two or more interfaces needs to be aggregated before being provided to the client. Therefore, in the disclosed embodiments, when graphically orchestrating the target encapsulated function and its connection relationships, if application service data needs to be obtained from multiple data sources on the server side via multiple application service interfaces, the target encapsulated function's input and output parameters need to be aggregated based on the connection relationships to obtain a first orchestration result, i.e., the aggregated orchestration result. Furthermore, given that the data required by the client may be less than the data provided by the interface, data needs to be trimmed within the BFF service layer to remove unnecessary fields, leaving only the fields that the client will consume. For example, when obtaining tenant information, the data returned by the tenant includes information such as the user name, company name, and department name. However, only the user name is actually consumed. Therefore, the company name and department name can be trimmed within the BFF service layer.Therefore, in the embodiments of the present disclosure, when graphically orchestrating the target encapsulated function and its connection relationships, if the current data content obtained from the server via multiple application service interfaces exceeds the data content of the application service data when obtaining application service data, the input and output parameters of the target encapsulated function need to be trimmed based on the connection relationships to obtain a second orchestration result, i.e., the trimmed orchestration result. It is understood that the combination element in the embodiments of the present disclosure can be used to aggregate or trim output parameters. As shown in Figure 6, the combination element can automatically aggregate the output parameters of the getUsetInfo and getPermission functions. Optionally, the company name (companyName) can be deleted by clicking the trash can button in the combination element, thereby trimming the parameter. The deleted field can also be restored by clicking the restore button again. Additionally, in the rename element, the rename button can be clicked to rename the output field, without limitation. It is understood that after obtaining the orchestration result through interface orchestration, the corresponding GraphQL interface can also be published. The BFF service layer proposed in the embodiments of the present disclosure also features an improved design for the release module. Figure 7 is a schematic diagram of a release module design according to Embodiment 1 of the present disclosure. As shown in Figure 7, release is performed by region. Users can select the region to be released and click Confirm to proceed. After release, the current release progress is displayed at the top of a pop-up window. Optionally, users can also select a pre-release environment and a group within the pop-up window. Furthermore, other services, such as financial cloud services, can be selected based on region, though this is not a limitation. Optionally, the release module includes an online environment preview that displays the time and regional deployment status. A note function is also provided to facilitate user annotation. When rolling back code, users can select the version number to be rolled back. For example, the system modification date can be used as the version number to facilitate user recall. After selecting the version number, the code content to be rolled back is displayed. After confirming the version number to be rolled back, the region to be rolled back is selected. For example, the latest released region can be highlighted by default to facilitate quick rollback operations. In an optional embodiment, the method for processing an interface call request further includes the following method steps: Step S261, performing access control on the interface call request using a preset access control method, wherein the preset access control method includes at least one of the following: performing access authentication on the interface call request; performing flow control on the interface call request; and pre-allocating access volume corresponding to application service data.The BFF service layer proposed in the embodiments of this disclosure also features an improved access control module. This disclosure categorizes access control into two categories: authentication and flow control. Authentication can be considered passive control. For example, when a client accesses a service, the user's product login status is verified. If the login status is expired, the user is redirected to the product login page. If the login status verification passes, the user is checked to see if they have registered as a tenant in the data management system. If not, the tenant registration process is automatically initiated. Flow control can be considered active control. For example, if the interface access traffic exceeds the limit, user access is restricted and a retry is initiated on the client. The BFF service layer also imposes timeout limits on backend interfaces. If the waiting time for a response exceeds the timeout limit, the connection is terminated and an access timeout message is returned. In addition to the aforementioned mechanisms, considering the characteristics of data management systems and the potential differences in traffic and client access volume between different applications, the present disclosure designs an application isolation mechanism for the BFF service layer access control module. This isolates applications and allocates their total BFF service layer access volume to prevent large applications from occupying excessive resources, leaving smaller applications without them. In embodiments of the present disclosure, when performing access control on interface call requests, a preset access control method can be employed. This preset access control method includes at least one of the following: access authentication for the interface call request, flow control for the interface call request, and pre-allocation of access volume corresponding to application service data. In other words, access control is performed on interface call requests from the perspectives of authentication, flow control, and application isolation. In an optional embodiment, the method for processing interface call requests further includes the following steps: Step S271: Responding to failures in calling multiple application service interfaces, obtaining a preset error code corresponding to the call failure event; Step S272: Searching for pre-recorded error information based on the preset error code. In step S273, a preset error code and error information are fed back to the client. The BFF service layer proposed in this embodiment of the present disclosure also features an improved design for the error code and prompt module, displaying both the error code and error prompt information to the client. This unification of the error code and error prompt information is achieved through the BFF service layer. Figure 8 is a flowchart of an interface call failure according to Example 1 of the present disclosure. As shown in Figure 8, the client sends an interface call request to the BFF service layer to request an interface call. After receiving the interface call request, the BFF service layer aggregates the GraphQL call and sends the interface call request to the server to obtain application service data. Upon receiving the request, the server executes processing logic. If an error occurs at the interface layer, a specific error code is returned to the BFF service layer.After receiving the error code, the BFF service layer searches for the entered error message based on the error code and then feeds the error code and error message back to the client. In this embodiment of the present disclosure, after the error message is delivered to the client, information such as the error title, error recipient, error cause, solution guidance, supplementary service information, error code, and request ID will be displayed on the client. Additionally, a primary and secondary supplementary buttons may be displayed to enable supplementary service operations, and a button with a one-click copy function may also be provided, though this is not a limitation. Figure 9 is a schematic diagram of an error message display according to Example 1 of the present disclosure. As shown in Figure 9, the "Data Source Service Call Failed" displayed on the error message display page is the error title. The "Data Source Service Call Failed Due to Unable to Obtain Scheduling Resource Group. Please check the RDS purchaser ID and RDS instance name to ensure availability" displayed on the page is the error cause and solution guidance. The "To use an exclusive scheduling resource group, please proceed to purchase" displayed on the page is the supplementary service information. The error code details displayed on the page include the error code, DE1001S10001, and the request ID, 0BC059CC16543099412338947E062B. Additionally, the page displays a primary button, a secondary button, and a one-click copy button. In this disclosed embodiment, when a client sends an interface call request to the BFF service layer, if multiple application service interface calls fail (i.e., an interface layer error occurs), the server obtains a preset error code corresponding to the call failure event. The BFF service layer then searches for pre-recorded error information based on the preset error code and sends the preset error code and error information back to the client in a unified manner. The error code can be understood as a code indicating the cause of the interface layer error, and the error information can be understood as information that further explains the cause of the interface layer error and provides guidance on solutions.In an optional embodiment, a graphical user interface (GUI) is provided via a cloud device, and the content displayed by the GUI at least partially includes an application service data query scenario. The method for processing an interface call request further includes the following method steps: Step S281: In response to a first control operation performed on the GUI, a target encapsulated function corresponding to the interface call request is selected from candidate encapsulated functions, where the function elements of the target encapsulated function include: a function application name, a function name, function input parameters, and function output parameters; Step S282: In response to a second control operation performed on the GUI, a connection relationship between the target encapsulated functions is determined based on the interface relationships of multiple application service interfaces; Step S283: In response to a third control operation performed on the GUI, the input parameters and output parameters of the target encapsulated functions are aggregated and / or trimmed based on the connection relationships to obtain an orchestration result; Step S284: Displaying the orchestration result within the GUI. In the embodiment of the present disclosure, the GUI displays at least the application service data query scenario, and a user can perform control operations within the application service data query scenario displayed in the GUI. It is understood that the aforementioned application service data query scenarios may include, but are not limited to, scenarios involving application service data query in fields such as e-commerce, education, healthcare, conferences, social networks, financial products, logistics, and navigation. The aforementioned graphical user interface also includes a first control (or a first touch area). When a first touch operation is detected on the first control (or the first touch area), a target encapsulated function corresponding to the interface call request may be selected from candidate encapsulated functions. It is understood that the function elements of the target encapsulated function include: function application name, function name, function input parameters, and function output parameters. The aforementioned first touch operation may be a click, box, check, or conditional filtering operation, without limitation. The aforementioned graphical user interface also includes a second control (or a second touch area). When a second touch operation is detected on the second control (or the second touch area), the connection relationship between the target encapsulated functions may be determined based on the interface relationship of multiple application service interfaces. The aforementioned second touch operation may be a click, box, check, or conditional filtering operation, without limitation. The graphical user interface also includes a third control (or a third touch area). When a third touch operation is detected on the third control (or the third touch area), the input and output parameters of the target wrapper function can be aggregated and / or trimmed based on the connection relationship to obtain an arrangement result. The third touch operation can be a click, a box, a check, a conditional filter, or other operation, which is not limited here. After obtaining the arrangement result, the arrangement result can be displayed in the graphical user interface.It should be noted that the first, second, and third touch operations can all be operations in which a user touches the display screen of the terminal device with a finger, thereby controlling the terminal device. These touch operations can include single-point touch and multi-point touch, where the touch operation at each touch point can include click, long press, hard press, swipe, and the like. The first, second, and third touch operations can also be touch operations performed using input devices such as a mouse and keyboard, without limitation. It is worth noting that the BFF service layer proposed in the embodiments of the present disclosure primarily comprises capabilities such as gateway, access control, interface orchestration, monitoring and alarming, resource hosting, access acceleration, error codes, access modes, disaster recovery, automated detection, and interface mocking. The gateway portion provides security control capabilities such as standard access protocols (HTTP, HTTPS), access port control, access whitelist control, sensitive information verification, and header detection. Access control is divided into two categories: authentication and flow control. Authentication can be considered passive control. For example, when a client accesses a service, the user's product login status is verified. If the login status is expired, the user is redirected to the product login page. Once the login status verification passes, the user is checked to see if they have registered as a tenant in the data management system. If not, registration is automatically initiated. Flow control can be considered active control. For example, when the interface access traffic exceeds the limit, user access is restricted and a retry is initiated on the client. The BFF service layer also imposes timeout limits on backend interfaces. If the waiting time for a response exceeds the timeout limit, the connection is terminated and an access timeout message is returned. In addition to the aforementioned mechanisms, considering the characteristics of the data management system and the fact that traffic and client access volume may vary between different applications, this disclosure designs an application isolation mechanism for the access control module of the BFF service layer. This isolates applications and allocates the total BFF service layer access volume to each application. This prevents large applications from occupying too many resources, leaving smaller applications without them. For interface orchestration, the BFF service layer provides server-side interface aggregation, tailoring, and orchestration capabilities. This orchestration process is visually visualized, lowering the user barrier to entry. For monitoring and alerting, the BFF service layer provides unified monitoring and alerting capabilities. As the middle layer of the entire call chain, the BFF service layer only captures call input, output, duration, and user information. It is unaware of the intermediate service execution process, making this information unavailable for monitoring. Therefore, the BFF service layer primarily monitors interface call traffic, success rate, error statistics, and output logs. Users can configure relevant alerting rules based on this information.In terms of resource hosting, the BFF service layer is responsible for hosting the static resources required by clients, achieving the goal of fully decoupled front-end and back-end collaborative optimization. For example, these files may include Hypertext Markup Language (HTML), JavaScript, JSON, text, and Cascading Style Sheets (CSS). Regarding access acceleration, the BFF service layer supports static resource acceleration, interface acceleration, and first-screen rendering acceleration. Regarding error codes, the BFF service layer primarily provides error information hosting and automatic information mapping. When an interface returns an error code, the BFF service layer maps the error information based on the error code and returns it to the client. Regarding access modes, the BFF service layer supports HTTP, HTTPS, Server-Sent Events (SSE), and WebSocket, which are service scenarios in current data management systems. Regarding disaster recovery, considering cost and service requirements, the BFF service layer can utilize a two-site, three-center approach to mitigate emergencies, eliminating the need for the more costly, same-city, dual-center approach. A data backup mechanism is also provided for data stored within the BFF service layer. Regarding automated detection, the BFF service layer can perform checks on registered server interfaces. This detection may not be real-time, but will be triggered when an interface changes, as well as on a scheduled basis. Exemplary detection content may include horizontal and vertical unauthorized access, heartbeat detection, and compliance checks. Regarding interface mocking, the BFF service layer provides virtual-to-real switching capabilities. Before the server interface is fully implemented, it can be switched to virtual mock data for debugging by client developers. After server development is complete, the real service call can be switched. Furthermore, mock data is persisted within the BFF service layer for subsequent debugging. As can be seen, the front-end and back-end collaborative BFF architecture provided by the disclosed embodiments can address the high collaboration costs and poor user experience associated with the vertically independent division of multiple products in related technologies. The BFF architecture of this disclosed data management system integrates multiple product lines and features the following: A unified gateway consolidates all interfaces under a single domain name, where standardized and strict security controls are established. A unified domain name consolidates all product lines under a few domain names (for example, public cloud, on-premises, and virtual operator domains), using primary and secondary paths to differentiate regions and products.Unified authentication: The BFF service layer handles authentication related to the data management system's tenants and account system, and delivers user-related information to various application services. Unified monitoring and alerting: The BFF service layer monitors unified interface traffic and anomaly alerts, and alerts specific individuals responsible for anomalies. Unified file and configuration hosting: All static resource files and configurations are managed within the BFF service layer, allowing these configurations and files to be shared across applications. In addition to the aforementioned capability integration, the disclosed data management system BFF architecture also offers many value-added collaborative capabilities, such as interface and file acceleration. The BFF platform uses the Carrier Ethernet Network (CEN) enterprise private network to accelerate cross-region access, addressing slow cross-region access. Interface orchestration: The disclosed data management system BFF architecture uses GraphQL technology to aggregate or tailor interfaces, making them more flexible and resilient. Front-end definition files are automatically generated, converting interface input and output parameters into a standard format using JSON Schema, converting them into TypeScript definition files, and syncing them to the front-end. Interface standardization scoring verifies interfaces, identifying and scoring fields that violate naming conventions, fail to use recommended lexicons, or present potential security risks or are redundant. Interface mocking allows the backend to first enter the interface definition and mock data into the BFF service layer without implementing the interface, allowing the frontend to proceed with development based on the mock data. This disclosure addresses the difficulties faced by enterprises implementing traditional BFF models through its orchestration-friendly design for the BFF middle layer. Furthermore, this disclosure addresses the incomplete coverage of production chains in industry solutions, including mocks, automatic TypeScript definition generation, and file / interface acceleration. It is easy to understand that the method for processing interface call requests provided by this disclosure offers the following benefits. Beneficial effect (1): The BFF architecture solution of the disclosed data management system covers the entire production chain, provides Mock, resource hosting, interface visual orchestration and other capabilities in the local development process, and provides complete monitoring and alarm, automatic detection, access acceleration, access control, unified gateway, unified domain name, disaster recovery and other capabilities in the production stage. It is a relatively complete BFF full-link solution.Beneficial effect (2): This disclosure uses GraphQL as the middle layer and uses a visual orchestration method to replace writing GraphQL, so that the R&D cost will not increase due to the introduction of new technologies. It solves the problem that the BFF solution proposed by the related technology based on the serverless cloud framework transfers the cost to the front end, or the solution that combines the API Gateway and BFF modes with the concept of the package manager transfers the cost to the back end, resulting in high R&D and operation and maintenance costs. At the same time, this disclosure limits the capabilities of GraphQL and does not allow direct access to the database. Instead, it accesses the back-end interface through the function mode, solving the security issues caused by GraphQL directly connecting to the database. It should be noted that the user information (including but not limited to user device information, user personal information, etc.) and data (including but not limited to data used for analysis, storage data, display data, etc.) involved in this disclosure are all information and data authorized by the user or fully authorized by all parties, and the collection, use and processing of relevant data must comply with the relevant laws, regulations and standards of relevant countries and regions, and provide corresponding operation entrances for users to choose to authorize or refuse. Furthermore, it should be noted that, for simplicity of description, the aforementioned method embodiments are described as a series of combined actions. However, those skilled in the art should be aware that the present disclosure is not limited by the order of the actions described, as certain steps may be performed in a different order or simultaneously, according to the present disclosure. Furthermore, those skilled in the art should also be aware that the embodiments described in this specification are preferred embodiments, and the actions and modules involved are not necessarily required for the present disclosure. Through the above description of the embodiments, those skilled in the art will clearly understand that the methods according to the aforementioned embodiments can be implemented using software and a necessary general-purpose hardware platform, or alternatively, hardware. Based on this understanding, the technical solution of the present disclosure, or the portion that contributes to the prior art, can be embodied in the form of a software product. This computer software product is stored in a storage medium (e.g., ROM / RAM, a magnetic disk, or an optical disk) and includes instructions for enabling a terminal device (which may be a mobile phone, a computer, a server, or a network device, etc.) to execute the methods described in the various embodiments of the present disclosure.Example 2 In the operating environment of Example 1, the present disclosure provides a method for processing an interface call request as shown in Figure 10. Figure 10 is a flowchart of the method for processing an interface call request according to Example 2 of the present disclosure. As shown in Figure 10, the method includes: Step S1001, sending an interface call request to a server, wherein the interface call request is used to request to call multiple application service interfaces of the server to obtain application service data corresponding to the application service requirements; Step S1002, receiving application service data fed back by the server, wherein the application service data is obtained by the server from the multiple application service interfaces based on an orchestration result, and the orchestration result is obtained by graphically orchestrating the target encapsulation function corresponding to the interface call request according to a preset interface orchestration method, and the preset interface orchestration method is used to obtain application service data from multiple application service interfaces by graphically orchestrating the target encapsulation functions and the connection relationships between the target encapsulation functions, and the target encapsulation functions are used to define interface information of the multiple application service interfaces, and the orchestration result is used to describe the processing process of obtaining the application service data by graphically orchestrating the target encapsulation functions and the connection relationships between the target encapsulation functions. The server can be understood as the BFF server, i.e., the server that provides various application services to the BFF client. The BFF client can be the BFF's corresponding front-end application. It is understood that the BFF coordinates between the front-end application and the server, providing specialized back-end services for the front-end application. In the disclosed embodiments, a BFF service layer is added to the server, enabling better interaction with the client based on the BFF service layer and achieving coordination between the front-end application and the server. An interface call request can be a client call request, i.e., a front-end application call request. An interface call request is used to request multiple application service interfaces on the server to obtain application service data corresponding to the application service requirements. By way of example, the interface call request can be an application programming interface call (API call) or a BFF interface request, used to obtain data, perform operations, or access specific functions, without limitation herein. Application service requirements can be understood as the operational requirements or functional requirements that users need to perform during project development, management, and use. For example, these requirements may be service requirements related to data development or operations management. They may also be information requirements that require querying the server, such as basic user information or operational information. It is understood that application service requirements are determined based on actual user needs and are not limited here.Application service data refers to data, operations, or functions corresponding to application service requirements. For example, if the application service requirement is to query user information, the application service data is user information. If the application service requirement is to call a function, the application service data is the corresponding function, without limitation. In the embodiments of the present disclosure, application service data is obtained by the server from multiple application service interfaces based on the orchestration results. It is understood that an interface call request typically calls one or more interfaces, so reasonable orchestration and planning are required between the interfaces to ensure correct data exchange, message transmission, and call relationships between the interfaces, ensuring that all parts of the system can work together effectively. The orchestration result is the result of orchestrating the interface call request. In the embodiments of the present disclosure, the orchestration result is the result of graphically orchestrating the interface call request according to a preset interface orchestration method. Considering the data security risks associated with users using GraphQL to directly operate on databases in related technologies, the present disclosure does not allow users to write GraphQL to directly operate on databases. The present disclosure accesses server-side interfaces through functions. While ensuring data security, it also ensures that R&D costs will not increase due to the introduction of new technologies. The preset interface arrangement method can be understood as a method of graphically arranging the target encapsulated function and the connection relationship between the target encapsulated functions, that is, a method of arranging the target encapsulated function and the connection relationship between the target encapsulated functions through a visual arrangement mode. For example, the arrangement can be performed on the interface arrangement page. The user can add a new call interface through the directory tree on the interface arrangement page, add new query or change operations to the API to expand the API functionality to meet the needs of the client. In addition, each interface can also be graphically represented. The user can drag and drop functions, compose (Compose) and rename (Rename) elements on the canvas to expand the functionality of the API to meet the needs of the client. In the embodiment of the present disclosure, the graphical function element can display information such as the function's application name, function name, function input parameters, function output parameters, etc., which are not limited here. The preset interface arrangement method can achieve the effect of obtaining the required application service data from multiple application service interfaces by calling the target encapsulated function corresponding to the interface call request. In other words, by using the encapsulated functions corresponding to the interface call requests, multiple application service interfaces on the server can be called to obtain application service data. The target encapsulated function is the function that executes the functions required by the interface call request. This can be an encapsulated function, allowing it to be called multiple times and used independently, improving code reusability and maintainability.The target encapsulation function is used to define interface information for multiple application service interfaces to ensure that they meet interface definition requirements. Exemplarily, the interface information may include the interface name, interface function description, parameter list, return result, error code list, and other content, which is not limited herein. As can be seen, in the embodiments of the present disclosure, graphically orchestrating interface call requests according to a preset interface orchestration method can generate an orchestration result. Application service data can then be obtained from multiple application service interfaces based on the orchestration result. Specifically, the target encapsulation function corresponding to the interface call request can be called based on the orchestration result to obtain application service data from the multiple application service interfaces. In the disclosed embodiment, steps S1001 and S1002 can be applied to a client corresponding to a BFF. The client sends an interface call request to the server and then receives application service data corresponding to the interface call request from the server. The application service data is obtained by the server from multiple application service interfaces based on an orchestration result. The orchestration result is obtained by graphically orchestrating the target encapsulated functions corresponding to the interface call request according to a preset interface orchestration method. The preset interface orchestration method is used to graphically orchestrate the target encapsulated functions and the connections between them to obtain application service data from multiple application service interfaces. As can be seen, the disclosed embodiment utilizes GraphQL as an intermediary layer, employs a visual orchestration method for interface orchestration, and accesses the server interface through functions. This ensures data security while preventing R&D costs from increasing due to the introduction of new technologies, thereby reducing both R&D and operational costs. The above-mentioned method for processing interface call requests provided by the embodiments of the present disclosure can be applied to, but is not limited to, application scenarios involving application service data queries in the fields of e-commerce services, educational services, legal services, medical services, conference services, social network services, financial product services, logistics services, and navigation services, for example, application service data query scenarios for e-commerce services, application service data query scenarios for academic interpretation, application service data query scenarios for medical means, etc., which are not limited here.According to the disclosed embodiments, an interface call request is sent to a server, and application service data corresponding to the interface call request is received from the server in feedback. The application service data is obtained by the server from multiple application service interfaces based on an orchestration result. The orchestration result is obtained by graphically orchestrating the target encapsulated functions corresponding to the interface call request according to a preset interface orchestration method. The preset interface orchestration method is used to graphically orchestrate the target encapsulated functions and the connections between the target encapsulated functions to obtain application service data from the multiple application service interfaces. This achieves the purpose of using GraphQL as an intermediate layer, performing interface orchestration in a visual orchestration method, and accessing the server interface through a function method to obtain the application service data corresponding to the interface call request. This ensures data security while preventing R&D costs from increasing due to the introduction of new technologies, thereby reducing R&D costs and operation and maintenance costs. This solves the technical problem in related technologies of using a serverless cloud framework as an intermediate layer, which leads to difficult operation and maintenance and high R&D and operation and maintenance costs. In an optional embodiment, in step S1001, sending an interface call request to a server includes the following method steps: Step S10011: Sending the interface call request to the server using a preset access domain name, where the preset access domain name is a pre-set unified public cloud domain name. Considering the security risks of directly accessing the server using an application's old domain name, in the embodiment of the present disclosure, when the client sends an interface call request to the server, the preset access domain name is used to send the interface call request to the server. This means that a unified domain name is used to communicate with the BFF service layer, thereby achieving security and improving user experience through a unified domain name. The preset access domain name can be understood as a pre-set unified public cloud domain name, which can consolidate all applications in the data management system under a single domain name. For example, the data management system of the present disclosure can include a unified public domain name, a unified public cloud virtual operator domain name, and a unified internal group domain name, without limitation. After unification, the only domain names perceived by users of the entire data management system are the aforementioned three. Optionally, because the data management system is a region-based product, unlike control products, a region concept is required to differentiate file retrieval from different regions. To distinguish regions, the secondary path of the domain name access can be designed to display region information.For example, taking the unified public domain name (i.e., the first-level path of the access domain name) as "https: / / xxxx.data.kkk.com", the second-level path of the access domain name may be "https: / / xxxx.data.kkk.com / (Region},^". That is, the Region information is displayed on the second-level path of the access domain name. Optionally, after specifying the first-level and second-level paths, the product that the user wants to access can also be distinguished by an identifier. Therefore, the present disclosure designs a third-level path to specify the desired product. For example, taking the first-level path of the access domain name as "https: / / xxxx.data.kkk.com" and the second-level path of the access domain name as "https: / / xxxx.data.kkk.com / (Region}", the third-level path of the access domain name may be "https: / / xxxx.data.kkk.com / {Region} / {product name}". Thus, the third-level path can fully express the user's intention to access a product page under a certain Region. In an optional embodiment, the domain name resolution result of the preset access domain name is used to map the interface call request to the server closest to the client sending the interface call request. In this embodiment of the present disclosure, after a user accesses a domain name, the domain name accessed by the user is resolved to obtain a domain name resolution result. This disclosure designs the BFF service layer to have the capabilities of a content delivery network (CDN). When a user accesses a unified public domain name, the domain name resolution is mapped to the server closest to the user, thereby achieving static resource acceleration. For example, Xiaomei, who lives in Hangzhou, accessed service A in the western United States purchased by her company. The domain name is "https: / / xxxx.data.kkk.com / us-west-1." ,5After domain name resolution, Xiaomei's access request is actually mapped to the BFF server in Hangzhou, which provides static resources to Xiaomei. This indicates that the domain name resolution result of the preset access domain name in the present disclosure is used to map the interface call request to the server closest to the client sending the interface call request, thereby accelerating static resources. Alternatively, cross-regional user access often results in slow access. To address this issue, the present disclosure is designed to accelerate the interface through the BFF. When a client accesses an interface, similar to the principles of a CDN, it first accesses the BFF server closest to the client. The BFF server then accelerates access to a BFF server in the designated region via a dedicated line. Finally, the BFF server in the designated region forwards the request to the actual interface service in the designated region. For example, the BFF server can be deployed at the same location as the application, ensuring minimal latency when connecting to the actual interface service after passing through the acceleration channel. In an optional embodiment, the method for processing an interface call request further includes the following steps: Step S10031, obtaining a data package to be synchronized from a server using a command line mode, wherein the data package to be synchronized includes: a source code file to be synchronized and a code type file to be synchronized, wherein the source code file to be synchronized and the code type file to be synchronized are used to describe the interface call logic; Step S10032, updating a local historical source code file based on the source code file to be synchronized, and updating a local historical code type file based on the code type file to be synchronized. In this disclosed embodiment, the command line mode may be a command line interface (CLI), i.e., a CLI command line. The data package to be synchronized may be a Node Package Manager (npm) package, which may include the source code file to be synchronized, i.e., a JavaScript file, and the code type file to be synchronized, i.e., a TypeScript file. It is understood that the JavaScript file includes interface call logic, which is used to implement the interface call logic, such as operations such as constructing a request, sending a request, and processing a response. JavaScript files also process the data returned by the API, parsing and transforming it, presenting it to the user, or passing it to other parts of the application. TypeScript files define the data types and structure of the interface, providing type safety and syntax checking to ensure that the parameters and return values ​​of the API calls meet expectations.TypeScript files can also be converted into JavaScript files through a compiler for execution in a browser. In the disclosed embodiments, npm packages can be updated using CLI commands. For example, a CLI command line can be used to obtain npm packages from a server. Local JavaScript files can then be updated based on the JavaScript files in the npm package. Simultaneously, local TypeScript files can be updated based on the TypeScript files in the npm package. This avoids the high cost of frequent npm package releases due to frequent BFF releases. Furthermore, this update method can also be effective during continuous integration (CI) cloud builds. It is worth noting that the client corresponding to the BFF in the disclosed embodiments can consist of remote procedure calls (RPCs), API calls, a static web page generator (Incremental Static Regeneration (ISR)) and auxiliary tools. RPC can be understood as a method of automatically encapsulating the BFF interface and then providing the encapsulated interface to the client user for direct call. This disclosure effectively isolates the interface call process through its RPC-based approach, eliminating the need for client users to know service-independent information such as how the client establishes a connection with the BFF service layer and the meaning of request parameters. This disclosure separates JavaScript and TypeScript files at the underlying layer. When a client downloads an npm package, it can request the latest JavaScript and TypeScript files from the remote BFF via Postinstall 1. Later, if the client needs the latest npm package, it can update it via the CLI. This avoids the issue of frequent npm package releases caused by the BFF service layer. This update method also works when running CI cloud builds. This disclosure encapsulates an API call library at the underlying RPC layer to address issues related to BFF service layer calls. This underlying library provides security-related methods, including protection against cross-site request forgery tokens (CSRF) and cross-site scripting attacks (XSS).This also solves the problem of maintaining a single CSRF token cache across multiple applications. The underlying library also provides basic REST call methods, such as POST and GET, as well as streaming data types (Server-Sent Events, SSE) and cross-domain JSONP call methods. Furthermore, the underlying library offers a rich set of hooks, including pre- and post-request hooks, data validation hooks, and data processing hooks. These hooks help access control better manage the request process and data. Regarding error display, because the disclosed data management system has unified error reporting logic and display interface, an error display component is also encapsulated in the client, eliminating the need for client users to handle error logic themselves. BFF processing primarily involves mapping application domain names to BFF domain names, distinguishing between pre-launch and production environments, and converting request parameters (the BFF server has requirements for request parameters). Finally, the API call library also provides auxiliary tools, such as the abort method for aborting requests and reconnection logic for rate limiting. Regarding the ISR builder, since most engineering systems within the data management system of this disclosure have switched from webpack to vite, this section primarily provides a builder for the vite system. The vite builder provides build hooks, which we use to generate static resource files and upload them to a remote BFF server. Regarding auxiliary tools, this disclosure has developed a toolkit for page-to-page transitions to address the cost of transitioning between applications under a unified domain name. Figure 11 is a schematic diagram of the design principles of a toolkit according to Example 2 of this disclosure. As shown in Figure 11, after the client user (producer) registers the transition logic code in a designated directory within the code, the code is published through a CI tool. The builder then automatically generates the transition configuration and usage documentation, which are then synchronized to the remote server. When other users (consumers) want to jump to the producer's application, they can refer to the usage documentation, directly obtain the registered instructions from the usage documentation, and write them directly into the code to perform page jumps or instruction calls within the service code. This can reduce the communication cost between producers and consumers and improve the efficiency of unified domain name migration.In an optional embodiment, the method for processing an interface call request further includes the following steps: Step S10041: Receiving a preset error code and error information from the server, wherein the preset error code is obtained by the server based on call failure events of multiple application service interfaces, and the error information is obtained by searching for the preset error code; Step S10042: Displaying a page indicating a failure to call a data source service, wherein the content displayed on the page indicating a failure to call a data source service includes at least the preset error code and error information. The preset error code can be understood as a pre-set code indicating the cause of an error at the interface layer, and the error information can be understood as information used to further explain the cause of the error at the interface layer and provide guidance on a solution. It is understood that if an error occurs at the interface layer when the server receives the interface call request from the client and executes processing logic, i.e., a call failure event occurs, the server can provide the preset error code and error information to the client. The preset error code is obtained by the server based on call failure events of multiple application service interfaces, and the error information is obtained by searching for the preset error code. For example, the BFF service layer can search for the error information based on a preset error code fed back by the server. After receiving the error code, the BFF service layer searches for the entered error information based on the error code and then feeds both the error code and the error information back to the client. In the disclosed embodiment, the client can receive the preset error code and error information from the server and display a page indicating a failure to call the data source service. The content displayed on the page includes at least the preset error code and error information. For example, the page indicating a failure to call the data source service can be shown in FIG. 9 and will not be further described here. In an optional embodiment, the method for processing an interface call request further includes the following method steps: Step S10051, generating a first static page using a preset static page generation method, wherein the first static page includes: page initial composition information, the page initial composition information including a page header and a menu bar; Step S10052, synchronizing the first static page to the server, so that when the target static page is accessed through the interface call request, the page initial composition information is first rendered; Step S10053, generating a second static page after the rendering of the page initial composition information is completed, wherein the second static page includes the remaining components of the target static page except the first static page; Step S10054, synchronizing the second static page to the server, so that the target static page is rendered on the first static page.To improve the user experience of the data management system, embodiments of the present disclosure incorporate features such as a unified domain name, static resource acceleration, interface acceleration, client first-page rendering acceleration, and unified error codes / prompts. Specifically, in terms of client first-page rendering acceleration, the present disclosure supports incremental static page regeneration (ISR) at the BFF service layer. While there are many approaches to client first-page rendering, such as server site rendering (SSR) and static site generation (SSG), the current state of data management systems, characterized by the excessive presence of legacy service code and unique architectures, makes the use of SSR prohibitively expensive. Furthermore, given the inherent service characteristics of data management systems, where the vast majority of applications are dynamic and relatively static, the SSG solution is also unsuitable. Therefore, the ISR approach is relatively well-suited for data management systems. The present disclosure can employ the ISR approach, compiling static HTML for first-page rendering when code is submitted to the continuous integration service (CI). This static HTML contains some of the initial page components, such as a common header and menu bar. This HTML code is then synchronized to the BFF server. As a result, when a user accesses the page, the header and menu bar are directly rendered on the first screen, and the remaining content is dynamically loaded using JavaScript. Figure 12 is a flowchart for first screen rendering according to Example 2 of the present disclosure. As shown in Figure 12, during first screen rendering on the client, static HTML for first screen rendering is first constructed based on the source code. This constructed static HTML includes the initial page components, such as the common header and menu bar. This static HTML code is then synchronized to the static server (BFF server) so that when the user accesses the page, the first screen can be directly rendered in a web browser. Figure 13 is a schematic diagram of a page rendered on the first screen according to Example 2 of the present disclosure. As shown in Figure 13, before the user accesses the page (i.e., during the process of constructing static HTML for first screen rendering based on the source code and synchronizing the static HTML code to the static server), the initial page components, such as the common header and menu bar, can be constructed in advance. When the user accesses the page, the first screen in the web browser is directly rendered.In embodiments of the present disclosure, the preset static page generation method can be an ISR method, and the target static page can be static HTML, where the static HTML includes the initial page composition information. When performing first-screen rendering based on an interface call request, the present disclosure can employ an ISR method. First, a first static page including the initial page composition information is generated, namely, static HTML including the initial page composition information is generated and synchronized to the server, thereby rendering the first static page including information such as the page header and menu bar. JavaScript is then used to dynamically load the remaining content of the target static page, namely, to generate the remaining components of the target static page excluding the first static page, thereby generating a second static page. This is then synchronized to the server, and the complete target static page is rendered based on the first static page, namely, the client's first-screen page. This improves access quality and user experience. It is worth noting that the BFF client in embodiments of the present disclosure primarily consists of applications and BFF components. The application component can include applications such as data development, operations and maintenance center, data analysis, data quality, data governance, data modeling, data integration, and data services. This disclosure does not adjust the application part, but adjusts from the BFF component layer to reduce a lot of manpower investment.

[0018] The BFF component includes functions such as BFF interface requests, notifications and error codes, external link redirection, CSRF verification, unified domain name redirection, TypeScript auto-generation tools, and an ISR builder. First, the BFF component is responsible for making interface requests with the BFF, processing the BFF's access domain name, interface format, input and output parameters, and error handling, thereby satisfying the requirements of calling the BFF interface on the service. Error notifications and error codes are displayed on the page based on the return content of the BFF interface request component, unifying the error display logic. The external link redirection component primarily handles the logic for redirecting between applications after domain name unification. This requires adjustments to existing inter-application redirection logic. This unified external link redirection decouples inter-application redirection by decoupling the coupling between applications, requiring developers to only know the target application name and parameters.

[0019] For CSRF verification, the BFF component is responsible for obtaining and passing the CSRF token during API requests, allowing client developers to focus solely on writing service logic. The unified domain redirection logic primarily addresses situations where existing customers continue to access the old domain after an old application has been migrated. In this case, the BFF component must handle redirection from the old domain to the new one.

[0020] The TypeScript auto-generation tool helps client developers quickly master interface usage using the editor's code hints during development. This disclosure also provides a command-line tool that developers can use to synchronize remote BFF information and instantly update local definition files.

[0021] The ISR builder part is to build static resources through the ISR building tool during the front-end compilation phase, and synchronize the static resources to the remote BFF service layer for use by clients when accessing. It is easy to understand that the beneficial effects of the method for processing interface call requests provided by the present disclosure also include the following points. Beneficial effect (3): The present disclosure uses the command line mode to update the npm package and restart the code verification capability of the editor, thereby solving the framework binding problem and introduction cost problem caused by the need to bind the scaffolding to produce the front-end TypeScript definition in the related art. It should be noted that the preferred implementation of this embodiment can be found in the relevant description of Example 1, and will not be repeated here. Example 3 Under the operating environment as in Example 1, the present disclosure provides a system for processing interface call requests as shown in Figure 14. FIG14 is a schematic diagram of a system for processing interface call requests according to Embodiment 3 of the present disclosure. As shown in FIG14 , the system includes: a front-end and back-end collaborative server 1401, configured to receive an interface call request from a front-end and back-end collaborative client, graphically orchestrate a target encapsulated function corresponding to the interface call request according to a preset interface orchestration method to obtain an orchestration result, obtain application service data from multiple application service interfaces based on the orchestration result, and feed the application service data back to the front-end and back-end collaborative client; a front-end and back-end collaborative client 1402, configured to send an interface call request to the front-end and back-end collaborative server and receive application service data fed back by the server; wherein the interface call request is used to request to call multiple application service interfaces of the server to obtain application service data corresponding to application service requirements, the preset interface orchestration method is used to graphically orchestrate target encapsulated functions and connection relationships between target encapsulated functions to obtain application service data from multiple application service interfaces, the target encapsulated functions are used to define interface information of multiple application service interfaces, and the orchestration result is used to describe the processing process of obtaining application service data by graphically orchestrating the target encapsulated functions and the connection relationships between the target encapsulated functions. The system for processing interface call requests in the disclosed embodiment includes a front-end / back-end collaborative server (BFF Server) 1401 and a front-end / back-end collaborative client (BFF Client) 1402. The BFF Client can be understood as the front-end application corresponding to the BFF, and the BFF Server is the server that provides various application services to the BFF Client. It is understood that the BFF is used to coordinate between the front-end application and the server, providing specialized back-end services for the front-end application.In the disclosed embodiments, a BFF service layer is added to the server, enabling better interaction with the client based on the BFF service layer and achieving coordination between the front-end application and the server. An interface call request can be understood as a call request from the BFF client, that is, a call request from the front-end application. This interface call request is used to invoke multiple application service interfaces on the BFF server to obtain application service data corresponding to the application service requirements. Exemplarily, the interface call request can be an application programming interface call (API call) or a BFF interface request, used to obtain data, perform operations, or access specific functions, without limitation. Application service requirements can be understood as operational requirements or functional requirements that users need to perform during project development, management, and use. Exemplarily, these can be service requirements related to data development or operations management, or information requirements that require querying the server, such as basic user information or operational information. It is understood that application service requirements are determined based on the user's actual needs and are not limited here. Application service data refers to data, operations, or functions corresponding to application service requirements. For example, if the application service requirement is to query user information, the application service data is user information. If the application service requirement is to call a function, the application service data is the corresponding function, which is not limited here. The target encapsulated function is a function that executes the functions required by the interface call request. It can be a packaged function, so that the function can be called multiple times and used independently, improving the reusability and maintainability of the code. The target encapsulated function is used to define the interface information of multiple application service interfaces to ensure that they meet the requirements of the interface definition. For example, the interface information may include the interface name, interface function description, parameter list, return result, error code list, etc., which is not limited here. It is understandable that the interface called by the interface call request usually includes one or more interfaces. Therefore, reasonable arrangement and planning between the interfaces are required to ensure that data exchange, message transmission, call relationships, etc. between the interfaces are correct, ensuring that the various components of the system can work together effectively. The BFF proposed in the embodiments of the present disclosure The service layer has improved the design of Graph Query Language (GraphQL) and restricted some of GraphQL's functions.Considering the data security risks associated with users using GraphQL to directly manipulate databases in related technologies, this disclosure does not allow users to write GraphQL to directly manipulate databases. Instead, this disclosure uses functions to access server-side interfaces, ensuring data security while minimizing the increase in R&D costs associated with introducing new technologies. The pre-defined interface orchestration method can be understood as a graphical arrangement of target encapsulated functions and the connections between them, specifically a visual arrangement of target encapsulated functions and the connections between them. For example, orchestration can be performed on the interface orchestration page, where users can add new call interfaces through a directory tree, adding new queries or mutation operations to the API to expand API functionality to meet client needs. Furthermore, interfaces can be graphically represented, allowing users to extend API functionality by dragging and dropping functions, composing, and renaming elements within the canvas to meet client needs. In the embodiments of the present disclosure, the graphical function element may display information such as the function's application name, function name, function input parameters, and function output parameters, without limitation. Graphically orchestrating the target encapsulated function corresponding to the interface call request according to a preset interface orchestration method enables the acquisition of required application service data from multiple application service interfaces by invoking the target encapsulated function corresponding to the interface call request. In other words, the encapsulated function corresponding to the interface call request can be used to call multiple application service interfaces on the server side to obtain application service data. Figure 15 is a diagram of a BFF system architecture according to Embodiment 3 of the present disclosure. As shown in Figure 15, the system architecture includes a client, a BFF service layer, and a server. Access between the client and the BFF service layer is based on the BFF unified access domain name, and access between the BFF service layer and the server is based on the intranet. The client primarily consists of applications and BFF components. The application component may include applications such as data development, operations and maintenance center, data analysis, data quality, data governance, data modeling, data integration, and data services. The BFF component includes functions such as BFF interface requests, report prompts and error codes, external link redirection, CSRF verification, unified domain name redirection, TypeScript (TS) automatic generation tools, and an ISR builder. For details, please refer to the description in Example 2 and will not be repeated here.

[0022] The BFF service layer primarily comprises capabilities such as gateway, access control, interface orchestration, monitoring and alarming, resource hosting, access acceleration, error codes, access modes, disaster recovery, automated detection, and interface mocking. The gateway provides capabilities such as access protocols, access ports, access whitelists, sensitive information verification, and header detection. Access control provides authentication and flow control. Authentication includes platform authentication, tenant authentication, role authentication, and automatic redirection for login failures. Flow control includes rate limiting, client retries, and timeout control. Application isolation is also included. Interface orchestration provides interface aggregation, interface slicing, and visual orchestration. Monitoring and alarming provide monitoring capabilities such as flow, success rate, error statistics, logging, and rule-based alarming. Resource hosting supports file types such as HTML, JavaScript (JS), JSON, text, and Cascading Style Sheets (CSS). Access acceleration provides interface acceleration, static resource acceleration, and client first-screen acceleration. Error codes provide functions such as error information hosting and automatic information mapping. Access modes support HTTP, HTTPS, SSE, and network communication protocols. Disaster recovery provides two-site, three-center, and data backup capabilities. Automated detection provides functions such as horizontal and vertical authorization, interface specification, and heartbeat detection. Interface simulation provides functions such as virtual-to-real switching and simulated data persistence. For details, please refer to the description in Example 1 and will not be elaborated here. The system for processing interface call requests provided in the embodiments of the present disclosure can be applied, but is not limited to, in application scenarios involving application service data queries in e-commerce services, education services, legal services, medical services, conference services, social network services, financial product services, logistics services, and navigation services. For example, application service data query scenarios for e-commerce services, academic interpretation applications, and medical treatment applications, etc., without limitation here.According to an embodiment of the present disclosure, a system for processing interface call requests provided by the present disclosure includes a front-end and back-end collaborative server and a front-end and back-end collaborative client. The front-end and back-end collaborative server is configured to receive the interface call request from the front-end and back-end collaborative client, graphically orchestrate the interface call request according to a preset interface orchestration method to obtain an orchestration result, obtain application service data from multiple application service interfaces based on the orchestration result, and feed the application service data back to the front-end and back-end collaborative client. The front-end and back-end collaborative client is configured to send an interface call request to the front-end and back-end collaborative server and receive the application service data fed back by the server. The interface call request is configured to request to call multiple application service interfaces of the server to obtain application service data corresponding to application service requirements. The preset interface orchestration method is configured to graphically orchestrate target encapsulated functions and connection relationships between the target encapsulated functions to obtain application service data from multiple application service interfaces. The target encapsulated functions are configured to define interface information of the multiple application service interfaces. The orchestration result is configured to describe the process of obtaining application service data by graphically orchestrating the target encapsulated functions and the connection relationships between the target encapsulated functions. This achieves the goal of using GraphQL as an intermediary layer, employing a visual orchestration approach for interface orchestration, and accessing server-side interfaces through functions to obtain the application service data corresponding to interface call requests. This ensures data security while also preventing R&D costs from increasing due to the introduction of new technologies, thereby reducing both R&D and operation and maintenance costs. This addresses the technical issue in related technologies where the use of serverless cloud frameworks as an intermediary layer leads to operational difficulties and high R&D and operation and maintenance costs. Notably, the BFF service layer in this embodiment of the present disclosure is optimized and developed in five areas: service security, high service availability, improved user experience, collaborative optimization, and additional value-added capabilities. Figure 16 is a schematic diagram of BFF capabilities according to Example 3 of the present disclosure. As shown in Figure 16, service security encompasses three major areas: a unified gateway, unified authentication, and a unified domain name. The unified gateway is intended to enable BFF to prevent attacks and verify sensitive information. In terms of attack prevention, BFF, as the unified gateway of the data management system, is expected to defend against all external attacks, allowing the application server to focus on service code development. Currently, BFF attack prevention measures include CSRF token verification, access whitelist control, access port restrictions, and login status verification. For sensitive information verification, the BFF service layer can scan output for sensitive information and fields with security risks, such as interface fields or server-side logic that may contain horizontal unauthorized access. Unified authentication can include both product and tenant authentication.Service high availability primarily consists of four components: flow control, monitoring, alerting, and disaster recovery. Flow control is further divided into flow limiting, client retry, and timeout control. Users can configure flow limiting rules based on historical interface data. When the number of accesses exceeds the limit, a specific error code is returned and a client retry is initiated. Timeouts can also be set for interface accesses to ensure availability. Monitoring focuses on interface traffic, success rate, and error statistics. Furthermore, BFF monitoring is expected to generate customized log error statistics based on output information. However, BFF does not monitor non-user-triggered interface calls, such as those triggered by internal timers. For alerting, users are expected to configure their own alerting rules, such as issuing alerts when traffic exceeds a certain percentage. Alerts can be sent via application or phone. For disaster recovery, BFF provides basic remote disaster recovery capabilities, and the server interface itself also has remote disaster recovery capabilities. User experience enhancements primarily include unified domain names, static resource acceleration, interface acceleration, client first-screen rendering acceleration, and unified error codes and prompts. For details, see Examples 1 and 2, and will not be elaborated on here. Collaborative optimization primarily includes automatic TypeScript (TS) definition generation, interface simulation, service orchestration, BFF static resource hosting, configuration of shared caches, and interface standardization. First, regarding service orchestration capabilities, it is hoped that the data management system (BFF) can support serial and parallel calls of multiple interfaces and be able to aggregate or trim data, thereby making client interfaces more flexible. If the client needs to add fields due to service requirements, this can be implemented automatically through the BFF service layer without requiring server-side modification. Furthermore, it is hoped that the data management system (BFF) can provide the ability to automatically generate TypeScript definitions. This capability eliminates the need for client users to write TypeScript definitions themselves, making the code more maintainable and saving server-side users the trouble of handwritten documents. Regarding interface mocking, it's hoped that mock data can be set up on the BFF before the server-side interface is implemented. This allows client developers to quickly begin development without having to wait for the server-side interface to be fully developed. Once the server-side user completes development, the mocking function can be disabled on the BFF, allowing the client to access the real interface data.Regarding static resource hosting, the BFF service layer is expected to host some static resource files needed by the frontend, such as HTML and some required JS and CSS files (preferably placed on a CDN, but in special cases, on the BFF). Combined with unified gateway invocation, this will achieve true frontend and backend decoupling, thereby improving collaborative efficiency. It is also expected that the BFF platform service will provide cloud-based editing capabilities to help client developers quickly develop and release content. Regarding interface standardization, the data management system disclosed herein references the point-of-presence (POP) interface specifications and makes some adjustments, primarily by changing from big camelCase to small camelCase, adjusting the resource-oriented architecture (ROA) style to the RPC style, and removing some vocabulary specifications to retain commonly used and universal characters in actual usage scenarios. Furthermore, it is desirable to check interface compliance at the BFF service layer. This check is non-binding and will not hinder interface development and release. Each interface can also be scored for health, allowing developers to determine whether the current interface requires optimization based on the score. For details, see Examples 1 and 2; we will not elaborate further here. Value-added capabilities primarily include third-party access, upload / download, version notes, SSE, and network communication protocols. Currently, BFF capabilities can be used in some scenarios to better meet service requirements. First, third-party access scenarios. With BFF, third-party requests can be quickly met. For example, a customer recently requested intranet access, which can be quickly modified and adapted using BFF. Furthermore, BFF can be used as a hub to quickly connect to Object Storage Service (OSS) to achieve upload / download capabilities. Furthermore, applications with the ability to generate release notes can also be implemented through BFF. BFF records release-related information and stores it in JSON format, eliminating the need for server-side development and directly meeting service requirements. The API documentation page design for the BBF system provided in the embodiments of the present disclosure may be shown in FIG17 , which is a schematic diagram of an API documentation page according to Embodiment 3 of the present disclosure. The API documentation page is primarily intended for client developers, allowing them to quickly browse all entered BFF APIs. The directory structure is organized by application name, such as data analysis, data integration, and data development.Search is available in the upper left corner, and search criteria can be switched based on file name, folder name, comments, code content, and more. The example on the right shows the details of an API, including a description, examples, request parameters, return parameters, and maintainer. The example section allows users to directly run sample code and display the return value in the output box. The sample code is read-only and can be modified during creation or editing. The request parameters section includes the name, type, whether it is required, sample value, and description. This information is automatically generated by parsing the GraphQL content of the BFF API. The return data section includes the name, type, sample value, and description. Due to the long history of data management systems, most services do not have a domain model, and establishing a domain model in the short term is difficult. Considering the feasibility of the solution, users are not currently required to fill in the domain model. Instead, the object type can be used. As a result, the return data may be unpredictable. In related art, the BFF service predicts and resolves a file by obtaining a return value from a single call, potentially leading to missed resolutions. Therefore, the present disclosure provides a manual editing method, allowing users to add and write annotations. The static resource management page design of the BBF system provided in this embodiment can be shown in Figure 18 . Figure 18 is a schematic diagram of a static resource management page according to Embodiment 3 of this disclosure. The static resource management page allows for the creation and management of file types such as JSON, HTML, JavaScript, and CSS. Users can create files by adding them to the directory tree on the left. The panel on the right displays the file's description, mapping route, login requirement, contact person, redirect address when not logged in, and text content. Figure 19 is a schematic diagram of a file creation and editing page according to Embodiment 3 of this disclosure. As shown in Figure 19 , when creating or editing a file, the user must specify the file name, file type (JSON, HTML, JavaScript, or CSS), contact person, mapping route, file description, login requirement, redirect address when not logged in, and text content. The mapping route is generated by default based on the file directory structure, but can be modified by the user. FIG20 is a schematic diagram of a monitoring dashboard page according to Example 3 of the present disclosure. As shown in FIG20 , users can obtain information about the health of their team's interfaces in the monitoring dashboard. For example, the dashboard includes information such as application overview, focus areas, call success rate, number of calls, yesterday's call duration, error rankings for the past month, and interface and file distribution.The application overview primarily displays each application's health score, number of alerts and errors over the past seven days, compliance score, number of slow interfaces, and total throttling over the past seven days, helping users assess the health of application interfaces. The focus section displays information such as the number of interface errors reported today, the number of throttling rules triggered today, the call success rate today, the compliance score today, newly added interfaces today, newly added files today, and the number of releases and deletions today, helping users perform maintenance and identify changes. The call success rate section ranks success rates from lowest to highest based on interface, application, and responsible person, helping to identify interfaces requiring management. The call count section ranks interfaces from highest to lowest based on interface, application, and responsible person, identifying interfaces with high call volume and re-protecting them. Yesterday's call duration section ranks the top 30 interfaces by call duration from highest to lowest to identify interfaces with prolonged call times. The error ranking section for the past month summarizes the total number of interface errors reported within the past month and displays the top 30 errors, ranked from largest to smallest, to help users identify interfaces requiring management. The interface distribution section breaks down the proportion of interfaces by application and responsible person. Similar to the interface distribution, the file distribution by responsible person or application is displayed. In summary, the full-link BFF solution proposed in this disclosure, covering gateways, access control, interface orchestration, monitoring and alerting, resource hosting, access acceleration, error codes, diverse access modes, disaster recovery, automated detection, and interface mocking, offers superior coverage compared to other solutions. Furthermore, this disclosure utilizes GraphQL as an intermediary layer and employs a visual orchestration approach to orchestrate interfaces. GraphQL usage restrictions are also implemented, and backend interfaces are accessed in function mode, mitigating the risks of direct database connections. Furthermore, this disclosure utilizes command-line mode to update npm packages and restart the editor's code verification capabilities, addressing framework binding issues and introduction costs. It should be noted that the preferred implementation of this embodiment can refer to the relevant description in Example 1 and will not be repeated here. Example 4 According to an embodiment of the present disclosure, an apparatus embodiment for implementing the above-mentioned method for processing an interface call request is also provided.FIG21 is a schematic structural diagram of an apparatus for processing an interface call request according to Embodiment 4 of the present disclosure. As shown in FIG21 , the apparatus includes: a receiving module 2101, configured to receive an interface call request from a client, wherein the interface call request is used to request calling multiple application service interfaces of a server to obtain application service data corresponding to the application service requirements; an orchestration module 2102, configured to graphically orchestrate the target encapsulation function corresponding to the interface call request according to a preset interface orchestration method to obtain an orchestration result, wherein the preset interface orchestration method is used to graphically orchestrate the target encapsulation function and the connection relationship between the target encapsulation functions to obtain application service data from multiple application service interfaces, the target encapsulation function is used to define interface information of multiple application service interfaces, and the orchestration result is used to describe a processing process of obtaining application service data by graphically orchestrating the target encapsulation function and the connection relationship between the target encapsulation functions; a first acquisition module 2103, configured to acquire application service data from the multiple application service interfaces based on the orchestration result; and a feedback module 2104, configured to feed back the application service data to the client. Optionally, the apparatus further includes: a creation module configured to create an initial program code block for multiple application service interfaces; configure function information for the initial program code block to obtain a target program code block, wherein the function information defines at least some or all of the following information: function name, calling method, server access points corresponding to the multiple application service interfaces, function description, and parameter configuration; and encapsulate the target program code block to obtain a target encapsulated function. Optionally, the orchestration module 2102 is further configured to: select a target encapsulated function corresponding to an interface call request from candidate encapsulated functions according to a preset interface orchestration method; determine a connection relationship between the target encapsulated functions based on interface relationships between the multiple application service interfaces; and graphically orchestrate the target encapsulated functions and the connection relationships to obtain an orchestration result. Optionally, the orchestration module 2102 is further configured to: determine, in response to the interface relationship indicating a dependency relationship between the multiple application service interfaces, that the connection relationship is a serial connection relationship between the target encapsulated functions; and determine, in response to the interface relationship indicating no dependency relationship between the multiple application service interfaces, that the connection relationship is a parallel connection relationship between the target encapsulated functions.Optionally, the orchestration module 2102 is further configured to: in response to obtaining application service data from multiple data sources on the server side via multiple application service interfaces, aggregate the input parameters and output parameters of the target encapsulated function based on the connection relationship to obtain a first orchestration result; and in response to the current data content obtained from the server side via the multiple application service interfaces being greater than the data content of the application service data, trim the input parameters and output parameters of the target encapsulated function based on the connection relationship to obtain a second orchestration result. Optionally, the apparatus further includes: a control module configured to employ a preset access control method to perform access control on interface call requests, wherein the preset access control method includes at least one of the following: access authentication on interface call requests; flow control on interface call requests; and pre-allocation of access volume corresponding to application service data. Optionally, the apparatus further includes: a second acquisition module configured to, in response to failures in calling multiple application service interfaces, obtain a preset error code corresponding to the call failure event; search for pre-recorded error information based on the preset error code; and feed the preset error code and error information back to the client. Optionally, a graphical user interface is provided through a cloud device, and content displayed by the graphical user interface at least partially includes an application service data query scenario. The apparatus further includes: an interaction module configured to, in response to a first control operation performed on the graphical user interface, select a target encapsulated function corresponding to the interface call request from candidate encapsulated functions, wherein function elements of the target encapsulated function include: a function application name, a function name, function input parameters, and function output parameters; in response to a second control operation performed on the graphical user interface, determine a connection relationship between the target encapsulated functions based on interface relationships of multiple application service interfaces; in response to a third control operation performed on the graphical user interface, aggregate and / or trim the input parameters and output parameters of the target encapsulated function based on the connection relationship to obtain an orchestration result; and display the orchestration result in the graphical user interface.According to an embodiment of the present disclosure, an interface call request from a client is received, and then graphically orchestrates the target encapsulated function corresponding to the interface call request according to a preset interface orchestration method to obtain an orchestration result. Based on the obtained orchestration result, namely, graphically orchestrates the target encapsulated function and the connection relationship between the target encapsulated functions, an orchestration result describing the process of obtaining application service data through the graphical orchestration of the target encapsulated function and the connection relationship between the target encapsulated functions is obtained. By calling the target encapsulated function corresponding to the interface call request, application service data corresponding to the application service demand is obtained from multiple application service interfaces on the server side. Finally, the obtained application service data is fed back to the client. This achieves the purpose of using GraphQL as an intermediary layer, performing interface orchestration in a visual orchestration method, and accessing the server-side interface through a function method. This ensures data security while preventing R&D costs from increasing due to the introduction of new technologies, thereby reducing R&D costs and operation and maintenance costs. This further solves the technical problem in related technologies of using a serverless cloud framework as an intermediary layer, which leads to operational difficulties and high R&D and operation and maintenance costs. It should be noted that the receiving module 2101, the orchestration module 2102, the first acquisition module 2103, and the feedback module 2104 described above correspond to steps S21 to S24 in Example 1. The examples and application scenarios implemented by these four modules and the corresponding steps are the same, but are not limited to the content disclosed in Example 1. It should be noted that the above modules or units may be hardware components or software components stored in a memory (e.g., memory 104) and processed by one or more processors (e.g., processors 102a, 102b, ..., 102n). The above modules may also be part of an apparatus and run in the computer terminal 10 provided in Example 1. According to an embodiment of the present disclosure, another apparatus embodiment for implementing the above method for processing an interface call request is also provided.FIG22 is a schematic structural diagram of another apparatus for processing an interface call request according to Embodiment 4 of the present disclosure. As shown in FIG22 , the apparatus includes: a sending module 2201 configured to send an interface call request to a server, wherein the interface call request is used to request calling multiple application service interfaces of the server to obtain application service data corresponding to the application service requirements; and a receiving module 2202 configured to receive application service data fed back by the server, wherein the application service data is obtained by the server from the multiple application service interfaces based on an orchestration result. The orchestration result is obtained by graphically orchestrating target encapsulation functions corresponding to the interface call request according to a preset interface orchestration method. The preset interface orchestration method is used to graphically orchestrate target encapsulation functions and connection relationships between target encapsulation functions to obtain application service data from multiple application service interfaces. The target encapsulation functions are used to define interface information of the multiple application service interfaces. The orchestration result is used to describe a processing procedure for obtaining application service data by graphically orchestrating the target encapsulation functions and the connection relationships between the target encapsulation functions. Optionally, the sending module 2201 is further configured to: send an interface call request to the server using a preset access domain name, where the preset access domain name is a pre-set unified public cloud domain name. Optionally, the domain name resolution result of the preset access domain name is used to map the interface call request to the server geographically closest to the client sending the interface call request. Optionally, the apparatus further includes: an acquisition module configured to acquire a data packet to be synchronized from the server using a command line mode, where the data packet to be synchronized includes: a source code file to be synchronized and a code type file to be synchronized, where the source code file to be synchronized describes the call logic for the interface, and the code type file to be synchronized describes the data type and structure of the interface; and to update a local historical source code file based on the source code file to be synchronized, and to update a local historical code type file based on the code type file to be synchronized. Optionally, the device further includes: a display module configured to receive a preset error code and error information from the server, wherein the preset error code is obtained by the server based on call failure events of multiple application service interfaces, and the error information is searched based on the preset error code; and display a page indicating a failure to call a data source service, wherein the display content on the page indicating a failure to call a data source service includes at least the preset error code and error information.Optionally, the device further includes: a rendering module, configured to generate a first static page using a preset static page generation method, wherein the first static page includes: page initial composition information, the page initial composition information including a page header and a menu bar; synchronizing the first static page to a server, so that when a target static page is accessed through an interface call request, the page initial composition information is first rendered; after the rendering of the page initial composition information is completed, generating a second static page, wherein the second static page includes the remaining components of the target static page except the first static page; synchronizing the second static page to the server, so as to render the target static page on the first static page. According to the disclosed embodiments, an interface call request is sent to a server, and application service data corresponding to the interface call request is received from the server in feedback. The application service data is obtained by the server from multiple application service interfaces based on an orchestration result. The orchestration result is obtained by graphically orchestrating the target encapsulated functions corresponding to the interface call request according to a preset interface orchestration method. The preset interface orchestration method is used to graphically orchestrate the target encapsulated functions and the connections between the target encapsulated functions to obtain application service data from the multiple application service interfaces. This achieves the purpose of using GraphQL as an intermediate layer, performing interface orchestration in a visual orchestration method, and accessing the server interface through a function method to obtain the application service data corresponding to the interface call request. This ensures data security while preventing R&D costs from increasing due to the introduction of new technologies, thereby reducing R&D costs and operation and maintenance costs. This solves the technical problem in related technologies of using a serverless cloud framework as an intermediate layer, which leads to difficult operation and maintenance and high R&D and operation and maintenance costs. It should be noted that the aforementioned sending module 2201 and receiving module 2202 correspond to steps S1001 to S1002 in Example 2. The examples and application scenarios implemented by these two modules and the corresponding steps are the same, but are not limited to the content disclosed in Example 1. It should be noted that the aforementioned modules or units may be hardware components or software components stored in a memory (e.g., memory 104) and processed by one or more processors (e.g., processors 102a, 102b, ..., 102n). The aforementioned modules may also be part of an apparatus and run in the computer terminal 10 provided in Example 1. It should be noted that the preferred implementation schemes involved in the aforementioned embodiments of the present disclosure are the same as the schemes, application scenarios, and implementation processes provided in Example 1, but are not limited to the schemes provided in Example 1.Embodiment 5 The present disclosure may provide a computer terminal, which may be any computer terminal device in a computer terminal group. Optionally, in this embodiment, the computer terminal may be replaced by a terminal device such as a mobile terminal. Optionally, in this embodiment, the computer terminal may be located in at least one of multiple network devices in a computer network. In this embodiment, the computer terminal can execute program code for the following steps in the method for processing an interface call request: receiving an interface call request from a client, wherein the interface call request is used to request to call multiple application service interfaces on a server to obtain application service data corresponding to the application service requirements; graphically orchestrating the target encapsulated functions corresponding to the interface call request according to a preset interface orchestration method to obtain an orchestration result, wherein the preset interface orchestration method is used to graphically orchestrate the target encapsulated functions and the connection relationships between the target encapsulated functions to obtain application service data from the multiple application service interfaces, wherein the target encapsulated functions are used to define interface information of the multiple application service interfaces; and the orchestration result is used to describe the process of obtaining application service data by graphically orchestrating the target encapsulated functions and the connection relationships between the target encapsulated functions; obtaining application service data from the multiple application service interfaces based on the orchestration result; and feeding the application service data back to the client. Optionally, FIG23 is a block diagram of a computer terminal according to an embodiment of the present disclosure. As shown in Figure 23 , the computer terminal A may include one or more processors 2302 (only one is shown), a memory 2304, a storage controller, and a peripheral interface. The peripheral interface is connected to a radio frequency module, an audio module, and a display. The memory may be used to store software programs and modules, such as the program instructions / modules corresponding to the method and apparatus for processing interface call requests in the embodiments of the present disclosure. The processor executes the stored software programs and modules to execute various functional applications and data processing, thereby implementing the aforementioned method for processing interface call requests. The memory may include high-speed random access memory (RAM) and non-volatile memory, such as one or more magnetic storage devices, flash memory, or other non-volatile solid-state memory. In some instances, the memory may further include memory located remotely from the processor, which may be connected to the computer terminal A via a network. Examples of such networks include, but are not limited to, the Internet, an intranet, a local area network, a mobile communication network, and combinations thereof.The processor can access information and applications stored in the memory through a transmission device to perform the following steps: receiving an interface call request from a client, wherein the interface call request is used to request calling multiple application service interfaces on a server to obtain application service data corresponding to the application service requirements; graphically orchestrating the interface call request according to a preset interface orchestration method to obtain an orchestration result, wherein the preset interface orchestration method is used to obtain application service data from the multiple application service interfaces by calling a target encapsulation function corresponding to the interface call request, wherein the target encapsulation function is used to define interface information of the multiple application service interfaces; obtaining application service data from the multiple application service interfaces based on the orchestration result; and feeding the application service data back to the client. Optionally, the processor can also execute program code of the following steps: creating an initial program code block for the multiple application service interfaces; configuring function information for the initial program code block to obtain a target program code block, wherein the function information is used to define at least some or all of the following information: function name, calling method, server access points corresponding to the multiple application service interfaces, function description, and parameter configuration; and encapsulating the target program code block to obtain a target encapsulation function. Optionally, the processor may further execute program code for the following steps: selecting a target encapsulated function corresponding to the interface call request from candidate encapsulated functions according to a preset interface arrangement method, and determining a connection relationship between the target encapsulated functions based on the interface relationships of multiple application service interfaces; and graphically arranging the target encapsulated functions and the connection relationships to obtain an arrangement result. Optionally, the processor may further execute program code for the following steps: in response to the interface relationship indicating that a dependency relationship exists between the multiple application service interfaces, determining the connection relationship to be a serial connection relationship between the target encapsulated functions; and in response to the interface relationship indicating that no dependency relationship exists between the multiple application service interfaces, determining the connection relationship to be a parallel connection relationship between the target encapsulated functions. Optionally, the processor may further execute program code for the following steps: in response to obtaining application service data from multiple data sources on the server side via multiple application service interfaces, aggregating input parameters and output parameters of the target encapsulated function based on the connection relationship to obtain a first orchestration result; and in response to current data content obtained from the server side via the multiple application service interfaces being greater than data content of the application service data, trimming input parameters and output parameters of the target encapsulated function based on the connection relationship to obtain a second orchestration result.Optionally, the processor may further execute program code for the following steps: performing access control on the interface call request using a preset access control method, wherein the preset access control method includes at least one of the following: performing access authentication on the interface call request; performing flow control on the interface call request; and pre-allocating access quota corresponding to the application service data. Optionally, the processor may further execute program code for the following steps: in response to failures in calling multiple application service interfaces, obtaining a preset error code corresponding to the call failure event; searching for pre-recorded error information based on the preset error code; and feeding the preset error code and error information back to the client. Optionally, a graphical user interface is provided through the cloud device, and content displayed by the graphical user interface at least partially includes an application service data query scenario. The above-mentioned processor may further execute program code of the following steps: in response to a first control operation performed on the graphical user interface, select a target encapsulated function corresponding to the interface call request from candidate encapsulated functions, where function elements of the target encapsulated function include: function application name, function name, function input parameters, and function output parameters; in response to a second control operation performed on the graphical user interface, determine a connection relationship between the target encapsulated functions through interface relationships of multiple application service interfaces; in response to a third control operation performed on the graphical user interface, aggregate and / or trim the input parameters and output parameters of the target encapsulated function based on the connection relationship to obtain an orchestration result; and display the orchestration result in the graphical user interface. According to an embodiment of the present disclosure, an interface call request from a client is received, and then graphically orchestrates the target encapsulated function corresponding to the interface call request according to a preset interface orchestration method to obtain an orchestration result. Based on the obtained orchestration result, namely, graphically orchestrates the target encapsulated function and the connection relationship between the target encapsulated functions, an orchestration result describing the process of obtaining application service data through the graphical orchestration of the target encapsulated function and the connection relationship between the target encapsulated functions is obtained. By calling the target encapsulated function corresponding to the interface call request, application service data corresponding to the application service demand is obtained from multiple application service interfaces on the server side. Finally, the obtained application service data is fed back to the client. This achieves the purpose of using GraphQL as an intermediary layer, performing interface orchestration in a visual orchestration method, and accessing the server-side interface through a function method. This ensures data security while preventing R&D costs from increasing due to the introduction of new technologies, thereby reducing R&D costs and operation and maintenance costs. This further solves the technical problem in related technologies of using a serverless cloud framework as an intermediary layer, which leads to operational difficulties and high R&D and operation and maintenance costs.Those skilled in the art will appreciate that the structure shown in FIG23 is merely illustrative, and computer terminal A may also be a smartphone (such as an Android phone, an iOS phone, etc.), a tablet computer, a PDA, a mobile internet device (MID), a PAD, or other terminal device. FIG23 does not limit the structure of the aforementioned electronic devices. For example, computer terminal A may include more or fewer components (such as a network interface, a display device, etc.) than those shown in FIG23 , or may have a configuration different from that shown in FIG23 . Those skilled in the art will appreciate that all or part of the steps in the various methods of the above embodiments can be completed by a program instructing the hardware associated with the terminal device. The program may be stored in a computer-readable storage medium, which may include a flash drive, a read-only memory (ROM), a random access memory (RAM), a magnetic disk, or an optical disk. Example 6 The present disclosure also provides a computer-readable storage medium. Optionally, in this embodiment, the computer-readable storage medium may be used to store the program code executed by the method for processing an interface call request provided in Example 1 above. Optionally, in this embodiment, the computer-readable storage medium may be located in any computer terminal in a computer terminal group in a computer network, or in any mobile terminal in a mobile terminal group. Optionally, in this embodiment, the computer-readable storage medium is configured to store program code for executing the following steps: receiving an interface call request from a client, wherein the interface call request is used to request to call multiple application service interfaces of a server to obtain application service data corresponding to an application service requirement; graphically orchestrating the target encapsulated function corresponding to the interface call request according to a preset interface orchestration method to obtain an orchestration result, wherein the preset interface orchestration method is used to graphically orchestrate the target encapsulated function and the connection relationships between the target encapsulated functions to obtain application service data from the multiple application service interfaces, wherein the target encapsulated function is used to define interface information of the multiple application service interfaces, and the orchestration result is used to describe the process of obtaining application service data by graphically orchestrating the target encapsulated function and the connection relationships between the target encapsulated functions; obtaining application service data from the multiple application service interfaces based on the orchestration result; and feeding the application service data back to the client.Optionally, in this embodiment, the computer-readable storage medium is configured to store program code for performing the following steps: creating an initial program code block for multiple application service interfaces; configuring function information for the initial program code block to obtain a target program code block, wherein the function information defines at least some or all of the following information: function name, calling method, server access points corresponding to the multiple application service interfaces, function description, and parameter configuration; and encapsulating the target program code block to obtain a target encapsulated function. Optionally, in this embodiment, the computer-readable storage medium is configured to store program code for performing the following steps: selecting a target encapsulated function corresponding to an interface call request from candidate encapsulated functions according to a preset interface arrangement method, and determining connection relationships between the target encapsulated functions based on interface relationships between the multiple application service interfaces; and graphically arranging the target encapsulated functions and the connection relationships to obtain an arrangement result. Optionally, in this embodiment, the computer-readable storage medium is configured to store program code for performing the following steps: in response to a dependency relationship between the multiple application service interfaces, determining that the connection relationship is a serial connection relationship between the target encapsulated functions; in response to a dependency relationship between the multiple application service interfaces, determining that the connection relationship is a parallel connection relationship between the target encapsulated functions. Optionally, in this embodiment, the computer-readable storage medium is configured to store program code for performing the following steps: in response to obtaining application service data from multiple data sources on a server side via multiple application service interfaces, aggregating input parameters and output parameters of the target encapsulated functions based on the connection relationship to obtain a first orchestration result; in response to the current data content obtained from the server side via the multiple application service interfaces being greater than the data content of the application service data, trimming the input parameters and output parameters of the target encapsulated functions based on the connection relationship to obtain a second orchestration result. Optionally, in this embodiment, the computer-readable storage medium is configured to store program code for executing the following steps: performing access control on interface call requests using a preset access control method, where the preset access control method includes at least one of the following: performing access authentication on the interface call request; performing flow control on the interface call request; and pre-allocating access quota corresponding to application service data. Optionally, in this embodiment, the computer-readable storage medium is configured to store program code for executing the following steps: in response to failures in calling multiple application service interfaces, obtaining preset error codes corresponding to the call failure events; searching for pre-recorded error information based on the preset error codes; and feeding the preset error codes and error information back to the client.Optionally, a graphical user interface is provided via a cloud device, and the content displayed by the graphical user interface at least partially includes an application service data query scenario. In this embodiment, a computer-readable storage medium is configured to store program code for performing the following steps: in response to a first control operation performed on the graphical user interface, selecting a target encapsulated function corresponding to the interface call request from candidate encapsulated functions, where the function elements of the target encapsulated function include: a function application name, a function name, function input parameters, and function output parameters; in response to a second control operation performed on the graphical user interface, determining a connection relationship between the target encapsulated functions based on the interface relationships of multiple application service interfaces; in response to a third control operation performed on the graphical user interface, aggregating and / or trimming the input parameters and output parameters of the target encapsulated functions based on the connection relationships to obtain an orchestration result; and displaying the orchestration result within the graphical user interface. The serial numbers of the above-mentioned embodiments of the present disclosure are for descriptive purposes only and do not represent the superiority or inferiority of an embodiment. In the above-mentioned embodiments of the present disclosure, the descriptions of each embodiment are given with emphasis. For portions not detailed in a particular embodiment, reference can be made to the relevant descriptions of other embodiments. In the several embodiments provided in this disclosure, it should be understood that the disclosed technical content can be implemented in other ways. The device embodiments described above are merely illustrative. For example, the division of units is merely a logical functional division. In actual implementation, other divisions may be employed. For example, multiple units or components may be combined or integrated into another system, or some features may be omitted or not implemented. Furthermore, the couplings or direct couplings or communication connections shown or discussed may be through interfaces, or indirect couplings or communication connections between units or modules, and may be electrical or other forms. The units described as separate components may or may not be physically separate, and the components shown as units may or may not be physical units, i.e., they may be located in one location or distributed across multiple network units. Some or all of these units may be selected to achieve the objectives of the present embodiments based on actual needs. Furthermore, the functional units in the various embodiments of this disclosure may be integrated into a single processing unit, each unit may exist physically separately, or two or more units may be integrated into a single unit. The above-mentioned integrated unit can be implemented in the form of hardware or software functional units. If the integrated unit is implemented in the form of a software functional unit and sold or used as an independent product, it can be stored in a computer-readable storage medium.Based on this understanding, the technical solution of this disclosure, or the portion that contributes to the prior art, or all or part of this technical solution, can be embodied in the form of a software product. This computer software product, stored in a storage medium, includes instructions for causing a computer device (such as a personal computer, server, or network device) to execute all or part of the steps of the methods described in various embodiments of this disclosure. The aforementioned storage medium includes various media capable of storing program code, such as USB flash drives, read-only memories (ROMs), random access memories (RAMs), removable hard drives, magnetic disks, or optical disks. The above description is merely a preferred embodiment of this disclosure. It should be noted that those skilled in the art can make various improvements and modifications without departing from the principles of this disclosure, and such improvements and modifications should also be considered within the scope of protection of this disclosure.

Claims

Claims 1. A method for processing an interface call request, comprising: Receive an interface call request from a client, where the interface call request is used to request to call multiple application service interfaces of a server to obtain application service data corresponding to an application service requirement; graphically orchestrate a target encapsulation function corresponding to the interface call request according to a preset interface orchestration method to obtain an orchestration result, where the preset interface orchestration method is used to graphically orchestrate the target encapsulation function and the connection relationship between the target encapsulation functions to obtain the application service data from the multiple application service interfaces, the target encapsulation function is used to define the interface information of the multiple application service interfaces, and the orchestration result is used to describe the process of obtaining the application service data by graphically orchestrating the target encapsulation function and the connection relationship between the target encapsulation functions; obtain the application service data from the multiple application service interfaces based on the orchestration result; and feedback the application service data to the client.

2. The method according to claim 1, wherein, The method further includes: creating initial program code blocks for the multiple application service interfaces; configuring function information for the initial program code blocks to obtain target program code blocks, where the function information is used to define at least some or all of the following information: function name, call method, server access points corresponding to the multiple application service interfaces, function description, parameter configuration; and encapsulating the target program code blocks to obtain the target encapsulation functions.

3. The method according to claim 1, wherein, Graphically orchestrating the target encapsulation function corresponding to the interface call request according to the preset interface orchestration method to obtain the orchestration result includes: selecting the target encapsulation function corresponding to the interface call request from candidate encapsulation functions according to the preset interface orchestration method, and determining the connection relationship between the target encapsulation functions through the interface relationship of the multiple application service interfaces; and graphically orchestrating the target encapsulation function and the connection relationship to obtain the orchestration result.

4. The method according to claim 3, wherein, Determining the connection relationship between the target encapsulation functions through the interface relationship of the multiple application service interfaces includes: in response to the interface relationship being that there is a dependency relationship between the multiple application service interfaces, determining the connection relationship as a serial connection relationship between the target encapsulation functions; 42 In response to the interface relationship being that there is no dependency relationship between the multiple application service interfaces, determining the connection relationship as a parallel connection relationship between the target encapsulation functions.

5. The method according to claim 3, wherein Graphically orchestrate the target encapsulation function and the connection relationship, and the obtained orchestration result includes: in response to obtaining the application service data from multiple data sources of the server via the multiple application service interfaces, aggregate the input parameters and output parameters of the target encapsulation function based on the connection relationship to obtain a first orchestration result; in response to the current data content obtained from the server via the multiple application service interfaces being more than the data content of the application service data, crop the input parameters and output parameters of the target encapsulation function based on the connection relationship to obtain a second orchestration result.

6. The method according to claim 1, wherein The method further includes: adopting a preset access control method to perform access control on the interface call request, where the preset access control method includes at least one of the following: performing access authentication on the interface call request; performing traffic control on the interface call request; pre-distributing the access volume corresponding to the application service data.

7. The method according to claim 1, wherein The method further includes: in response to the failure of the calls of the multiple application service interfaces, obtain a preset error code corresponding to the call failure event; based on the preset error code, search for pre-entered error information; feedback the preset error code and the error information to the client.

8. The method according to claim 1, wherein Provide a graphical user interface through a cloud device, and the content displayed by the graphical user interface at least partially includes an application service data query scenario. The method includes: in response to a first control operation performed on the graphical user interface, select the target encapsulation function corresponding to the interface call request from candidate encapsulation functions, where the function elements of the target encapsulation function include: function application name, function name, function input parameters, and function output parameters; in response to a second control operation performed on the graphical user interface, determine the connection relationship between the target encapsulation functions through the interface relationship of the multiple application service interfaces; in response to a third control operation performed on the graphical user interface, 43 aggregate and / or crop the input parameters and output parameters of the target encapsulation function based on the connection relationship to obtain the orchestration result; display the orchestration result in the graphical user interface.

9. A method for processing an interface call request, comprising: Send an interface call request to the server, where the interface call request is used to request to call multiple application service interfaces of the server to obtain application service data corresponding to application service requirements; receive the application service data fed back by the server, where the application service data is obtained by the server from the multiple application service interfaces based on an orchestration result, and the orchestration result is obtained by graphically orchestrating a target encapsulation function corresponding to the interface call request according to a preset interface orchestration method. The preset interface orchestration method is used to graphically orchestrate the target encapsulation function and the connection relationship between the target encapsulation functions to obtain the application service data from the multiple application service interfaces. The target encapsulation function is used to define the interface information of the multiple application service interfaces, and the orchestration result is used to describe the processing process of obtaining the application service data by graphically orchestrating the target encapsulation function and the connection relationship between the target encapsulation functions.

10. The method according to claim 9, wherein, Sending the interface call request to the server includes: sending the interface call request to the server using a preset access domain name, where the preset access domain name is a pre-set unified public cloud domain name.

11. The method according to claim 10, wherein The domain name resolution result of the preset access domain name is used to map the interface call request to the server closest to the geographical location of the client that sends the interface call request.

12. The method according to claim 9, wherein, The method further includes: obtaining a data packet to be synchronized from the server in a command line mode, where the data packet to be synchronized includes: a source code file to be synchronized and a code type file to be synchronized. The source code file to be synchronized is used to describe the call logic of the interface, and the code type file to be synchronized is used to describe the data type and structure of the interface; updating the local historical source code file based on the source code file to be synchronized, and updating the local historical code type file based on the code type file to be synchronized.

13. The method according to claim 9, wherein The method further includes: receiving a preset error code and error information from the server, where the preset error code is obtained by the server based on a call failure event of the multiple application service interfaces, and the error information is searched based on the preset error code; 44 Display a page indicating failure to call the data source service, where the display content in the page indicating failure to call the data source service at least includes: the preset error code and the error information.

14. The method according to claim 9, wherein The method further includes: generating a first static page by using a preset static page generation method, where the first static page includes: page initial composition information, and the page initial composition information includes a page header and a menu bar; synchronizing the first static page to the server, so that when accessing a target static page through the interface call request, the page initial composition information is first rendered; after the rendering of the page initial composition information is completed, generating a second static page, where the second static page includes the remaining composition parts of the target static page except the first static page; synchronizing the second static page to the server, so that the target static page is rendered on the first static page.

15. A system for processing interface call requests, comprising: The front-end and back-end collaborative server is used to receive an interface call request from the front-end and back-end collaborative client, graphically arrange the target encapsulation function corresponding to the interface call request according to a preset interface arrangement method to obtain an arrangement result, obtain application service data from multiple application service interfaces based on the arrangement result, and feedback the application service data to the front-end and back-end collaborative client; The front-end and back-end collaborative client is used to send an interface call request to the front-end and back-end collaborative server and receive the application service data fed back by the server; where the interface call request is used to request to call multiple application service interfaces of the server to obtain application service data corresponding to application service requirements, the preset interface arrangement method is used to graphically arrange the target encapsulation function and the connection relationship between the target encapsulation functions to obtain the application service data from the multiple application service interfaces, the target encapsulation function is used to define the interface information of the multiple application service interfaces, and the arrangement result is used to describe the processing process of obtaining the application service data by graphically arranging the target encapsulation function and the connection relationship between the target encapsulation functions.

16. An electronic device, comprising: A memory stores an executable program; A processor is used to run the program, where when the program runs, it executes the method for processing an interface call request according to any one of claims 1 to 14.

17. A computer-readable storage medium, where the computer-readable storage medium includes a stored executable program, Among them, When the executable program runs, it controls the device where the computer-readable storage medium is located to execute the method for processing an interface call request according to any one of claims 1 to 14.

Images