Front-end page preview method, electronic device, and storage medium

Abstract

The present disclosure provides a front-end page preview method, an electronic device and a storage medium. The method of the present disclosure comprises: receiving a page access request sent by a client; if a preview identifier is parsed from the page access request, intercepting the page access request; querying historical log data matching a request URL contained in the page access request from a historical log system; returning target response data extracted from the historical log data to the client, so that the client displays a preview front-end page based on the target response data.

Description

Technical Field

[0001] This disclosure relates to the field of computer technology, and more particularly to front-end page preview methods, electronic devices, and storage media. Background Technology

[0002] In digital construction scenarios based on internet platforms, there are a large number of Hyper Text Markup Language 5 (H5) business pages that rely on complex backend interfaces. When troubleshooting problems or viewing page styles, it is necessary to use a Uniform Resource Locator (URL) for quick previewing.

[0003] Traditional preview solutions often involve setting up a complete local runtime environment or accessing a separate test environment. Staff need to start the React project and Node service locally and manually configure mock data as needed. When the business system is complex, the local environment may struggle to fully simulate real-world scenarios, resulting in long setup times. Furthermore, accessing the test environment may require resolving strong dependencies such as login authentication and API parameter matching, causing instability in the online preview. Therefore, a page preview solution that is fast, realistic, and requires zero configuration is needed. Summary of the Invention

[0004] This disclosure provides a method for previewing front-end pages, electronic devices, and storage media.

[0005] According to a first aspect of this disclosure, a method for previewing a front-end page is provided. The method specifically includes: receiving a page access request sent by a client; intercepting the page access request if a preview identifier is parsed from it; retrieving historical log data matching the Request Uniform Resource Locator (URL) from a historical log system based on the URL contained in the page access request; and returning target response data extracted from the historical log data to the client, so that the client can display a preview front-end page based on the target response data.

[0006] According to at least one embodiment of this disclosure, if a preview identifier is parsed from a page access request, the page access request is intercepted, including: parsing the page access request; determining whether the page access request contains a preview identifier based on the parsing result; wherein the preview identifier is used to instruct the server to process the current request as a preview request; if the preview identifier is contained, the page access request is intercepted; if the preview identifier is not contained, the request is sent to the backend server to obtain page information.

[0007] According to at least one embodiment of this disclosure, querying historical log data matching the Request Uniform Resource Locator (URL) from a historical log system based on the URL contained in the page access request includes: parsing the URL from the page access request to obtain the URL; wherein the URL contains path information and query parameters; and querying historical log data matching the path information from the historical log system.

[0008] According to at least one embodiment of this disclosure, returning target response data extracted from historical log data to a client includes: performing adaptation processing on the historical log data to generate target response data; and returning the adapted target response data to the client.

[0009] After retrieving historical log data matching the requested Uniform Resource Locator from the historical log system according to at least one embodiment of this disclosure, the method further includes: obtaining multiple candidate log data matched from the historical log system; filtering out successfully executed candidate log data based on the status codes contained in the candidate log data; sorting the successfully executed candidate log data according to the generation timestamp order of the candidate log data; and determining the candidate log data that is ranked first as historical log data.

[0010] According to at least one embodiment of this disclosure, historical log data is adapted by: obtaining a standard response structure template for building a preview front-end page; mapping historical log data to a target data field in the standard response structure template; injecting a preview mode identifier field into the standard response structure template to generate target response data; wherein the preview mode identifier field is used for the client to identify that the target response data originates from the page preview mode.

[0011] Before mapping historical log data to target data fields in a standard response structure template according to at least one embodiment of this disclosure, the method further includes: performing data cleaning processing on the historical log data, wherein the data cleaning processing includes: replacing sensitive field data with preset desensitized characters; and / or, correcting the generated timestamp field to the current system time.

[0012] According to at least one embodiment of this disclosure, historical log data includes a business data body, status code, pagination information, and generation timestamp; mapping historical log data to target data fields in a standard response structure template includes: mapping status codes to status code fields in the standard response structure template; mapping business data bodies to data content fields in the standard response structure template; mapping pagination information to pagination information fields in the standard response structure template; and mapping generation timestamps to response time fields in the standard response structure template.

[0013] According to a second aspect of this disclosure, an electronic device is provided, comprising: a memory storing execution instructions; and a processor executing the execution instructions stored in the memory, such that the processor performs a first aspect of any embodiment of this disclosure.

[0014] According to a third aspect of this disclosure, a readable storage medium is provided, wherein executable instructions are stored therein, which, when executed by a processor, are used to implement a first aspect of any embodiment of this disclosure.

[0015] According to a fourth aspect of this disclosure, a computer program product is provided, including a computer program that, when executed by a processor, implements a first aspect of any embodiment of this disclosure. Attached Figure Description

[0016] The accompanying drawings illustrate exemplary embodiments of the present disclosure and, together with the description thereof, serve to explain the principles of the present disclosure. These drawings are included to provide a further understanding of the present disclosure and are incorporated in and constitute a part of this specification.

[0017] Figure 1 This is a flowchart illustrating the front-end page preview method provided in an embodiment of this disclosure.

[0018] Figure 2 This is a flowchart illustrating a method for intercepting page access requests provided in an embodiment of this disclosure.

[0019] Figure 3 This is a flowchart illustrating the historical log data query method provided in this embodiment of the disclosure.

[0020] Figure 4 This is a flowchart illustrating the target response data generation method provided in an embodiment of the present disclosure.

