A cloud-native system application interface rendering method, device, medium and equipment

Abstract

The specification discloses an application interface rendering method, device, medium and equipment of a cloud native system. The application interface rendering method of the cloud native system comprises: obtaining source code of each application and framework types of each application, constructing the source code of each application to obtain construction products of the application, analyzing the construction products to extract page template data and static resource data, storing the page template data and the static resource data in the cloud native system, reading target page template data, target static resource data and a target framework type from the cloud native system after receiving an access request, filling the target page template data into a front-end template to obtain a hypertext file, and sending the hypertext file and the target static resource data to a client to render an application interface of a target application.

Description

Technical Field

[0001] This specification relates to the field of cloud-native technology, and in particular to a method, apparatus, medium and device for rendering application interfaces of cloud-native systems. Background Technology

[0002] With the development of cloud-native technology, cloud-native applications are becoming increasingly diverse. Compared with traditional software applications, cloud-native applications can run in cloud computing environments. Furthermore, cloud-native applications consist of multiple cloud services, each of which has scalability, elasticity, and composability.

[0003] However, different front-end applications rely on different front-end frameworks and builds. When deploying these front-end applications to a cloud-native system, each application needs to start a corresponding container for deployment. Different deployment scripts are used to process different applications independently to adapt front-end applications with different frameworks and builds to the cloud-native system. The application deployment is complex, which leads to a lot of manual processing in the process, resulting in low processing efficiency. Furthermore, starting more containers will consume a lot of system resources.

[0004] Therefore, how to reduce the deployment complexity of front-end applications, improve deployment efficiency, and reduce deployment costs while ensuring accurate rendering of the application interface after receiving access requests is an urgent problem to be solved. Summary of the Invention

[0005] This specification provides a method, apparatus, medium, and device for rendering application interfaces in a cloud-native system, in order to partially solve the aforementioned problems existing in the prior art.

[0006] The following technical solution is adopted in this specification:

[0007] This specification provides a method for rendering application interfaces in cloud-native systems, including:

[0008] Obtain the source code of each application, and determine and store the framework types of the front-end frameworks that each application depends on;

[0009] For each application, the application's source code is built to obtain the application's build artifact;

[0010] The constructed artifacts are parsed to extract the application's page template data and static resource data;

[0011] The page template data and static resource data are stored in a cloud-native system;

[0012] Upon receiving an access request, the system reads the target page template data, target static resource data, and target frame type that match the target application corresponding to the access request from the cloud-native system.

[0013] Select a front-end template from the preset front-end template library that matches the target frame type;

[0014] The target page template data is filled into the front-end template to obtain the hypertext file corresponding to the target application;

[0015] The hypertext file and the target static resource data are sent to the client so that the client can render the application interface of the target application based on the hypertext file and the target static resource data.

[0016] Optionally, the constructed artifacts are parsed to extract the application's page template data and static resource data, specifically including:

[0017] The constructed artifact is parsed, and the storage path corresponding to the static resource data is identified in the corresponding HTML file of the constructed artifact according to the regular expression;

[0018] The page template data and static resource data of each application are stored in the cloud-native system, specifically including:

[0019] For each application, based on the storage path corresponding to the application's static resource data, determine whether the application's static resource data is accessible. If so, store the application's static resource data in the cloud-native system.

[0020] Optionally, the storage path corresponding to the static resource data is identified in the Hypertext Markup Language (Html) file corresponding to the constructed output based on a regular expression, specifically including:

[0021] The regular expression is used to identify the storage paths corresponding to style file data and script file data in the HTML file corresponding to the constructed product;

[0022] The storage paths corresponding to the style file data and script file data are used as the storage paths corresponding to the static resource data.

[0023] Optionally, the page template data and static resource data of each application are stored in the cloud-native system, specifically including:

[0024] The static resource data is stored in the static resource database of the cloud-native system, and a global identification number ID corresponding to the static resource is generated. The global ID is used to determine the page template data.

[0025] The application name is used as a unique application identifier corresponding to the global ID, and the global ID is stored in the page template database of the cloud-native system.

[0026] Optionally, upon receiving an access request, the system reads target page template data, target static resource data, and target frame type that match the target application corresponding to the access request from the cloud-native system, specifically including:

[0027] The access request is parsed to determine the unique application identifier corresponding to the target application;

[0028] The system queries the page template database for the target global ID corresponding to the unique application identifier, obtains the target page template data corresponding to the target global ID, and reads the target static resource data from the static resource database.

[0029] Optionally, before reading the target page template data, target static resource data, and target frame type that match the target application corresponding to the access request from the cloud-native system, the method further includes:

[0030] The access request is parsed to extract the identity authentication information corresponding to the access request;

[0031] Based on the identity authentication information, obtain the user's account information;

[0032] Based on the account information, determine whether the user has permission to access the target application.

[0033] Optionally, the method further includes:

[0034] If it is determined that the user has permission to access the target application, the access request is forwarded to the page assembly engine of the cloud-native system to assemble the page of the target application; otherwise, an error code indicating that the user does not have permission to access is returned to the client.

[0035] Optionally, based on the identity authentication information, the user's account information is obtained, specifically including:

[0036] Based on the identity authentication information, determine whether the access request is valid;

[0037] If the access request is valid, the account information is written into the parameter set of the access request; otherwise, a login redirect link is sent to the client.

[0038] Optionally, determining whether the access request is valid based on the identity authentication information specifically includes:

[0039] Based on the identity authentication information, query the pre-saved login session;

[0040] If the login session is not found or the login session has exceeded the preset retention period, the access request is determined to be invalid; otherwise, the account information recorded in the login session is retrieved.

[0041] Optionally, the cloud-native system includes at least one of a front-end parsing component, a front-end storage component, and a page assembly component;

[0042] The front-end storage component includes a static resource database and a page template database.

[0043] Optionally, the constructed artifacts are parsed to extract the application's page template data and static resource data, specifically including:

[0044] The front-end parsing component is used to parse the build artifacts and extract the page template data and static resource data corresponding to the application.

[0045] The page template data and static resource data of each application are stored in the cloud-native system, specifically including:

[0046] The page template data and static resource data of each application are stored in the front-end storage component of the cloud-native system.

[0047] Optionally, upon receiving an access request, the system reads target page template data, target static resource data, and target frame type that match the target application corresponding to the access request from the cloud-native system, specifically including:

[0048] Upon receiving the access request, the access request is authenticated by the page assembly component. After successful authentication, the target page template data, target static resource data, and target frame type that match the target application corresponding to the access request are read from the cloud-native system.

[0049] Optionally, the client includes a front-end browser.

[0050] This specification provides an application interface rendering device for a cloud-native system, including:

[0051] The module retrieves the source code of each application and determines and stores the framework types of the front-end frameworks that each application depends on.

[0052] The build module, for each application, builds the application's source code to obtain the application's build artifacts;

[0053] The parsing module parses the constructed artifacts and extracts the application's page template data and static resource data.

[0054] The storage module stores the page template data and static resource data of each application in the cloud-native system;

[0055] Upon receiving an access request, the reading module reads from the cloud-native system the target page template data, target static resource data, and target frame type that match the target application corresponding to the access request.

[0056] The module determines a front-end template that matches the target frame type from a preset front-end template library.

[0057] The filling module fills the target page template data into the front-end template to obtain the hypertext file corresponding to the target application;

[0058] The rendering module sends the hypertext file and the target static resource data to the client, so that the client renders the application interface of the target application based on the hypertext file and the target static resource data.

[0059] This specification provides a computer-readable storage medium storing a computer program that, when executed by a processor, implements the application interface rendering method of the cloud-native system described above.

[0060] This specification provides an electronic device, including a memory, a processor, and a computer program stored in the memory and executable on the processor, wherein the processor executes the program to implement the application interface rendering method of the cloud-native system described above.

[0061] The above-mentioned technical solutions adopted in this specification can achieve the following beneficial effects:

[0062] In the cloud-native system application interface rendering method provided in this specification, the source code and framework type of each application are obtained. For each application, the source code of the application is built to obtain the build artifact. The build artifact is parsed to extract page template data and static resource data. The page template data and static resource data are stored in the cloud-native system. After receiving an access request, the target page template data, target static resource data and target framework type are read from the cloud-native system. The target page template data is filled into the front-end template to obtain an hypertext file. The hypertext file and target static resource data are sent to the client to render the application interface of the target application.

[0063] As can be seen from the above method, when deploying different applications, this solution only needs to store the parsed page template data and static resource data in the cloud-native system. It does not require complex processing of different applications to adapt them to the cloud-native system. Furthermore, since the page template data and static resource data of different applications are uniformly stored in the cloud-native system, only one container needs to be started to complete the deployment of all applications. When users actually access the application interface, they only need to read the target page target data and static resource data from the cloud-native system to realize the subsequent rendering of the application interface. Compared with the current method of performing independent and complex processing and deploying different applications in different containers, this solution can reduce the deployment complexity of front-end applications, improve deployment efficiency, and reduce deployment costs. Attached Figure Description

[0064] The accompanying drawings, which are included to provide a further understanding of this specification and form part of this specification, illustrate exemplary embodiments and are used to explain this specification, but do not constitute an undue limitation thereof. In the drawings:

[0065] Figure 1 This is a schematic diagram illustrating the application deployment process of a traditional cloud-native system provided in this specification;

[0066] Figure 2 This is a flowchart illustrating a cloud-native system application interface rendering method provided in this specification.

[0067] Figure 3 This is a schematic diagram of the structure of a cloud-native system provided in this specification;

[0068] Figure 4 This is a schematic diagram illustrating the application deployment process of a cloud-native system provided in this specification;