[0021] Figure 5 A flowchart illustrating the method for determining historical log data provided in this embodiment of the disclosure.

[0022] Figure 6 This is a flowchart illustrating the target data field generation method provided in this embodiment of the disclosure.

[0023] Figure 7 This is a flowchart illustrating the historical log data preprocessing method provided in an embodiment of this disclosure.

[0024] Figure 8 This is a schematic diagram of the data mapping process provided in an embodiment of the present disclosure.

[0025] Figure 9 This is a schematic diagram of system interaction provided for an embodiment of this disclosure.

[0026] Figure 10 This is a schematic block diagram of a front-end page preview device according to one embodiment of the present disclosure.

[0027] Figure 11 This is a schematic block diagram of an electronic device according to one embodiment of the present disclosure. Detailed Implementation

[0028] The present disclosure will now be described in further detail with reference to the accompanying drawings and examples. It should be understood that the specific examples described herein are for illustrative purposes only and are not intended to limit the scope of the disclosure. Furthermore, it should be noted that, for ease of description, only the parts relevant to the present disclosure are shown in the accompanying drawings.

[0029] It should be noted that, where there is no conflict, the embodiments and features described in this disclosure can be combined with each other. The technical solutions of this disclosure will now be described in detail with reference to the accompanying drawings and embodiments.

[0030] Figure 1 This is a flowchart illustrating the front-end page preview method provided in an embodiment of this disclosure. Figure 1 The method shown includes steps S101 to S104. This method can be applied to a server, which may include a node middleware layer, a mock engine, and a historical log system, etc.

[0031] Specifically, Figure 1 The method shown includes step S101: receiving a page access request sent by the client.

[0032] The client referred to here is the terminal device (such as a mobile phone, computer, etc.) that initiates the page access request. This refers to a user device that can run a browser or Hypertext Markup Language 5 (H5) web pages. The page access request refers to the network request initiated by the client to the server to obtain page content, typically conforming to the Hypertext Transfer Protocol (HTTP) or Hypertext Transfer Protocol Secure (HTTPS) specifications.

[0033] In normal applications, clients can send page access requests to servers (such as servers used to meet preview requirements, or backend servers that execute actual business requirements).

[0034] Step S102: If the preview identifier is obtained from the page access request, then the page access request is intercepted.

[0035] The preview identifier mentioned here is a specific tag carried in the page access request to indicate that the current request on the server is in preview mode rather than normal business mode. For example, it can be a judgment identifier inserted into the normal URL to distinguish whether the URL is in preview mode.

[0036] In conventional solutions, enabling preview mode requires modifying the local hosts file, configuring proxy tools, or starting a specific mock service, which is cumbersome and highly dependent on the environment. However, in this application, simply including a preview identifier in the request (e.g., adding a specific identifier to the URL) allows the server to recognize and intercept the request. This interception means the server stops forwarding the page access request to the real backend business server, thus severing the direct dependency between the client and the real backend. It eliminates the need to worry about the availability of the real backend service, the need for complex login authentication or permission checks, and avoids preview failures due to backend service fluctuations, effectively reducing the environmental dependency cost of preview and achieving a ready-to-use preview effect. If the preview identifier is not resolved, the server forwards the request to the backend server (i.e., the real business server) to obtain the page information according to the normal process, ensuring that normal business operations are not affected.

[0037] Step S103: Based on the Request Uniform Resource Locator (URL) contained in the page access request, retrieve historical log data that matches the Request Uniform Resource Locator from the historical log system.

[0038] The historical log system mentioned here refers to a system that stores records of past interface calls. Preferably, it is an enterprise log platform that records real user access behavior in an enterprise production environment. The data stored therein is historical log data, which includes response information for past requests, such as response information with success status codes and response information with error status codes.

[0039] Since the page access request has been intercepted, the server can construct its own response data based on this. This utilizes real historical logs generated in the production environment as a data source, overcoming the difficulties in maintaining traditional mock data and its poor timeliness. The server extracts the request URL from the page access request and sends it as a query condition to the historical log system. The historical log system stores a large amount of interface request and response data generated by real users during daily business access. The server performs a matching query in the historical log system based on the request URL to find the historical log data corresponding to that request URL. It is important to note that existing log playback technologies typically require all parameters of the request to be completely identical to the log record for a match. However, this application uses the matching logic based on the request URL, matching based on the path information in the URL, thus ignoring specific business query parameters in the URL (such as user ID, order number, etc.). This selective matching method solves the problem in traditional solutions where historical log data cannot be obtained due to the lack of specific business parameters, allowing for the acquisition of a valid data source with only the page path, achieving parameterless or low-parameter preview.

[0040] Step S104: Return the target response data extracted from the historical log data to the client so that the client can display a preview front-end page based on the target response data.

[0041] The target response data mentioned here refers to the data that the server processes based on historical log data and ultimately returns to the client for page rendering. The preview front-end page mentioned here refers to the page interface rendered by the client based on the target response data, which is displayed to the user.

[0042] The server parses the required response content from the retrieved historical log data and generates the target response data. This target response data retains the data structure characteristics of the real business logic, thus accurately reflecting the field formats required by the front-end page. The server returns the target response data to the client via an HTTP response. Upon receiving the target response data, the client performs data binding and component rendering in the same way as receiving a real backend response, ultimately displaying a preview of the front-end page. Because the target response data originates from real logs in the production environment, its data structure is consistent with the latest online business logic, avoiding the problems of outdated data structures, missing fields, or inconsistencies with the backend that can occur with traditionally manually written mock data, ensuring the authenticity and effectiveness of the preview effect.