[0069] Figure 5 This is a schematic diagram of an application interface rendering device for a cloud-native system provided in this specification.

[0070] Figure 6 This specification provides a corresponding Figure 2 A schematic diagram of an electronic device. Detailed Implementation

[0071] To make the objectives, technical solutions, and advantages of this specification clearer, the technical solutions of this specification will be clearly and completely described below in conjunction with specific embodiments and corresponding drawings. Obviously, the described embodiments are only a part of the embodiments of this specification, and not all of them. Based on the embodiments in this specification, all other embodiments obtained by those skilled in the art without creative effort are within the scope of protection of this specification.

[0072] This manual provides a schematic diagram of the application deployment process of a traditional cloud-native system, such as... Figure 1 As shown.

[0073] Figure 1 This is a schematic diagram illustrating the application deployment process of a traditional cloud-native system provided in this specification.

[0074] from Figure 1 As can be seen, in the process of deploying different front-end projects (front-end applications) in the local code repository, framework 1, framework 2, and framework 3 can correspond to the jQuery framework, the React.js framework, and the Vue framework, respectively. Since different front-end applications depend on different frameworks, each front-end application needs to be compiled independently and its corresponding deployment script needs to be executed. Deployment script 1, deployment script 2, and deployment script 3 can correspond to the nginx script, the nodejs script, and the edge script, respectively. This results in different applications being deployed in different global wide area network web service containers to process each front-end application independently and make it compatible with the cloud-native operating system. This not only wastes a lot of manual labor costs, but also has low deployment efficiency. Furthermore, the more containers are opened, the more system resources are consumed.

[0075] The technical solutions provided in the various embodiments of this specification are described in detail below with reference to the accompanying drawings.

[0076] Figure 2 This document provides a flowchart illustrating a cloud-native system application interface rendering method, which includes the following steps:

[0077] S201: Obtain the source code of each application and the framework type of the front-end framework that each application depends on.

[0078] S202: For each application, build the application's source code to obtain the application's build artifact.

[0079] With the development of cloud-native applications and the increasing richness of system functions, more and more front-end applications are needed to support these functions. However, different front-end applications rely on different front-end frameworks and builds. Furthermore, because cloud-native systems have unified authentication management, there is no unified way for front-end applications to connect; each application is developed and processed independently. This makes it difficult to meet the needs of scenarios that do not require authentication. Therefore, a standardized application deployment method is needed to improve development and connection efficiency and reduce system overhead.

[0080] Based on this, this specification provides a method for rendering application interfaces in cloud-native systems, which reduces the deployment complexity of front-end applications, improves deployment efficiency, and reduces deployment costs, while ensuring accurate rendering of the application interface after receiving an access request.

[0081] In this specification, the execution subject used to implement the application interface rendering method of the cloud-native system can be a specified device such as the cloud-native system server. For ease of understanding, this specification only uses the server as the execution subject to explain the application interface rendering method of the cloud-native system provided in this specification.

[0082] Once the front-end application developers have written the application, they can upload the application's source code and store it in the server's local code repository. After the server receives the application deployment request, it can retrieve the source code of each application that needs to be deployed from the local code repository. At the same time, the server can also determine the framework type of the front-end framework that each application depends on and store it. The storage location can be local on the server, or it can be the front-end storage component of the cloud-native system. This manual does not make any specific restrictions on this.

[0083] In practical applications, the framework types mentioned above can include jQuery, ReactJS, and Vue. These framework types can be specified by the application developers when uploading the application's source code, or they can be determined by the server after identifying the application's information.

[0084] It should be noted that the cloud-native system mentioned in this specification may refer to a cloud-native operating system. For ease of understanding, this specification provides a schematic diagram of the structure of a cloud-native system, such as... Figure 3 As shown.

[0085] Figure 3 This is a schematic diagram of the structure of a cloud-native system provided in this specification.

[0086] The cloud-native system deploys page assembly components, front-end storage components, and front-end parsing components. The front-end parsing component provides a management interface and includes a front-end code parser for parsing the application's source code. The front-end storage component includes a static resource database and a page template database. The page assembly component includes a routing parsing module, an access authentication module, an assembly engine module, and a front-end template library.

[0087] For each application that needs to be deployed, the server can build the application's source code. During the build process, the server can use the front-end framework's compiler to execute shell commands to compile the source code, thereby generating build artifacts in the target directory. The build artifacts include: Hyper Text Markup Language (Html) files, Cascading Style Sheets (CCS) files, JavaScript (js) files, and image files.

[0088] Of course, developers can also compile the application's source code using a compiler deployed in the client, and then log in to the management interface provided by the front-end parsing component to upload the build artifacts and fill in the framework type.

[0089] S203: Analyze the constructed artifacts and extract the page template data and static resource data of the application.

[0090] S204: Store the page template data and static resource data of each application in a cloud-native system.

[0091] The server can use the front-end parsing component of the cloud-native system, employing dynamic template technology, to parse the build artifacts, extract the application's page template data and static resource data, and store them in the cloud-native system's front-end storage component. The aforementioned page template data is used to build the application interface template. Static resource data includes style file data (CCS file data) and script file data (JS file data), and may also include other static data such as image data, used to render other styles, scripts, and images in the application interface besides the template.

[0092] In addition, the server can parse the static resource addresses in the HTML files corresponding to the above-mentioned build artifacts, and identify the storage paths of the two types of static resources, JS and CSS, in the HTML text based on regular expressions.

[0093] The server can then perform accessibility checks on static resources, specifically checking the accessibility of the storage path for each static resource.

[0094] If the access is successful, it means that the static resource data is accessible and is stored in the static resource database in the front-end storage component. A global resource identification number (Identity Document, ID) is generated for the static resource. This global ID is used to determine the page target data corresponding to the page template to which these static resources point.

[0095] If access fails, log the process and exit, indicating a deployment failure.

[0096] The server can then use the application name as the unique application identifier of the aforementioned global ID, and store the global ID in the page template database of the cloud-native system page storage component.

[0097] It should be noted that after the server stores the aforementioned global ID in the cloud-native system, it completes the storage of page template data. During the actual rendering of the application interface, the server can directly retrieve the corresponding page template data based on the global ID.

[0098] After storing the page template data and static resource data of each application in the cloud-native system, you only need to start a service container in the cloud-native system to complete the deployment of each application in the cloud-native system.

[0099] S205: Upon receiving an access request, read from the cloud-native system the target page template data, target static resource data, and target frame type that match the target application corresponding to the access request.

[0100] S206: Determine a front-end template that matches the target frame type from the preset front-end template library.

[0101] S207: Fill the target page template data into the front-end template to obtain the hypertext file corresponding to the target application.

[0102] After receiving a user's access request, the server can use the cloud-native system's page assembly components to uniformly handle route resolution and authenticate the access request. Upon successful authentication, the application interface is dynamically generated and returned to the client for rendering. In this specification, the client can be a front-end browser.

[0103] Specifically, when a user accesses an application page using a front-end browser via a fixed Uniform Resource Locator (URL), the server can forward the access request to the page assembly component. In this specification, the access request can be a Hypertext Transfer Protocol (HTTP) request.

[0104] After receiving an HTTP request, the route parsing module in the page assembly component can determine the unique application identifier of the target application accessed by the user according to the fixed URL mapping rules, and write the unique application identifier of the target application into the parameter set of the HTTP request header.

[0105] In addition, the access authentication module can verify the validity of access requests. Specifically, it can extract parameters from the HTTP request header and query the login session pre-stored on the server. If the login session does not exist or has exceeded the preset storage period, the access request is deemed invalid, and a login redirect link is returned to the front-end browser. If a login session is found and has not exceeded the preset storage period, the access request is considered valid, and the account information recorded in the login session is retrieved. The aforementioned preset storage period can be set according to actual needs; this manual does not impose specific limitations on it.

[0106] Furthermore, the access authentication module of the page assembly component can extract the user's identity authentication information from the HTTP request header and retrieve the associated account information from the user center. This account information may include roles and permission codes. If the target application does not allow the role or permission code to access, it returns an access denied error code to the front-end browser; otherwise, it forwards the HTTP request to the page assembly engine corresponding to the assembly engine module.

[0107] Once a user's access request (HTTP request) is authenticated, the server can extract the unique application identifier of the target application from the HTTP request header through page assembly components, and use this unique application identifier as a key to read the corresponding target global ID from the front-end template database, thereby obtaining the target page template data corresponding to the target global ID.

[0108] In addition, the page assembly component can further read the target static resource data and target frame type that match the target application corresponding to the access request from the cloud-native system. Then, it reads the front-end template that matches the target frame type from the front-end template library. It should be noted that the front-end templates in the front-end template library are standard general templates corresponding to each frame type.

[0109] The server can then populate the target page data into the determined front-end template to complete the rendering of the HTML file and obtain the HTML file corresponding to the target application.

[0110] S208: Send the hypertext file and the target static resource data to the client so that the client renders the application interface of the target application based on the hypertext file and the target static resource data.

[0111] The server can send the aforementioned hypertext file and target static resource data to the user's client (browser), enabling the browser to render the application interface of the target application based on the received hypertext file and static resource data. For ease of understanding, this specification provides a schematic diagram of the application deployment process of a cloud-native system, such as... Figure 4 As shown.

[0112] Figure 4 This is a schematic diagram illustrating the application deployment process of a cloud-native system provided in this specification.

[0113] from Figure 4 As can be seen, this solution only requires parsing the application's source code in the local code repository to obtain page template data and static resource data, and storing them in the cloud-native system to complete the application deployment. In this process, only one container needs to be started.