[0043] Based on the publicly available solutions, by setting up an interception mechanism based on preview identifiers on the server side, the isolation between preview traffic and real business traffic is achieved. This eliminates the need to build a complete local development environment or rely on a testing environment, significantly reducing the cost and time of environment setup. By utilizing the historical log system to query and match historical log data, the automatic generation of Mock data is achieved, eliminating the need for manual maintenance of Mock configurations. Furthermore, the data originates from the production environment, ensuring the timeliness and authenticity of the data structure. By using matching queries based on request URLs, the dependence on business parameters is reduced, improving the success rate and convenience of previews. This effectively solves the technical problems in existing technologies, such as complex preview configurations, high data maintenance costs, and strict parameter matching leading to preview failures.

[0044] In one or more embodiments of this disclosure, such as Figure 2 This is a flowchart illustrating a method for intercepting page access requests provided in an embodiment of this disclosure. Figure 2 As shown, if a preview identifier is obtained from the page access request, the page access request is intercepted, including: Step S201: Parse the page access request. Step S202: Determine whether the page access request contains a preview identifier based on the parsing result; wherein, the preview identifier is used to instruct the server to process the current request as a preview request. Step S203: If a preview identifier is contained, the page access request is intercepted. Step S204: If a preview identifier is not contained, the request is sent to the backend server to obtain page information.

[0045] In existing technologies, switching preview modes typically requires modifying the local hosts file, configuring a separate proxy server, or switching to a different domain name. This approach isolates the preview environment from the normal business environment, resulting in high maintenance costs and the inability to dynamically switch between modes within the same service instance. This embodiment, however, achieves dynamic mode switching based on request content by parsing and judging page access requests internally on the server side, without requiring changes to the network architecture or client configuration.

[0046] Specifically, the first step is to parse the page access request. Parsing refers to the server's process of reading and analyzing the structured data of the received page access request. Page access requests typically conform to the HTTP protocol specification and include a request line, request headers, and a request body. Through parsing, the server extracts key information from the request, such as the request URL, query parameters, and headers, for subsequent feature identification. This ensures that the server can accurately obtain any identifying information carried in the request.

[0047] Furthermore, the parsing results determine whether the page access request contains a preview identifier. This preview identifier is a pre-defined, specific data feature used to distinguish request types. In this embodiment, the preview identifier instructs the server to process the current request as a preview request. This means that the preview identifier triggers the server's internal decision on how to handle the page access request. By introducing this preview identifier, the solution in this application enables the server to automatically identify user intent, achieving preview functionality without configuration.

[0048] If the judgment result contains a preview identifier, the page access request is intercepted. That is, the server stops forwarding the current request to the downstream real business node. Once the preview identifier is identified, the server confirms that the current request does not require the involvement of the real backend, thus blocking the normal forwarding link and initiating the preview processing flow based on historical log data described in this solution. This interception method ensures that preview traffic does not pollute the real backend business services, and that preview failures are not caused by backend service authentication, rate limiting, or other policies.

[0049] If the judgment result indicates that the preview identifier is not present, the request is sent to the backend server to retrieve page information. The backend server here refers to the server-side device that provides the actual business logic processing, distinct from the server executing this method (i.e., the request forwarding middleware (Node middleware)). When the preview identifier is absent from the request, the server determines it as a normal business request. In this case, the server acts as a proxy, directly forwarding the page access request to the backend server. The backend server executes the actual business logic (such as database queries, permission verification, etc.), generates the actual page information, and returns it. Even without the preview identifier, the user experience is consistent with existing technologies and is unaffected by the preview function.

[0050] Based on the publicly available solutions described above, by integrating parsing and judgment logic within the server-side, the coexistence and dynamic switching between preview mode and normal business mode are achieved. This eliminates the need to build a separate environment for preview, effectively reducing operational costs. The command-line function of the preview identifier makes the switching process controllable; users only need to add the preview identifier to the URL to trigger preview mode, and remove the identifier to restore normal mode, making the operation convenient. This approach ensures both independence in the preview scenario and stability in the normal business scenario, achieving an efficient architecture where a single service instance supports both modes simultaneously.

[0051] In one or more embodiments of this disclosure, such as Figure 3 This is a flowchart illustrating the historical log data query method provided in an embodiment of this disclosure. Figure 3As shown, based on the request URL contained in the page access request, historical log data matching the request URL is retrieved from the historical log system, including: Step S301: Parsing the request URL from the page access request; wherein, the request URL contains path information and query parameters. Step S302: Retrieving historical log data matching the path information from the historical log system.

[0052] In conventional solutions, when using log data for interface replay or simulation, a full match is typically used. This means that the URL, request parameters, and request headers of the current request must be completely identical to those recorded in the log data for a successful match. This makes it difficult to construct specific query parameters that conform to business logic (e.g., valid order numbers, user IDs) in preview mode, and may even lead to the inability to retrieve any historical log data due to parameter mismatches, resulting in preview failure. This application's embodiment refines the URL parsing and matching method to achieve fuzzy matching based on path information.

[0053] In practical applications, the request URL is parsed from the page access request. This request URL is a Uniform Resource Locator (URL) used to identify the resource location in the page access request. The server parses the page access request to extract the complete request URL string. Furthermore, the request URL contains path information and query parameters. The path information refers to the part of the URL that identifies the interface resource level, usually located after the domain name and before the question mark, such as ` / api / product / detail`. The query parameters refer to the specific business data carried in the URL, usually located after the question mark, such as `?productId=123&userId=456`. In existing technologies, path information and query parameters are often treated as a whole for matching, while this solution structurally separates them, requiring only the path information for fuzzy matching.