[0114] Compared to Figure 1 Compared to traditional application deployment methods, this solution only requires storing the parsed page template data and static resource data in the cloud-native system when deploying different applications. It eliminates the need for complex processing of different applications to adapt them to the cloud-native system. Furthermore, since the page template data and static resource data of different applications are uniformly stored in the cloud-native system, only one container needs to be started to complete the deployment of all applications. When users actually access the application interface, they only need to read the target page data and static resource data from the cloud-native system to render the application interface. Compared to the current method of independently and complexly processing and deploying different applications in different containers, this solution reduces the deployment complexity of front-end applications, improves deployment efficiency, and reduces deployment costs.

[0115] The above describes one or more application interface rendering methods for implementing cloud-native systems. Based on the same approach, this specification also provides corresponding application interface rendering devices for cloud-native systems, such as... Figure 5 As shown.

[0116] Figure 5 This specification provides a schematic diagram of an application interface rendering device for a cloud-native system, including:

[0117] The acquisition module 501 is used to acquire the source code of each application, as well as to determine and store the framework types of the front-end frameworks that each application depends on.

[0118] Build module 502 is used to build the source code of each application to obtain the build artifact of the application.

[0119] The parsing module 503 is used to parse the constructed artifacts and extract the page template data and static resource data of the application.

[0120] Storage module 504 is used to store the page template data and static resource data of each application in the cloud-native system;

[0121] The reading module 505 is used to read, after receiving an access request, the target page template data, target static resource data and target frame type that match the target application corresponding to the access request from the cloud-native system;

[0122] The determining module 506 is used to determine a front-end template that matches the target frame type from a preset front-end template library;

[0123] The filling module 507 is used to fill the target page template data into the front-end template to obtain the hypertext file corresponding to the target application;

[0124] The rendering module 508 is used to send the hypertext file and the target static resource data to the client, so that the client renders the application interface of the target application based on the hypertext file and the target static resource data.

[0125] Optionally, the parsing module 503 is specifically used to parse the construction product and identify the storage path corresponding to the static resource data in the Hypertext Markup Language (Html) file corresponding to the construction product according to a regular expression;

[0126] The storage module 504 is specifically used to determine, for each application, whether the static resource data of the application is accessible based on the storage path corresponding to the static resource data of the application, and if so, to store the static resource data of the application in the cloud-native system.

[0127] Optionally, the parsing module 503 is specifically used to identify the storage paths corresponding to style file data and script file data in the hypertext markup language (Html) file corresponding to the constructed product according to regular expressions; and to use the storage paths corresponding to the style file data and script file data as the storage paths corresponding to the static resource data.

[0128] Optionally, the storage module 504 is specifically used to store the static resource data in the static resource database of the cloud-native system, and generate a global identification number ID corresponding to the static resource, wherein the global ID is used to determine the page template data; and store the global ID in the page template database of the cloud-native system, using the application name of the application as the unique application identifier corresponding to the global ID.

[0129] Optionally, the reading module 505 is specifically configured to: parse the access request to determine the unique application identifier corresponding to the target application; query the page template database for the target global ID corresponding to the unique application identifier and obtain the target page template data corresponding to the target global ID; and read the target static resource data from the static resource database.

[0130] Optionally, before reading the target page template data, target static resource data, and target framework type that match the target application corresponding to the access request from the cloud-native system, the reading module 505 is further configured to: parse the access request and extract the identity authentication information corresponding to the access request; obtain the user's account information based on the identity authentication information; and determine whether the user has permission to access the target application based on the account information.

[0131] Optionally, the reading module 505 is further configured to, if it is determined that the user has permission to access the target application, forward the access request to the page assembly engine of the cloud-native system to assemble the page of the target application; otherwise, return an error code indicating that the user does not have permission to access the application to the client.

[0132] Optionally, the reading module 505 is specifically used to determine whether the access request is valid based on the identity authentication information; if the access request is valid, the account information is written into the parameter set of the access request; otherwise, a login redirect link is sent to the client.

[0133] Optionally, the reading module 505 is specifically used to query a pre-saved login session based on the identity authentication information; if the login session is not found or the login session exceeds a preset storage period, the access request is determined to be invalid; otherwise, the account information recorded in the login session is obtained.

[0134] Optionally, the cloud-native system includes at least one of a front-end parsing component, a front-end storage component, and a page assembly component; the front-end storage component includes a static resource database and a page template database.

[0135] Optionally, the parsing module 503 is specifically used to parse the construction product through the front-end parsing component and extract the page template data and static resource data corresponding to the application;

[0136] The storage module 504 is specifically used to store the page template data and static resource data of each application in the front-end storage component of the cloud-native system.

[0137] Optionally, the reading module 505 is specifically used to, after receiving the access request, authenticate the access request through the page assembly component, and after the authentication is successful, read the target page template data, target static resource data and target frame type that match the target application corresponding to the access request from the cloud-native system.

[0138] Optionally, the client includes a front-end browser.

[0139] This specification also provides a computer-readable storage medium storing a computer program that can be used to execute the above-described... Figure 2 This provides a method for rendering application interfaces in cloud-native systems.

[0140] This instruction manual also provides Figure 6 The one shown corresponds to Figure 2 A schematic diagram of the structure of an electronic device. (e.g.) Figure 6 At the hardware level, the electronic device includes a processor, internal bus, network interface, memory, and non-volatile memory, and may also include other hardware required for the business operations. The processor reads the corresponding computer program from the non-volatile memory into memory and then runs it to achieve the above-mentioned functions. Figure 2 The cloud-native system application interface rendering method described herein. Of course, in addition to software implementation, this specification does not exclude other implementation methods, such as logic devices or a combination of hardware and software, etc. In other words, the execution subject of the following processing flow is not limited to individual logic units, but can also be hardware or logic devices.

[0141] Improvements in a technology can be clearly distinguished as either hardware improvements (e.g., improvements to the circuit structure of diodes, transistors, switches, etc.) or software improvements (improvements to the methodology). However, with technological advancements, many improvements to the methodology can now be considered direct improvements to the hardware circuit structure. Designers almost always obtain the corresponding hardware circuit structure by programming the improved methodology into the hardware circuit. Therefore, it cannot be said that an improvement in methodology cannot be implemented using hardware physical modules. For example, a Programmable Logic Device (PLD) (such as a Field Programmable Gate Array (FPGA)) is such an integrated circuit whose logic function is determined by the user programming the device. Designers can program and "integrate" a digital system onto a PLD themselves, without needing chip manufacturers to design and manufacture dedicated integrated circuit chips. Furthermore, nowadays, instead of manually manufacturing integrated circuit chips, this programming is mostly implemented using "logic compiler" software. Similar to the software compiler used in program development, the original code before compilation must be written in a specific programming language, called a Hardware Description Language (HDL). There are many HDLs, such as ABEL (Advanced Boolean Expression Language), AHDL (Altera Hardware Description Language), Confluence, CUPL (Cornell University Programming Language), HDCal, JHDL (Java Hardware Description Language), Lava, Lola, MyHDL, PALASM, and RHDL (Ruby Hardware Description Language). Currently, VHDL (Very-High-Speed ​​Integrated Circuit Hardware Description Language) and Verilog are the most commonly used. Those skilled in the art should understand that by simply performing some logic programming on the method flow using one of these hardware description languages ​​and programming it into an integrated circuit, the hardware circuit implementing the logical method flow can be easily obtained.

[0142] The controller can be implemented in any suitable manner. For example, it can take the form of a microprocessor or processor and a computer-readable medium storing computer-readable program code (e.g., software or firmware) executable by the (micro)processor, logic gates, switches, application-specific integrated circuits (ASICs), programmable logic controllers, and embedded microcontrollers. Examples of controllers include, but are not limited to, the following microcontrollers: ARC 625D, Atmel AT91SAM, Microchip PIC18F26K20, and Silicon Labs C8051F320. A memory controller can also be implemented as part of the control logic of the memory. Those skilled in the art will also recognize that, in addition to implementing the controller in purely computer-readable program code form, the same functionality can be achieved by logically programming the method steps to make the controller take the form of logic gates, switches, application-specific integrated circuits, programmable logic controllers, and embedded microcontrollers. Therefore, such a controller can be considered a hardware component, and the means included therein for implementing various functions can also be considered as structures within the hardware component. Alternatively, the means for implementing various functions can be considered as both software modules implementing the method and structures within the hardware component.

[0143] The systems, devices, modules, or units described in the above embodiments can be implemented by computer chips or entities, or by products with certain functions. A typical implementation device is a computer. Specifically, a computer can be, for example, a personal computer, laptop computer, cellular phone, camera phone, smartphone, personal digital assistant, media player, navigation device, email device, game console, tablet computer, wearable device, or any combination of these devices.

[0144] For ease of description, the above devices are described in terms of function, divided into various units. Of course, in implementing this specification, the functions of each unit can be implemented in one or more software and / or hardware components.

[0145] Those skilled in the art will understand that embodiments of this specification can be provided as methods, systems, or computer program products. Therefore, this specification may take the form of a completely hardware embodiment, a completely software embodiment, or an embodiment combining software and hardware aspects. Furthermore, this specification may take the form of a computer program product embodied on one or more computer-usable storage media (including, but not limited to, disk storage, CD-ROM, optical storage, etc.) containing computer-usable program code.

[0146] This specification is described with reference to flowchart illustrations and / or block diagrams of methods, apparatus (systems), and computer program products according to embodiments of this specification. It will be understood that each block of the flowchart illustrations and / or block diagrams, and combinations of blocks in the flowchart illustrations and / or block diagrams, can be implemented by computer program instructions. These computer program instructions can be provided to a processor of a general-purpose computer, special-purpose computer, embedded processor, or other programmable data processing apparatus to produce a machine, such that the instructions, which execute via the processor of the computer or other programmable data processing apparatus, create a machine for implementing the flowchart illustrations and / or block diagrams. Figure 1 One or more processes and / or boxes Figure 1 A device that provides the functions specified in one or more boxes.