[0054] When constructing query conditions, the server only extracts the path information from the request URL as the key matching field, ignoring the query parameters. When the server sends a query request to the historical log system, it includes the path information, instructing the historical log system to retrieve all historical log data whose request path matches the path information, regardless of the query parameters in the original log records. For example, when the client requests the URL / api / product / detail?id=999, the server only uses / api / product / detail as the query condition, without needing the specific query parameter id=999. Even if the historical log system stores a record with / api / product / detail?id=100, it can still be successfully matched and returned because the path information is consistent.

[0055] Based on the publicly available solutions mentioned above, by structurally splitting the request URL and performing local matching, the dependency between the preview function and specific business query parameters is decoupled; the probability of successful matching of historical log data is significantly improved, and usable historical log data can be successfully obtained even in preview scenarios where valid business parameters (such as user ID and order number) cannot be provided; the cost of preview operations is reduced, and users can complete the page preview without understanding the parameter definitions of the backend interface.

[0056] In one or more embodiments of this disclosure, such as Figure 4 This is a flowchart illustrating the target response data generation method provided in an embodiment of this disclosure. Figure 4 As shown, the target response data extracted from historical log data is returned to the client, including: Step S401: Adapting the historical log data to generate the target response data. Step S402: Returning the adapted target response data to the client.

[0057] Since the proposed solution utilizes historical log data to build the preview page, and production environment historical log data often contains internal debugging fields and sensitive information, directly returning this data could lead to front-end parsing errors, page rendering failures, or data security risks. Therefore, an adaptation process is introduced to automate the conversion from raw logs to usable response data.

[0058] First, the historical log data undergoes adaptation processing to generate the target response data. This adaptation processing refers to the server-side adjustment, transformation, or cleaning of the historical log data to conform to the client's expected data format and specifications. Through this adaptation processing, the server can convert historical log data into standard, secure target response data that is compatible with the current front-end version.

[0059] Furthermore, the adapted target response data is returned to the client. The server encapsulates the generated target response data in a standard HTTP response message body and sends it back to the requesting client via the computer network. After receiving the target response data, the client can parse and render it as a normal backend interface response without needing to know whether the data source is a real backend or historical logs.

[0060] Based on the publicly available solutions mentioned above, the adaptation process eliminates the differences between the original log data and the expected data structure of the front end, ensuring the normal rendering of the preview page; it achieves secure data isolation, preventing sensitive information in production logs from being directly exposed to the client; and it improves data availability, enabling historical logs to be directly converted into high-quality mock data without manual intervention.

[0061] In one or more embodiments of this disclosure, such as Figure 5 This is a flowchart illustrating the method for determining historical log data provided in an embodiment of this disclosure. Figure 5 As shown, after retrieving historical log data matching the requested Uniform Resource Locator from the historical log system, the process further includes: Step S501: Obtaining multiple candidate log data entries matched from the historical log system. Step S502: Filtering out successfully executed candidate log data based on the status codes contained in the candidate log data. Step S503: Sort the successfully executed candidate log data according to the generation timestamp order. Step S504: Determining the candidate log data at the top of the sorted list as historical log data.

[0062] If a record is randomly selected directly from the log database as historical log data, it is highly likely that erroneous or structurally invalid data will be selected, leading to display errors or missing fields on the front-end preview page. Therefore, this application embodiment adopts the following scheme to determine historical log data: specifically, it obtains multiple candidate log data matched from the historical log system. These candidate log data refer to the collection of all historical log records in the historical log system that match the request URL. Due to the high concurrency characteristics of the production environment, the same interface path may be called tens of thousands of times a day; therefore, the query result is usually not a single record, but a list containing multiple records. The server receives this list as input for subsequent processing.

[0063] Furthermore, the system filters out successfully executed candidate log data based on the status codes contained within the candidate log data. These status codes identify the result of the interface request processing; for example, in the HTTP protocol, 200 represents a success status code, 500 represents a failure status code, and 404 represents a resource not found status code. The server iterates through multiple candidate log data entries, checking the status code in each entry. If a candidate log data entry's status code indicates a successful request (e.g., status code 200), it is retained as a successful candidate log data entry; if a candidate log data entry's status code indicates a failed request (e.g., status code 500 or timeout), it is filtered and discarded. This ensures that the historical log data used for subsequent previews is legitimate data indicating successful execution of business logic.

[0064] Furthermore, the successfully executed candidate log data is sorted according to its generation timestamp. This generation timestamp refers to the specific time when each historical log data was recorded in the log system. The server then sorts the filtered successfully executed candidate log data in reverse chronological order by generation timestamp, with more recent data appearing first. This is because the backend interface data structure may be updated with version iterations, and log data more recent than the current time reflects the latest online business logic more accurately. This time-based sorting ensures that the selected data has the highest timeliness.

[0065] The server extracts the top-ranked candidate log data from the sorted list (in practice, this can be selected as needed; generally, log data ranked higher is more up-to-date and has a higher probability of successful preview), and officially designates it as the historical log data for subsequent steps. If there is exactly one candidate log data that has successfully executed, it is directly designated as the historical log data; if there are multiple, the latest one is selected. The server thus identifies a single, both successful and up-to-date, data point from a massive amount of disorganized logs, serving as the basis for generating the target response data.