[0147] These computer program instructions may also be stored in a computer-readable storage medium that can direct a computer or other programmable data processing device to function in a particular manner, such that the instructions stored in the computer-readable storage medium produce an article of manufacture including instruction means, which are implemented in a process Figure 1 One or more processes and / or boxes Figure 1 The function specified in one or more boxes.

[0148] These computer program instructions may also be loaded onto a computer or other programmable data processing equipment to cause a series of operational steps to be performed on the computer or other programmable equipment to produce a computer-implemented process, thereby providing instructions that execute on the computer or other programmable equipment for implementing the process. Figure 1 One or more processes and / or boxes Figure 1 The steps of the function specified in one or more boxes.

[0149] In a typical configuration, a computing device includes one or more processors (CPU), input / output interfaces, network interfaces, and memory.

[0150] Memory may include non-persistent storage in computer-readable media, such as random access memory (RAM) and / or non-volatile memory, such as read-only memory (ROM) or flash RAM. Memory is an example of computer-readable media.

[0151] Computer-readable media includes both permanent and non-permanent, removable and non-removable media that can store information using any method or technology. Information can be computer-readable instructions, data structures, modules of programs, or other data. Examples of computer storage media include, but are not limited to, phase-change memory (PRAM), static random access memory (SRAM), dynamic random access memory (DRAM), other types of random access memory (RAM), read-only memory (ROM), electrically erasable programmable read-only memory (EEPROM), flash memory or other memory technologies, CD-ROM, digital versatile optical disc (DVD) or other optical storage, magnetic tape, magnetic magnetic disk storage or other magnetic storage devices, or any other non-transferable medium that can be used to store information accessible by a computing device. As defined herein, computer-readable media does not include transient computer-readable media, such as modulated data signals and carrier waves.

[0152] It should also be noted that the terms "comprising," "including," or any other variations thereof are intended to cover non-exclusive inclusion, such that a process, method, article, or apparatus that comprises a list of elements includes not only those elements but also other elements not expressly listed, or elements inherent to such a process, method, article, or apparatus. Without further limitation, an element defined by the phrase "comprising one..." does not exclude the presence of other identical elements in the process, method, article, or apparatus that includes said element.

[0153] Those skilled in the art will understand that the embodiments of this specification can be provided as methods, systems, or computer program products. Therefore, this specification may take the form of a completely hardware embodiment, a completely software embodiment, or an embodiment combining software and hardware aspects. Furthermore, this specification may take the form of a computer program product embodied on one or more computer-usable storage media (including, but not limited to, disk storage, CD-ROM, optical storage, etc.) containing computer-usable program code.

[0154] This specification can be described in the general context of computer-executable instructions that are executed by a computer, such as program modules. Generally, program modules include routines, programs, objects, components, data structures, etc., that perform a specific task or implement a specific abstract data type. This specification can also be practiced in distributed computing environments, where tasks are performed by remote processing devices connected via a communication network. In distributed computing environments, program modules can reside in local and remote computer storage media, including storage devices.

[0155] The various embodiments in this specification are described in a progressive manner. Similar or identical parts between embodiments can be referred to interchangeably. Each embodiment focuses on describing the differences from other embodiments. In particular, the system embodiments are basically similar to the method embodiments, so the description is relatively simple; relevant parts can be referred to the descriptions in the method embodiments.

[0156] The above description is merely an embodiment of this specification and is not intended to limit this specification. Various modifications and variations can be made to this specification by those skilled in the art. Any modifications, equivalent substitutions, improvements, etc., made within the spirit and principles of this specification should be included within the scope of the claims of this specification.

Claims

1. A method for rendering the application interface of a cloud-native system, characterized in that, include: Obtain the source code of each application, and determine and store the framework types of the front-end frameworks that each application depends on; For each application, the application's source code is built to obtain the application's build artifact; The constructed artifacts are parsed to extract the application's page template data and static resource data; The page template data and static resource data are stored in a cloud-native system. The cloud-native system includes at least one of a front-end parsing component, a front-end storage component, and a page assembly component. The front-end storage component includes a static resource database and a page template database. The static resource data is stored in the static resource database, and a global identification number (ID) corresponding to the static resource is generated. This global ID is used to identify the page template data. The application name is used as a unique application identifier corresponding to the global ID, and the global ID is stored in the page template database. The method further includes: parsing the construction artifacts using the front-end parsing component to extract the page template data and static resource data corresponding to the application; and storing the page template data and static resource data of each application in the front-end storage component of the cloud-native system. Upon receiving an access request, the system reads the target page template data, target static resource data, and target frame type that match the target application corresponding to the access request from the cloud-native system. Select a front-end template from the preset front-end template library that matches the target frame type; The target page template data is filled into the front-end template to obtain the hypertext file corresponding to the target application; The hypertext file and the target static resource data are sent to the client so that the client can render the application interface of the target application based on the hypertext file and the target static resource data.