[0066] Based on the publicly available solutions, it is known that by using status codes for filtering, abnormal logs and error data in the production environment are effectively filtered out, ensuring the availability of the preview page and preventing the front end from rendering error messages. By generating timestamp sorting mechanisms, it is ensured that the selected data structure is up-to-date and can adapt to the latest front end code logic, avoiding parsing errors caused by inconsistent data structure versions. Through an automated optimization process, no manual intervention is required to select logs, greatly improving the efficiency and accuracy of preview data preparation.

[0067] In one or more embodiments of this disclosure, such as Figure 6 This is a flowchart illustrating the target data field generation method provided in this embodiment of the disclosure. Figure 6 As shown, the adaptation processing for historical log data includes: Step S601: Obtaining a standard response structure template for building the preview front-end page. Step S602: Mapping historical log data to target data fields in the standard response structure template. Step S603: Injecting a preview mode identifier field into the standard response structure template to generate target response data. The preview mode identifier field is used by the client to identify that the target response data originates from the page preview mode.

[0068] In practical applications, a standard response structure template is obtained for building the preview front-end page. This standard response structure template refers to a predefined data structure framework that conforms to the front-end page rendering requirements. This template specifies the field names, nesting levels, and data types that the response data should include. For example, it stipulates that all successful responses must include top-level fields such as code, data, and message. The server can obtain the standard response structure template from configuration files, a database, or a memory cache. This ensures that regardless of changes to the original log structure, the final output data framework always conforms to the front-end's expectations.

[0069] Furthermore, historical log data is mapped to target data fields in the standard response structure template. These target data fields refer to the fields in the standard response structure template used to carry the actual business data. The server parses the historical log data, extracts the valid business content, and populates it into the corresponding target data fields in the standard response structure template. For example, if the historical log data contains a "result" field, and the corresponding target data field in the standard response structure template is "data," the server establishes a mapping relationship and assigns the content of the "result" field to "data." This achieves the conversion from raw log data to standard format data.

[0070] Furthermore, a preview mode identifier field is injected into the standard response structure template to generate the target response data. This preview mode identifier field is a specific field added to the response data to carry pattern recognition information. After the server populates the business data, it writes the preview mode identifier field into the standard response structure template. After injection, the entire template content is generated as the target response data. When the client receives the target response data, it can parse this field to know that it is currently in preview mode, thereby triggering the corresponding preview logic.

[0071] Based on the publicly available solutions, it is known that by using a standard response structure template, the format of historical log data from different sources and versions is unified, ensuring the stability of front-end parsing; by using a mapping mechanism, the differences between log data and the front-end's expected structure are flexibly adapted, improving data compatibility; by injecting a preview mode identifier field, the client is given the ability to identify the data source, enabling the front-end to dynamically adjust the interaction logic according to the preview status (such as hiding sensitive operations and displaying debugging information), enhancing the controllability and security of the preview function.

[0072] In one or more embodiments of this disclosure, such as Figure 7 This is a flowchart illustrating the historical log data preprocessing method provided in an embodiment of this disclosure. Figure 7 As shown, before mapping historical log data to the target data field in the standard response structure template, the process further includes: Step S701: Performing data cleaning on the historical log data, which includes replacing sensitive field data with preset desensitized characters. And / or, Step S702: Correcting the generated timestamp field to the current system time.

[0073] In practical applications, historical log data undergoes data cleaning before being mapped to target data fields in the standard response structure template. This data cleaning process involves inspecting, modifying, or replacing specific fields in the historical log data to eliminate security vulnerabilities or invalid information.

[0074] The sensitive fields mentioned earlier refer to fields in historical log data that involve user privacy or system security, such as mobile phone numbers, ID card numbers, bank card numbers, or internal keys. The preset de-identification characters mentioned here refer to pre-agreed character sequences used to replace the original sensitive information, such as asterisks. If the historical log data does not contain sensitive fields, skip this step.

[0075] It should be noted that the "generated timestamp field" mentioned earlier refers to the field in the historical log data that records the time the original request occurred. The "current system time" mentioned earlier refers to the real-time time when the server executes this method. The server modifies the value of the generated timestamp field in the historical log data to the current system time. If the historical log data does not contain a generated timestamp field, this step is skipped. By correcting it to the current system time, the client's time verification logic is satisfied, allowing historical data to be rendered normally as fresh data.

[0076] It should be noted that the steps of replacing sensitive field data and correcting the generated timestamp field are related by AND / OR. The server can perform only the replacement of sensitive field data, only the correction of the generated timestamp field, or both operations simultaneously. Which operations are performed can be configured according to security policies and front-end validation rules.

[0077] Based on the publicly available solutions mentioned above, data cleaning effectively prevents the leakage of sensitive production environment information through the preview function, thus improving system security; by correcting the generated timestamp field, front-end validation failures caused by outdated log data are avoided, ensuring the usability and smoothness of the preview page; and by performing cleaning before mapping, the quality of data entering the standard response structure template is guaranteed, reducing the complexity of subsequent processing.

[0078] In one or more embodiments of this disclosure, such as Figure 8 This is a schematic diagram illustrating the data mapping process provided in an embodiment of this disclosure. Figure 8 As shown, the historical log data includes the business data body, status code, pagination information, and the generation timestamp. Mapping the historical log data to the target data field in the standard response structure template includes: Step S801: Mapping the status code to the status code field in the standard response structure template. Step S802: Mapping the business data body to the data content field in the standard response structure template. Step S803: Mapping the pagination information to the pagination information field in the standard response structure template. Step S804: Mapping the generation timestamp to the response time field in the standard response structure template.

[0079] In practical applications, historical log data includes the business data body, status codes, pagination information, and the generation timestamp. The business data body refers to the portion of the interface response that carries core business content, such as product details or user information lists. The status code is a code that identifies the result of the interface request processing, indicating whether the response was successful or failed. The pagination information refers to metadata describing the pagination status when the business data is in list format, such as the current page number, total number of pages, and number of items per page. The generation timestamp is a field recording the time the data was generated; this field may have been corrected to the current system time as needed.

[0080] Furthermore, the status codes are mapped to status code fields in the standard response structure template. The server reads the status codes from historical log data and assigns them to predefined status code fields in the standard response structure template. This allows the client to determine the business status of the current preview request by parsing the status code fields, such as whether data was successfully retrieved.

[0081] In addition, the main business data is mapped to the data content fields in the standard response structure template. The server extracts the core business content from historical log data and populates the data content fields in the standard response structure template. This is the primary data source for front-end page rendering, ensuring that the preview page can display specific business information, such as list items and details.

[0082] Furthermore, the pagination information is mapped to the pagination information field in the standard response structure template. If the historical log data contains list data, the server extracts the pagination metadata and assigns it to the pagination information field in the standard response structure template. This enables the front-end pagination component to correctly display the page number control based on the pagination information field, supports page turning operations, and ensures the integrity of the list page preview function.

[0083] Furthermore, the generated timestamp will be mapped to the response time field in the standard response structure template. The server assigns the generated timestamp (which can be a corrected system time) from the historical log data to the response time field in the standard response structure template. This avoids front-end logic errors caused by missing or misformatted time fields.

[0084] Based on the publicly available solutions described above, by clearly defining the constituent elements of the historical log data, the integrity and standardization of the data source are ensured. By mapping the status code, business data subject, pagination information, and generation timestamp to the corresponding fields in the standard response structure template, a high degree of standardization of the data structure is achieved, enabling historical log data from different interfaces and versions to be converted into a format that the front end expects. This ensures that the front-end page can correctly determine the business status, render core content, display pagination controls, and verify time information based on the mapped data, effectively improving the fidelity and usability of the preview page.

[0085] Based on the same idea, this disclosure provides a front-end page preview system. For example... Figure 9 This is a schematic diagram of system interaction provided for an embodiment of this disclosure.

[0086] Step 901: The user accesses the URL containing the preview identifier through client 91.

[0087] Users access a URL containing a preview identifier (e.g., / test / page?__preview_mode=log) through their browser. Here, __preview_mode=log serves as the preview identifier, instructing the server to treat the current request as a preview request. This preview identifier is passed as a URL query parameter, enabling zero-configuration preview mode triggering without modifying hosts files or switching environments.

[0088] Step 902: Client 91 sends an API request (i.e., a page access request) with a preview flag to Node middleware 92.

[0089] The client parses the preview identifier in the URL and proxies all API requests to the Node middleware layer 92. The middleware in the Node middleware layer 92 parses the requests, extracting the preview identifier and request path information from the URL. If the preview identifier is detected, the Node middleware layer intercepts the request and stops forwarding it to the actual backend server 95.

[0090] Step 903: The Node middleware layer 92 queries matching historical log data through the enterprise log system 93 (that is, the historical log system mentioned above).

[0091] After identifying the scenario as a preview, Node.js middleware 92 extracts path information (e.g., / api1) and request method (e.g., GET) from the request URL, ignoring business query parameters (e.g., user ID, order number, etc.) in the URL. Based on the path information, Node.js middleware 92 initiates a query request to the enterprise log system 93, retrieving historical log data matching the path. The enterprise log system 93 performs fuzzy matching based on the path information, automatically filtering log records with failed status codes, and returns the five most recent successfully executed historical log records. This achieves parameterless preview.

[0092] Step 904: The enterprise log system 93 returns historical log data to the Node middleware 92.

[0093] The enterprise log system 93 returns multiple matched candidate log data to the Node middleware 92. Each historical log data includes fields such as the business data body, status code, pagination information, and generation timestamp. The Node middleware 92 filters out the candidate log data that was successfully executed based on the status code, sorts them in descending order according to the generation timestamp, and determines the latest historical log data at the top of the list as the target data source.

[0094] Step 905: The Node middleware layer 92 sends historical log data to the dynamic Mock generation engine 94 and performs data processing and adaptation.

[0095] The Node middleware layer 92 passes the filtered historical log data to the dynamic mock generation engine for data processing. The dynamic mock generation engine 94 performs the following processing: Data cleaning: Replace sensitive fields (such as mobile phone numbers and ID card numbers) with preset desensitized characters; correct the generated timestamp field to the current system time to prevent the front end from refusing to render due to expired data.

[0096] Template mapping: Obtain the standard response structure template used to build the preview client, map the status codes in the historical log data to the status code field of the template, map the business data body to the data content field, map the pagination information to the pagination information field, and map the generation timestamp to the response time field.

[0097] Identifier Injection: Inject a preview mode identifier field into the standard response structure template to allow the client to identify that the target response data originates from the page preview mode. Generate target response data: After completing the above processing, step 906 generates compliant Mock data that conforms to the front-end's expected format and returns it to the Node middleware layer 92.

[0098] Step 907: Node middleware 92 returns a simulated response to client 91 and renders the preview page.