2. The method as described in claim 1, characterized in that, The constructed artifacts are parsed to extract the application's page template data and static resource data, specifically including: The constructed artifact is parsed, and the storage path corresponding to the static resource data is identified in the corresponding HTML file of the constructed artifact according to the regular expression; The page template data and static resource data of each application are stored in the cloud-native system, specifically including: For each application, based on the storage path corresponding to the application's static resource data, determine whether the application's static resource data is accessible. If so, store the application's static resource data in the cloud-native system.

3. The method as described in claim 2, characterized in that, Identify the storage path corresponding to the static resource data in the HTML file corresponding to the constructed output based on regular expressions, specifically including: The regular expression is used to identify the storage paths corresponding to style file data and script file data in the HTML file corresponding to the constructed product; The storage paths corresponding to the style file data and script file data are used as the storage paths corresponding to the static resource data.

4. The method as described in claim 3, characterized in that, Upon receiving an access request, the system reads target page template data, target static resource data, and target frame type that match the target application corresponding to the access request from the cloud-native system. Specifically, this includes: The access request is parsed to determine the unique application identifier corresponding to the target application; The system queries the page template database for the target global ID corresponding to the unique application identifier, obtains the target page template data corresponding to the target global ID, and reads the target static resource data from the static resource database.

5. The method as described in claim 1, characterized in that, Before reading the target page template data, target static resource data, and target frame type that match the target application corresponding to the access request from the cloud-native system, the method further includes: The access request is parsed to extract the identity authentication information corresponding to the access request; Based on the identity authentication information, obtain the user's account information; Based on the account information, determine whether the user has permission to access the target application.

6. The method as described in claim 5, characterized in that, The method further includes: If it is determined that the user has permission to access the target application, the access request is forwarded to the page assembly engine of the cloud-native system to assemble the page of the target application; otherwise, an error code indicating that the user does not have permission to access is returned to the client.

7. The method as described in claim 5, characterized in that, Based on the identity authentication information, the user's account information is obtained, specifically including: Based on the identity authentication information, determine whether the access request is valid; If the access request is valid, the account information is written into the parameter set of the access request; otherwise, a login redirect link is sent to the client.

8. The method as described in claim 7, characterized in that, Based on the identity authentication information, it is determined whether the access request is valid, specifically including: Based on the identity authentication information, query the pre-saved login session; If the login session is not found or the login session has exceeded the preset retention period, the access request is determined to be invalid; otherwise, the account information recorded in the login session is retrieved.

9. The method as described in claim 1, characterized in that, Upon receiving an access request, the system reads target page template data, target static resource data, and target frame type that match the target application corresponding to the access request from the cloud-native system. Specifically, this includes: Upon receiving the access request, the access request is authenticated by the page assembly component. After successful authentication, the target page template data, target static resource data, and target frame type that match the target application corresponding to the access request are read from the cloud-native system.

10. The method as described in claim 1, characterized in that, The client includes: a front-end browser.

11. A cloud-native system application interface rendering device, characterized in that, include: The module retrieves the source code of each application and determines and stores the framework types of the front-end frameworks that each application depends on. The build module, for each application, builds the application's source code to obtain the application's build artifacts; The parsing module parses the constructed artifacts and extracts the application's page template data and static resource data. The storage module stores the page template data and static resource data of each application in the cloud-native system. The cloud-native system includes at least one of a front-end parsing component, a front-end storage component, and a page assembly component. The front-end storage component includes a static resource database and a page template database. The static resource data is stored in the static resource database, and a global identification number (ID) corresponding to the static resource is generated. This global ID is used to identify the page template data. The module further includes storing the global ID in the page template database using the application name as the unique application identifier corresponding to the global ID. The module also includes parsing the build artifacts through the front-end parsing component to extract the page template data and static resource data corresponding to the application. Finally, the page template data and static resource data of each application are stored in the front-end storage component of the cloud-native system. Upon receiving an access request, the reading module reads from the cloud-native system the target page template data, target static resource data, and target frame type that match the target application corresponding to the access request. The module determines a front-end template that matches the target frame type from a preset front-end template library. The filling module fills the target page template data into the front-end template to obtain the hypertext file corresponding to the target application; The rendering module sends the hypertext file and the target static resource data to the client, so that the client renders the application interface of the target application based on the hypertext file and the target static resource data.

12. A computer-readable storage medium, characterized in that, The storage medium stores a computer program, which, when executed by a processor, implements the method described in any one of claims 1 to 10.

13. An electronic device comprising a memory, a processor, and a computer program stored in the memory and executable on the processor, characterized in that, When the processor executes the program, it implements the method described in any one of claims 1 to 10.

Images