[0099] The Node middleware encapsulates the target response data generated by the dynamic mock generation engine into an HTTP response and returns it to the client. Upon receiving the target response data, the client parses the preview mode identifier field to identify that it is currently in preview mode and executes the corresponding preview logic. Subsequently, the front-end framework performs component data binding, binding the main business data from the target response data to the page components, and finally renders the complete UI to display to the user. Users can then see a preview page generated based on real production environment data, without relying on a real backend service.

[0100] Step 908: Client 91 sends an API request (i.e., a page access request) to Node middleware 92 without a preview identifier.

[0101] If the preview identifier is not included, the normal process proceeds to step 909, which sends a real API request to the backend server 95, thereby enabling intelligent traffic splitting between preview traffic and normal business traffic. Then, step 910 is executed, and the backend server 95 returns the actual page.

[0102] Based on any of the above embodiments, this disclosure also provides a front-end page preview device. Figure 10 This is a schematic block diagram illustrating the structure of a front-end page preview device according to one embodiment of this disclosure. Figure 10 As shown, the user behavior-based front-end page preview device includes: a receiving module 1001, used to receive page access requests sent by a client; a parsing module 1002, used to intercept the page access request if a preview identifier is parsed from it; a querying module 1003, used to query historical log data matching the Request Uniform Resource Locator (URL) contained in the page access request from the historical log system; and a returning module 1004, used to return the target response data extracted from the historical log data to the client, so that the client can display the preview front-end page based on the target response data.

[0103] The parsing module 1002 is used to parse the page access request; based on the parsing result, it determines whether the page access request contains a preview identifier; the preview identifier is used to instruct the server to process the current request as a preview request; if the preview identifier is contained, the page access request is intercepted; if the preview identifier is not contained, it is sent to the backend server to obtain page information.

[0104] The query module 1003 is used to parse the request Uniform Resource Locator (URL) from the page access request; the URL contains path information and query parameters; and to query historical log data that matches the path information from the historical log system.

[0105] Return module 1004 is used to adapt historical log data and generate target response data; the adapted target response data is then returned to the client.

[0106] The query module 1003 is used to obtain multiple candidate log data matched from the historical log system; filter out the candidate log data that was successfully executed based on the status code contained in the candidate log data; sort the candidate log data that was successfully executed according to the generation timestamp order of the candidate log data; and determine the candidate log data that is ranked first as historical log data.

[0107] Return module 1004, which is used to obtain the standard response structure template for building the preview front-end page; map the historical log data to the target data field in the standard response structure template; inject the preview mode identifier field into the standard response structure template to generate the target response data; wherein, the preview mode identifier field is used for the client to identify that the target response data comes from the page preview mode.

[0108] Return module 1004 is used to perform data cleaning processing on historical log data. The data cleaning processing includes: replacing sensitive field data with preset desensitized characters; and / or correcting the generated timestamp field to the current system time.

[0109] Optionally, the historical log data includes the business data body, status code, pagination information, and generation timestamp; the return module 1004 is used to map the status code to the status code field in the standard response structure template; map the business data body to the data content field in the standard response structure template; map the pagination information to the pagination information field in the standard response structure template; and map the generation timestamp to the response time field in the standard response structure template.

[0110] The specific implementation process of the functions and roles of each module in the above device can be found in the implementation process of the corresponding steps in the above method, and will not be repeated here.

[0111] The entity executing the information sending method in the specific embodiments of this disclosure may be an electronic device such as a server (including a local server or a cloud computing platform).

[0112] Therefore, based on any of the above embodiments, this disclosure also provides an electronic device that can execute the front-end page preview method of any of the embodiments described above.

[0113] Figure 11 This is a schematic block diagram of an electronic device according to one embodiment of the present disclosure.

[0114] The hardware architecture of the electronic device 1000 can be implemented using a bus architecture. The bus architecture can include any number of interconnect buses and bridges, depending on the specific application of the hardware and overall design constraints. Bus 1100 connects various circuits, including one or more processors 1200, memory 1300, and / or hardware modules. Bus 1100 can also connect various other circuits 1400, such as peripheral devices, voltage regulators, power management circuits, external antennas, etc.

[0115] Bus 1100 can be an Industry Standard Architecture (ISA) bus, a Peripheral Component Interconnect (PCI) bus, or an Extended Industry Standard Component Architecture (EISA) bus, etc. Buses can be categorized as address buses, data buses, control buses, etc. For ease of representation, this diagram uses only one connection line, but this does not imply that there is only one bus or one type of bus.

[0116] This disclosure also provides a readable storage medium storing a computer program that, when executed by a processor, is used to implement the methods described above. A "readable storage medium" can be any means capable of containing, storing, communicating, propagating, or transmitting a program for use by or in conjunction with an instruction execution system, apparatus, or device. More specific examples of a readable storage medium include: an electrical connection with one or more wires (electronic device), a portable computer disk drive (magnetic device), random access memory (RAM), read-only memory (ROM), erasable and programmable read-only memory (EPROM or flash memory), fiber optic devices, and portable read-only memory (CDROM), etc.

[0117] This disclosure also provides a computer program product, the methods of which can be implemented wholly or partially through software, hardware, firmware, or any combination thereof. When implemented in software, it can be implemented wholly or partially as a computer program product. The computer program product includes one or more computer programs or instructions. When the computer program or instructions are loaded and executed, all or part of the processes or functions of this disclosure are performed.

[0118] Computer programs or instructions can be stored in a readable storage medium or transferred from one readable storage medium to another. For example, the computer program or instructions can be transferred from one website, computer, server, or data center to another website, computer, server, or data center via wired or wireless means. The readable storage medium can be any available medium capable of access, or a data storage device such as a server or data center that integrates one or more available media. The available medium can be a magnetic medium, such as a floppy disk, hard disk, or magnetic tape; an optical medium, such as a digital video optical disc; or a semiconductor medium, such as a solid-state drive. The computer-readable storage medium can be a volatile or non-volatile storage medium, or it can include both volatile and non-volatile types of storage media.

[0119] Those skilled in the art will understand that embodiments of this disclosure can be provided as methods, systems, or computer program products. Therefore, this disclosure can take the form of a completely hardware embodiment, a completely software embodiment, or an embodiment combining software and hardware aspects. Furthermore, this disclosure can 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.

[0120] This disclosure is described with reference to flowchart illustrations and / or block diagrams of methods, apparatus (systems), and computer program products according to this disclosure. 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, generate instructions for implementing the flowchart illustrations. Figure 1 One or more processes and / or boxes Figure 1 A device that provides the functions specified in one or more boxes.

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

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

[0123] In the description of this specification, the references to terms such as "one embodiment / mode," "some embodiments / modes," "example," "specific example," or "some examples," etc., refer to specific features, structures, or characteristics described in connection with that embodiment / mode or example, which are included in at least one embodiment / mode or example of this disclosure. In this specification, the illustrative expressions of the above terms do not necessarily refer to the same embodiment / mode or example. Moreover, the specific features, structures, or characteristics described may be combined in any suitable manner in one or more embodiments / modes or examples. Furthermore, without contradiction, those skilled in the art can combine and integrate the different embodiments / modes or examples described in this specification, as well as the features of different embodiments / modes or examples.

[0124] Furthermore, the terms "first" and "second" are used for descriptive purposes only and should not be construed as indicating or implying relative importance or implicitly specifying the number of technical features indicated. Thus, a feature defined as "first" or "second" may explicitly or implicitly include at least one of that feature. In the description of this disclosure, "a plurality of" means at least two, such as two, three, etc., unless otherwise explicitly specified.

[0125] Those skilled in the art should understand that the above embodiments are merely for illustrating the present disclosure and are not intended to limit the scope of the disclosure. Those skilled in the art can make other changes or modifications based on the above disclosure, and these changes or modifications still fall within the scope of the present disclosure.

Claims

1. A front-end page preview method, characterized in that, The method includes: Receive page access requests sent by the client; If a preview identifier is parsed from the page access request, then the page access request is intercepted; Based on the Request Uniform Resource Locator (URL) contained in the page access request, retrieve historical log data that matches the Request Uniform Resource Locator from the historical log system; The target response data extracted from the historical log data is returned to the client so that the client can display a preview front-end page based on the target response data.

2. The front-end page preview method according to claim 1, characterized in that, If a preview identifier is parsed from the page access request, then intercepting the page access request includes: The page access request is parsed; Determine whether the page access request contains a preview identifier based on the parsing results; If the preview identifier is included, the page access request is blocked; If the preview identifier is not included, the page information will be sent to the backend server.

3. The front-end page preview method according to claim 1, characterized in that, The step of retrieving historical log data matching the Request Uniform Resource Locator (URL) from the historical log system based on the URL contained in the page access request includes: The Request Uniform Resource Locator (URL) is parsed from the page access request; wherein the URL contains path information and query parameters; Historical log data matching the path information was retrieved from the historical log system.

4. The front-end page preview method according to claim 1, characterized in that, After retrieving historical log data from the historical log system that matches the requested Uniform Resource Locator, the process also includes: Obtain multiple candidate log data matched from the historical log system; Select successfully executed alternative log data based on the status codes contained in the alternative log data; The successful candidate log data is sorted according to the generation timestamp order of the candidate log data; The candidate log data that is ranked first is determined as the historical log data.

5. The front-end page preview method according to claim 1, characterized in that, The step of returning the target response data extracted from the historical log data to the client includes: The historical log data is adapted to generate the target response data; The adapted target response data is returned to the client.

6. The front-end page preview method according to claim 5, characterized in that, The adaptation process for the historical log data includes: Obtain the standard responsive structure template used to build the preview front-end page; Map the historical log data to the target data field in the standard response structure template; A preview mode identifier field is injected into the standard response structure template to generate the target response data; wherein, the preview mode identifier field is used by the client to identify that the target response data originates from the page preview mode.

7. The front-end page preview method according to claim 6, characterized in that, Before mapping the historical log data to the target data field in the standard response structure template, the process also includes: The historical log data undergoes data cleaning processing, which includes: replacing sensitive field data with preset de-identified characters; and / or, The generated timestamp field has been corrected to reflect the current system time.

8. The front-end page preview method according to claim 6 or 7, characterized in that, The historical log data includes the business data body, status code, pagination information, and the generation timestamp. The step of mapping the historical log data to the target data field in the standard response structure template includes: Map the status code to the status code field in the standard response structure template; Map the business data subject to the data content field in the standard response structure template; Map the pagination information to the pagination information field in the standard response structure template; The generated timestamp is mapped to the response time field in the standard response structure template.

9. An electronic device, characterized in that, include: The memory stores execution instructions; as well as, A processor that executes execution instructions stored in the memory, causing the processor to perform the method of any one of claims 1 to 8.

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

Images