A server-driven front-end and back-end collaborative interaction method, system, and device

Abstract

This application applies to the field of computer technology and provides a server-driven front-end and back-end collaborative interaction method, including: constructing a declarative metadata description engine, defining the attribute specifications and interaction behavior specifications of interface components using a first data contract, and generating an interface description document package; converting the interface description document package into a serialized data packet of a second data contract through a protocol bidirectional conversion engine, and generating a DSL configuration carrying a version identifier, wherein the DSL configuration encapsulates business filtering dimensions and operation instruction sets; in the front-end, receiving the DSL configuration, reconstructing the interface description document package and performing verification, and dynamically instantiating and generating interface components based on the verification result; when a version change of the DSL configuration is detected, calculating the minimum change set based on the dependency graph of the old and new versions using a graph difference algorithm, and performing hot reloading and updating based on the minimum change set, thereby achieving decoupling of the front-end and back-end, eliminating the need to write or modify the front-end code for each business change.

Description

Technical Field

[0001] This application belongs to the field of computer technology, and in particular relates to a front-end and back-end collaborative interaction method, system, device and medium based on server-side driven interaction. Background Technology

[0002] In traditional software application development models, front-end and back-end development follow a highly coupled division of labor architecture. Front-end developers implement the layout, style, and interaction logic of interface components one by one in a hard-coded manner based on the interface documents predefined and provided by the back-end. When business requirements change, the front-end interface and the back-end interface cannot evolve independently. The front-end and back-end developers must coordinate and modify the code synchronously, and release it together after joint debugging. With the diversification of application platforms, the same business interface logic also needs to be adapted for heterogeneous terminal platforms such as Web, iOS, and Android, with each platform maintaining an independent set of interface code.

[0003] The aforementioned traditional development model has resulted in significant efficiency bottlenecks and quality risks in practical applications. Specifically, the high coupling between the front-end and back-end makes communication and coordination for business changes costly. Any minor interface adjustment or rule modification involves cross-team collaboration, leading to extended delivery cycles and making it difficult to meet the needs of agile business rapid iteration. Secondly, the multi-terminal independent development model not only causes a large amount of repetitive coding work, but also easily introduces inconsistent interactive behaviors due to differences in the technology stacks of different platforms and misunderstandings among developers, seriously affecting the consistency of the end-user experience.

[0004] Therefore, there is an urgent need for a technical solution that can achieve decoupling between the front-end and back-end, support dynamic interface driving, and unified rendering across multiple platforms. Summary of the Invention

[0005] This application provides a front-end and back-end collaborative interaction method, system, device, and medium based on server-side driven technology, which can solve one of the above-mentioned problems in the prior art.

[0006] In a first aspect, embodiments of this application provide a front-end and back-end collaborative interaction method based on server-side driving, including: Build a declarative metadata description engine, use the first data contract to define the attribute specifications and interaction behavior specifications of the interface components, and generate an interface description document package; The interface description document package is converted into a serialized data packet of the second data contract through a protocol bidirectional conversion engine, and a DSL configuration carrying a version identifier is generated. The DSL configuration encapsulates business filtering dimensions and operation instruction sets. In the front end, the DSL configuration is received, the interface description document package is reconstructed and verified, and interface components are dynamically instantiated and generated based on the verification result. When a version change of the DSL configuration is detected, a minimum change set is calculated based on the dependency graph of the old and new versions using a graph difference algorithm, and a hot reload update is performed based on the minimum change set.

[0007] Furthermore, the first data contract is a JSON Schema; The declarative metadata description engine includes a metadata collection and abstraction layer, a specification compilation and constraint verification layer, and a version and relationship analysis layer; wherein... The metadata collection and abstraction layer is used to receive declarative interface requirements and abstract them into structured metadata entries. The specification compilation and constraint verification layer has a built-in JSON Schema generator, which is used to automatically compile the structured metadata entries into a JSON Schema interface description document based on the pre-set component knowledge graph and cross-platform rendering constraints, and declare the interaction behavior specifications of the interface components through custom extended keywords during the compilation process. The version and relationship analysis layer is used to simultaneously analyze the dependencies between component attributes when generating the interface description document, generate a dependency diagram of atomic components, and encapsulate the dependency diagram and the interface description document into an interface description document package.

[0008] Furthermore, the second data contract is Protocol Buffers; The step of converting the interface description document package into a serialized data packet of the second data contract through a bidirectional protocol conversion engine includes: Load and parse the interface description document package, extract standard keywords and custom extended keywords, and construct an enhanced abstract syntax tree; Establish a contract mapping rule base, traverse the enhanced abstract syntax tree, and map component attribute definitions to message bodies in Protocol Buffers format; Construct a bidirectional mapping table to record the correspondence between the component attributes of each interface component in the interface description document and the field identifiers in Protocol Buffers format; The message body in the Protocol Buffers format is optimized for serialization to generate a serialized data packet.

[0009] Furthermore, the generation of the DSL configuration carrying a version identifier, wherein the DSL configuration encapsulates service filtering dimensions and operation instruction sets, including: Receive business requirements and compile them into business filtering dimensions and operation instruction sets. The business filtering dimensions include a unique dimension identifier, a bound data field path, a filter control type, a default value, optional data sources, and condition activation rules. The operation instruction set includes an instruction identifier, a trigger condition, a target API endpoint, an HTTP method, request parameter mapping rules, a pre-validation rule set, and a post-state change declaration. The service filtering dimensions and the operation instruction set are atomically encapsulated and appended to the DSL configuration.

[0010] Furthermore, the atomic encapsulation of the business filtering dimensions and the operation instruction set includes: Each independent business filtering dimension is broken down into atomic dimension components, and each dimension component encapsulates input parameter definitions, filtering logic rules, and output data structures. Each operation instruction in the operation instruction set is encapsulated into an atomic operation component. Each operation component encapsulates a trigger condition, API endpoint, request method, parameter binding mapping, pre-validation rules, and post-state change declaration. The output data structure of the dimensional component is parsed and mapped to the parameter binding of the operation component, as well as the data filtering chain between the dimensional components, and directed edges of the data flow are established. Parse the post-state change declaration after each operation instruction is executed, identify the UI components whose state changes are triggered by the execution of the operation instruction, and establish event triggering dependency edges; Identify explicit call chains between operation components and establish sequential dependency edges between operation components; Based on the directed edges of the data stream, the event-triggered dependency edges, and the sequential dependency edges, a dependency graph is constructed. The nodes of the dependency graph represent atomic components, the directed edges represent the dependencies between components, and the direction of the directed edges represents the direction of influence.

[0011] Furthermore, in the front-end, receiving the DSL configuration, reconstructing and validating the interface description document package, and dynamically instantiating and generating interface components based on the validation result includes: The system receives the DSL configuration and deserializes it into a structured message object, while extracting the version identifier, dependency graph, and bidirectional mapping table embedded in the DSL configuration. Based on the bidirectional mapping table, the structured message object is restored field by field to the first data contract representation structure; Based on the first data contract representation structure, attribute-level validation, business constraint-level validation, and condition evaluation validation are performed on the interface data. Based on the verification results and the platform layout hints in the first data contract representation structure, the native components of the corresponding platform are selected for dynamic instantiation.

[0012] Furthermore, when a version change in the DSL configuration is detected, the minimum change set is calculated based on the dependency graph between the old and new versions using a graph difference algorithm, including: Detect whether a new version of the DSL configuration exists on the server by at least one of the following methods: long-connection push, periodic polling, or user behavior triggering. When a new version is detected, the dependency graph of the new version is obtained and compared with the dependency graph of the current running version at the node level. Atomized component nodes whose node attributes, version identifiers or dependency edges have changed are marked as change source nodes. Query the pre-calculated influence domain of each change source node in the dependency graph, take the union of all change source nodes and their influence domains as the minimum change set, and sort the components in the minimum change set according to the dependency topology order.

[0013] Furthermore, the hot reloading update based on the minimum change set includes: Obtain the incremental DSL configuration corresponding to the minimum change set from the server. The incremental DSL configuration contains only the Protocol Buffers data of the atomic components that have changed. In the front end, the new component instance corresponding to the incremental DSL configuration is rendered and verified. If the verification passes, the new component instance replaces the corresponding old component instance in the current interface; otherwise, the update is deemed to have failed and an atomic rollback is triggered.

[0014] Secondly, embodiments of this application provide a server-driven front-end and back-end collaborative interaction system, including: The first processing module is used to build a declarative metadata description engine, which uses the first data contract to define the attribute specifications and interaction behavior specifications of the interface components and generate an interface description document package. The second processing module is used to convert the interface description document package into a serialized data packet of the second data contract through a bidirectional protocol conversion engine, and generate a DSL configuration carrying a version identifier. The DSL configuration encapsulates business filtering dimensions and operation instruction sets. The third processing module is used in the front end to receive the DSL configuration, reconstruct the interface description document package and perform verification, and dynamically instantiate and generate interface components based on the verification result. The fourth processing module is used to calculate the minimum change set based on the dependency graph of the old and new versions using a graph difference algorithm when a version change of the DSL configuration is detected, and to perform hot reloading update based on the minimum change set.

[0015] Thirdly, embodiments of this application provide a computer device, including a memory, a processor, and a computer program stored in the memory and executable on the processor. When the processor executes the computer program, it implements the aforementioned front-end and back-end collaborative interaction method based on server-side driver.

[0016] The beneficial effects of the embodiments in this application compared with the prior art are: This application discloses a server-driven front-end and back-end collaborative interaction method. Through server-side driving, the attribute specifications and interaction behavior specifications of interface components are defined declaratively on the server side. On the front end, a unified parsing engine dynamically instantiates and generates the interface, thus achieving decoupling between the front-end and back-end and eliminating the need to write or modify front-end code for each business change. Furthermore, by constructing a bidirectional protocol conversion engine, the JSON Schema interface description document package is automatically compiled into a Protocol Buffers format serialized data packet, while a bidirectional mapping table records the precise correspondence between the two, thereby reducing transmission volume and improving parsing speed by several times. In addition, the dependency graph construction accurately depicts the data flow dependencies, event triggering dependencies, and explicit call dependencies between atomic components in a directed graph form, and pre-calculates the influence domain of each component. When business rules change, a version change detection and minimum change set calculation mechanism locates the range of atomic components that need to be updated, reducing the update granularity from the page level to the component level. Simultaneously, the front end only performs hot reloading updates on components falling into the minimum change set, while other parts of the page remain completely undisturbed, eliminating the drawbacks of a full refresh. Attached Figure Description

[0017] To more clearly illustrate the technical solutions in the embodiments of this application, the drawings used in the description of the embodiments or the prior art will be briefly introduced below. Obviously, the drawings described below are only some embodiments of this application. For those skilled in the art, other drawings can be obtained based on these drawings without creative effort.

[0018] Figure 1 This is a flowchart illustrating a front-end and back-end collaborative interaction method based on server-side driving, according to an embodiment of the present invention. Figure 2 This is a schematic diagram of the structure of a front-end and back-end collaborative interaction system based on server-side driver according to an embodiment of the present invention; Figure 3 This is a schematic diagram of the structure of a computer device provided in an embodiment of the present invention. Detailed Implementation

[0019] In the following description, specific details such as particular system architectures and techniques are set forth for illustrative purposes and not for limitation, in order to provide a thorough understanding of the embodiments of this application. However, those skilled in the art will understand that this application may also be implemented in other embodiments without these specific details. In other instances, detailed descriptions of well-known systems, apparatuses, circuits, and methods have been omitted so as not to obscure the description of this application with unnecessary detail.

[0020] It should be understood that, when used in this application specification and the appended claims, the term "comprising" indicates the presence of the described features, integrals, steps, operations, elements and / or components, but does not exclude the presence or addition of one or more other features, integrals, steps, operations, elements, components and / or a collection thereof.

[0021] It should also be understood that the term “and / or” as used in this application specification and the appended claims means any combination of one or more of the associated listed items and all possible combinations, and includes such combinations.

[0022] As used in this application specification and the appended claims, the term "if" may be interpreted, depending on the context, as "when," "once," "in response to determination," or "in response to detection." Similarly, the phrase "if determined" or "if detected [the described condition or event]" may be interpreted, depending on the context, as meaning "once determined," "in response to determination," "once detected [the described condition or event]," or "in response to detection [the described condition or event]."

[0023] Furthermore, in the description of this application and the appended claims, the terms "first," "second," "third," etc., are used only to distinguish descriptions and should not be construed as indicating or implying relative importance.

[0024] References to "one embodiment" or "some embodiments" as described in this specification mean that one or more embodiments of this application include a specific feature, structure, or characteristic described in connection with that embodiment. Therefore, the phrases "in one embodiment," "in some embodiments," "in other embodiments," "in still other embodiments," etc., appearing in different parts of this specification do not necessarily refer to the same embodiment, but rather mean "one or more, but not all, embodiments," unless otherwise specifically emphasized. The terms "comprising," "including," "having," and variations thereof mean "including but not limited to," unless otherwise specifically emphasized.

[0025] Please see Figure 1 As shown, this invention is a front-end and back-end collaborative interaction method based on server-side driving, including the following steps: S100. Construct a declarative metadata description engine, using the first data contract to define the attribute specifications and interaction behavior specifications of the interface components, and generate an interface description document package. In some embodiments, the first data contract is a JSON Schema, and the second data contract is a Protocol Buffers; The declarative metadata description engine includes a metadata collection and abstraction layer, a specification compilation and constraint verification layer, and a version and relationship analysis layer; wherein... The metadata collection and abstraction layer is used to receive declarative interface requirements and abstract them into structured metadata entries. The specification compilation and constraint verification layer has a built-in JSON Schema generator, which is used to automatically compile the structured metadata entries into a JSON Schema interface description document based on the pre-set component knowledge graph and cross-platform rendering constraints, and declare the interaction behavior specifications of the interface components through custom extended keywords during the compilation process. The version and relationship analysis layer is used to simultaneously analyze the dependencies between component attributes when generating the interface description document, generate a dependency diagram of atomic components, and encapsulate the dependency diagram and the interface description document into an interface description document package.

[0026] In this embodiment, a declarative metadata description engine is built on the server side to fully define interface components in a standardized, structured and semantically rich manner, laying a precise data foundation for subsequent protocol conversion, dependency analysis and dynamic rendering.

[0027] Specifically, the declarative metadata description engine adopts a layered and decoupled architecture, which includes at least three core functional layers: metadata collection and abstraction layer, specification compilation and constraint verification layer, and version and relationship analysis layer.

[0028] More specifically, the metadata collection and abstraction layer connects to the business requirement awareness channel. This channel provides different requirement expression methods for different roles to obtain the business requirements of the interface. The metadata collection and abstraction layer transforms these business requirements into structured metadata entries, eliminating the need to write procedural code. Specifically, this layer abstracts natural language-based business requirements into structured metadata entries. These structured metadata entries include the target component type, the data fields to be bound, and the types of operations that can be performed, thereby eliminating procedural coding. Understandably, these structured metadata entries correspond to specific front-end component types and attributes, specifically interface metadata entries, providing direct input for subsequent JSON data structure attribute specifications and interaction behavior specifications.

[0029] Furthermore, the specification compilation and constraint verification layer has a built-in JSON Schema generator. It is worth noting that JSON Schema is a specification based on the JSON format used to describe and verify JSON data structures. It is mainly used to verify whether JSON data conforms to specified patterns, types, and constraints, such as checking whether fields are strings and whether the numerical range is compliant. It provides clear and rigorous declarations, is self-descriptive, and is widely supported by various programming languages ​​and platforms. It has good compatibility and can serve as a machine-readable and human-readable document for data, making it easy to understand the data model. Therefore, in this application, the first data contract uses JSON Schema to standardize the description of interface requirements. Specifically, the specification compilation and constraint verification layer receives structured metadata entries abstracted by the metadata collection and abstraction layer through the JSON Schema generator, outputs component structure and attribute types according to the JSON Schema standard specification, and automatically compiles the structured metadata entries into an interface description document based on the pre-set component knowledge graph and cross-platform rendering constraints.

[0030] Understandably, the component knowledge graph is a structured knowledge base maintained internally by the declarative metadata description engine. It forms a queryable and reasonable semantic network with component types as nodes and composition relationships, attribute dependencies, and validation constraints between components as edges. Cross-platform rendering constraints, on the other hand, are another structured knowledge base maintained internally by the declarative metadata description engine. They record the layout adaptation rules and format specifications for different types of UI component attributes across different terminal platforms (Web browsers, native iOS, native Android).

[0031] It is worth noting that when automatically compiling and generating the interface description document, cross-field validation rules are also introduced. For example, the constraint "the countdown end time must be greater than the current server time" is automatically generated. This rule, together with the `format: "date-time"` validation, constitutes a strict validation of the attribute value, providing a data foundation for the subsequent conversion between the first and second data contracts.

[0032] Furthermore, for the specification compilation and constraint verification layer, when generating the interface description document, the interactive behavior specifications of the interface components are declared through custom extended keywords. In a preferred embodiment, the custom extended keywords include x-ui-action, x-visible-when, and x-enable-when. x-ui-action is used to declaratively define the set of operation instructions supported by the interface component and the backend interactive behaviors it triggers, specifically including interface endpoints, request methods, and context parameter bindings. For example, in one embodiment, for the "Buy Now" button, its description in the interface description document includes standard keywords such as text and style, as well as x-ui-action:{ type: "apiCall", endpoint: " / order / create", method: "POST", payload: { productId: "$context.selectedProductId";} ... The custom extended keyword} indicates that when a user triggers the "Buy Now" button, the selectedProductId in the current context is automatically used as a parameter to POST the / order / create interface to create an order, thus expressing the backend interaction behavior completely in a machine-readable way. x-visible-when and x-enable-when are used to declare and define the visibility and availability conditions of interface components, respectively. Their conditional expressions are configured to reference the attribute values ​​of other components within the same interface or the global business state. For example, in one embodiment, a custom extended keyword for the coupon input box is x-visible-when:"$context.user.isVip == true", indicating that the coupon input box is displayed when the current user is a VIP, otherwise it is automatically hidden. This essentially describes the data-driven dependency relationship between components in a declarative way, which is beneficial for the subsequent construction of the dependency graph.

[0033] In addition, to describe the layout weights and adaptation strategies for different terminals, a custom extended keyword x-layout-hint is set to ensure that when creating dynamic instances, the layout of each platform can be automatically adapted based on the x-layout-hint extended keyword, ensuring a consistent experience across multiple terminals.

[0034] In one embodiment, for the business requirement that "the product list needs to support filtering by price", developers configure a "price range filter" control through a visual configuration interface, setting its price range to 0 to 10,000 yuan, the sliding step to 100 yuan, and the default selected range to the entire price range. Through the metadata collection and abstraction layer, the above configuration content can be abstracted into structured metadata entries. In this embodiment, the structured metadata entries include at least three metadata entries: price filtering component metadata, product list component metadata, and product card sub-component metadata. Each structured metadata entry includes the target component type, the component's unique identifier, the path to the bound data field, and a set of component attributes. The component attribute set corresponds to the standard keywords in the interface description document generated by the subsequent JSON Schema generator. For the interactive behaviors corresponding to the components, dependency declarations and interactive behavior declarations are also set, corresponding to the subsequent JSON... The custom extended keywords in the interface description document generated by the schema generator, taking the price filter component metadata as an example, have the following structured metadata entries: {Target component type: range slider filter; Component unique identifier: priceRangeFilter; Binding data field path: price field in the product list data source; Component attribute set: minimum value (value 0), maximum value (value 10000), slider step (value 100), default selected range (minimum value 0, maximum value 10000), slider label (text "price range"), display format (text "¥{value}"); Interaction behavior declaration: when the slider value changes, trigger a re-filtering request in the product list data source}. In the specification compilation and constraint validation layer, each item is compiled according to the JSON Schema standard specification. During this process, JSON... The schema generator also needs to query the pre-built component knowledge graph and cross-platform rendering constraint knowledge base to perform attribute inference, constraint injection, and platform adaptation description generation for each structured metadata entry. For example, by querying the "range slider filter" component node in the component knowledge graph, it can obtain and verify at least the following pre-built knowledge for this component type. For example, knowledge entry one: the required attribute set of the range slider filter, which stipulates that any component of the "range slider filter" type must contain four attributes: minimum value, maximum value, step size, and default range. The JSON schema generator then verifies whether the above price filter component metadata contains these four required attributes. If they are missing, it automatically supplements the default values ​​and issues a warning.Knowledge Item 2: Automatic Validation Rules for Range Slider Filters. The rules stipulate that the "minimum value" attribute of the range slider filter must be less than the "maximum value" attribute, the starting value of the "default range" must be greater than or equal to the minimum value and less than or equal to the maximum value, and the ending value of the "default range" must also be between the minimum and maximum values. Based on this, the JSON Schema generator automatically generates validation rules: minimum value strictly less than maximum value, default range starting value greater than or equal to minimum value, default range ending value less than or equal to maximum value, and default range starting value less than default range ending value. For the cross-platform rendering constraint knowledge base, it is stipulated that the range slider filter should use different interaction implementations on different platforms: HTML range sliders with dual drag handles on the web; dual thumb variants of the native UISlider on iOS; and the RangeSlider component from Material Design on Android. The JSON Schema generator injects platform layout hints into the metadata of the above price filtering components using the x-layout-hint extended keyword, guiding the front-end to select the correct native component implementation for each platform during instantiation. This generates an interface description document for the business requirement that "the product list needs to support filtering by price".

[0035] More specifically, the version and relationship analysis layer, while generating the interface description document, scans the implicit dependencies in its custom extended keywords, and analyzes the explicit and implicit dependencies between standard keywords of interface components. For example, the "display price" attribute depends on the calculation results of two business dimensions: "user membership level" and "promotion rules." This initially generates a dependency graph with atomic components as nodes and data flow and event flow as directed edges. This dependency graph is then packaged together with the interface description document into an interface description document package. It is worth noting that this interface description document package carries a version number for subsequent version updates. In addition, the dependency graph, as prior knowledge, can be used to assist in identifying the dependency graph formed by subsequent business selection dimensions and operation instruction set encapsulation.

[0036] S200. Through the protocol bidirectional conversion engine, the interface description document package is converted into a serialized data packet of the second data contract, and a DSL configuration carrying a version identifier is generated. The DSL configuration encapsulates business filtering dimensions and operation instruction sets. In some embodiments, the second data contract is Protocol Buffers; The step of converting the interface description document package into a serialized data packet of the second data contract through a bidirectional protocol conversion engine includes: Load and parse the interface description document package, extract standard keywords and custom extended keywords, and construct an enhanced abstract syntax tree; Establish a contract mapping rule base, traverse the enhanced abstract syntax tree, and map component attribute definitions to message bodies in Protocol Buffers format; Construct a bidirectional mapping table to record the correspondence between the component attributes of each interface component in the interface description document and the field identifiers in Protocol Buffers format; The message body in the Protocol Buffers format is optimized for serialization to generate a serialized data packet.

[0037] In this embodiment, a bidirectional protocol conversion engine is built on the server side. By parsing the interface description document package of the JSON Schema specification, the component structure and constraints of each interface are extracted and mapped to the message body of the second data contract, providing a standardized transmission carrier for subsequent front-end dynamic rendering. Specifically, the second data contract is Protocol Buffers. It is understandable that the interface description document obtained in step S100 has strong readability and self-explanatory ability, but its textual nature leads to a significant transmission burden in the mobile network environment. Taking the above-mentioned business requirement of "the product list needs to support filtering by price" as an example, it contains at least three component metadata. The more complex the business requirement, the more interface components there are, and the more attributes, validation rules, and layout prompts there are. As a result, the size of its JSON Schema text can reach hundreds of KB. When it is transmitted to the front end for dynamic instantiation, its transmission and parsing process is inefficient. Therefore, this application introduces the second data contract Protocol Buffers to convert the interface description document package into a serialized data packet in Protocol Buffers format. Buffers, as a binary serialization protocol, uses techniques such as replacing field names with field numbers, variable-length encoding, and optional field omission to compress the same information to one-tenth or even less of the size of a JSON Schema, improving parsing speed by several times. This allows mobile applications in weak network environments to quickly obtain and parse interface configurations, ensuring the real-time performance of dynamic rendering.

[0038] In this embodiment, a bidirectional protocol conversion engine receives the JSON Schema specification interface description document package, achieving intelligent and lossless conversion from declarative description to an efficient binary transmission protocol, and encapsulating it into a complete versioned DSL configuration. Specifically, the bidirectional protocol conversion engine adopts a modular pipeline architecture, including a schema parsing and semantic extraction module, a type mapping and contract generation module, a reverse mapping table construction and injection module, and a multi-version compilation and optimization module.

[0039] More specifically, the Schema parsing and semantic extraction module is used to load and deeply parse the JSON Schema specification interface description document generated in step S100 above. Specifically, it extracts standard keywords and custom extended keywords and their semantic content from the interface description document, and constructs an enhanced abstract syntax tree to ensure that business semantics are not lost during protocol conversion. In particular, the enhanced abstract syntax tree ensures that the attribute specifications, interaction behavior specifications, and inter-component conditional dependencies of all interface components defined in the declaration method in step S100 above will not be lost or distorted in subsequent protocol conversion, thus guaranteeing the faithful transmission of semantics.

[0040] More specifically, the type mapping and contract generation module, through a contract mapping rule base, transforms the JSON Schema specification interface description document into a Protocol Buffers format message body. In this process, it traverses the enhanced abstract syntax tree to ensure that the attribute definition of each interface component can be converted into the corresponding Protocol Buffers format message body. This message body specifically includes message definition and field declaration. In addition, validation constraints in the interface description document also need to be mapped to custom options in Protocol Buffers format to ensure that the transport protocol layer also carries complete validation semantics. Specifically, for standard keywords, basic type mapping is performed. For example, for JSON Schema, "type": "string" is mapped to the string type in Protocol Buffers; "type": "integer" is mapped to int32 or int64; "type": "number" is mapped to double or float; "type": "boolean" is mapped to bool; "type": "object" is mapped to nested messages; and "type": "array" is mapped to repeated fields. For the corresponding validation rules, keywords related to the validation rules in the interface description document are preserved through the options mechanism of Protocol Buffers. For example, "minimum": 0 is mapped to [(validate_rule) = "gte:0"]; "maxLength": 100 is mapped to [(validate_rule) = "max_len:100"]; Mapped to For custom extension keywords, the injected extension keywords such as x-ui-action and x-visible-when are preserved as primitives through Protocol Buffers extensions or custom options. For example, x-visible-when: "$context.user.isVip == true" is mapped to the option [(ui_visible_when) = "context.user.isVip == true"] in the Protocol Buffers format, ensuring the parsability of business behavior descriptions at the binary protocol layer. For cross-field validation rules, the cross-field validations defined in the interface description document are converted into option declarations in Protocol Buffers format, preserving the complete inter-component constraint relationships.

[0041] More specifically, the reverse mapping table construction and injection module constructs a bidirectional mapping table when generating the Protocol Buffers format message body. This bidirectional mapping table accurately records the correspondence between the component attributes of each interface component in the JSON Schema specification interface description document and the corresponding field identifiers in the Protocol Buffers format. This includes the basic type mapping of standard keywords, the semantic migration path of custom extended keywords, the mapping of validation rules in standard keywords, and the migration of cross-field validation rules. This bidirectional mapping table can be used for the reverse conversion of "reconstructing JSON Schema" in subsequent front-end dynamic instances.

[0042] More specifically, the multi-version compilation and optimization module is used to perform serialization optimization on the generated Protocol Buffers format message body, including field number compression, default value pruning, incremental compilation, etc., to generate serialized data packets.

[0043] In some embodiments, the generation of a DSL configuration carrying a version identifier, wherein the DSL configuration encapsulates service filtering dimensions and operation instruction sets, including: Receive business requirements and compile them into business filtering dimensions and operation instruction sets. The business filtering dimensions include a unique dimension identifier, a bound data field path, a filter control type, a default value, optional data sources, and condition activation rules. The operation instruction set includes an instruction identifier, a trigger condition, a target API endpoint, an HTTP method, request parameter mapping rules, a pre-validation rule set, and a post-state change declaration. The service filtering dimensions and the operation instruction set are atomically encapsulated and appended to the DSL configuration.

[0044] In this embodiment, in the multi-version compilation and optimization module, after completing the protocol conversion, the serialized data packets need to be encapsulated into a DSL configuration by integrating the bidirectional mapping table to minimize the transmission volume. Specifically, the DSL configuration is a binary data stream, which does not require schema parsing or pre-compilation parsing in the front end. In addition, the DSL configuration also carries a globally unique version number, a generation timestamp, and a change summary relative to the previous version (including a list of added, modified, and deleted component identifiers), providing a direct basis for subsequent front end version detection and minimum change set calculation. At the same time, according to the user's business needs, it is atomically encapsulated and attached to the DSL configuration to ensure that the subsequent front end instantiation process meets the user's actual needs.

[0045] It is worth noting that the business requirements encapsulated in the DSL configuration of this application include business filtering dimensions and operation instruction sets. Their semantic boundaries are determined by the interaction behavior specifications declared by the custom extended keywords in the interface description document package. Specifically, the dependency relationship sketch in the interface description document package is used as prior knowledge for atomic encapsulation.

[0046] Specifically, this application provides three complementary business requirement perception channels to adapt to the needs of different roles and scenarios. Specifically, for business operations personnel, a visual configuration perception channel is adopted. This channel provides a drag-and-drop interface building environment. Operations personnel can select predefined business component templates, such as "product list", "filter group", "marketing card", etc., and configure their data sources, filtering conditions and operation buttons. In the declarative metadata description engine, its metadata collection and abstraction layer automatically captures these configuration operations and transforms them into structured metadata entries. For example, if an operations personnel drag a "price range" control into the filtering area and set the range to 0-10000 yuan, the metadata collection and abstraction layer will capture it as {filterType: "range", field: "price", min: 0, max: 10000, step:100}. For product managers or business analysts, a natural language intent parsing channel is used. This channel provides a natural language requirement description input interface and, based on a domain knowledge graph-based intent parsing model, parses the natural language description into structured business requirement primitives, including target pages, new filter dimensions, conditional visibility rules, and display logic. These are then transformed into structured metadata entries through a metadata collection and abstraction layer. For scenarios requiring integration with external business systems, an external system event subscription channel is used. This channel subscribes to rule change events from external business systems via an event bus or API gateway, such as "activity launch / delaunch" notifications from a promotion engine or "level rule change" notifications from a membership system. These external system events are automatically converted into corresponding add, delete, or modify requests for business filter dimensions or operation instructions, and then transformed into structured metadata entries through a metadata collection and abstraction layer.

[0047] Furthermore, to facilitate semantic management of business requirements and improve the mapping efficiency of the interface component attributes in the interface description document generated by the declarative metadata description engine, this application converts the business requirements obtained by the business requirement perception channel into standardized business filtering dimensions and operation instruction sets. The business filtering dimensions define the way users filter data on the interface and are used to compile the filtering intent of business requirements. The types of business filtering dimensions include, but are not limited to, single-option filtering dimensions, multi-option filtering dimensions, range filtering dimensions, cascading filtering dimensions, keyword search dimensions, and Boolean switch filtering dimensions. Each dimension includes a unique dimension identifier, bound data field path, filter control type, optional data source, default value, and condition activation rules, among other dimension attributes. Specifically, in the business filtering dimensions, the single-selection dimension provides a set of mutually exclusive options, and users can only select one option as a filtering condition at a time. Its filtering control type corresponds to a group of radio buttons or a drop-down list. The multi-selection dimension provides a set of options, and users can select zero or one or more options simultaneously as joint filtering conditions. Its filtering control type corresponds to a group of multi-select checkboxes. The range dimension provides range selection within a continuous numerical interval. Users can set the upper and lower limits of the filtering range by dragging a slider or entering values. Its filtering control type can be a range slider with two draggable slider handles representing the minimum and maximum values, respectively. The Boolean dimension provides switching between two mutually exclusive states, typically used to represent the "yes" or "no" judgment of an attribute. Users filter using a toggle control, and its filtering control type can be represented by a toggle button. The keyword search dimension provides a text input area where users enter keyword strings for fuzzy matching filtering in a specified data field. Its filtering control type can be a text input box with a search icon and a clear button.

[0048] The operation instruction set is a collection of operation instructions compiled from the interactive intents in business requirements into a unified format. In other words, operation instructions define the behavioral norms for users to trigger backend business operations or frontend state changes through interface elements. Specific operation instruction types include, but are not limited to, data change instructions, resource creation instructions, state switching instructions, navigation instructions, and frontend interface operation instructions. Each operation instruction includes instruction attributes such as a unique instruction identifier, triggering conditions, target API endpoint, HTTP method, request parameter mapping rules, pre-validation rule set, and post-state change declaration. Specifically, within the operation instruction set, data modification instructions send requests to the server to create, update, or delete data records, and update the front-end interface state based on the response; resource creation instructions create a complete business record on the server, typically involving multi-step information collection and complex pre-validation; state switching instructions change the state attribute value of a data object, and the appearance state of the corresponding front-end component is updated synchronously after the request is successful; navigation instructions trigger front-end page jumps or route switching, without directly calling back-end interfaces, but may carry context parameters before the jump; and front-end interface operation instructions are limited to the local front-end and do not involve server-side interface calls, used to control the display, hiding, or layout changes of interface elements.

[0049] More specifically, after compiling and generating the business filtering dimensions and operation instruction sets, cross-dimensional consistency checks also need to be performed, including: checking whether the parameters referenced by the operation instructions are bound to the output fields of the defined filtering dimensions or component states; checking whether the mutual exclusion or dependency relationships between filtering dimensions are consistent with the business rules; and checking whether the condition visibility rules constitute circular dependencies.

[0050] Furthermore, the compiled business filtering dimensions and operation instruction sets can be managed as independent versioned business semantic assets. Specifically, a unique semantic version identifier is assigned to each complete set of business filtering dimensions and operation instruction sets generated by each compilation, and the details of the changed dimensions or instructions are recorded to form a version evolution chain of business semantics. At the same time, the definition of each business filtering dimension and the definition of each operation instruction can serve as the encapsulation boundary and functional description of atomic encapsulation.

[0051] It is worth noting that the business semantic assets generated above can serve as the core input material for the declarative metadata description engine in the above steps. Specifically, the metadata collection and abstraction layer of the declarative metadata description engine reads the bound data field paths, filter control types, and other dimension attributes of each business filtering dimension, as well as the instruction attributes of each operation instruction in the operation instruction set, to generate the attribute definitions of the corresponding structured metadata entries. The specification compilation and constraint verification layer then compiles and verifies the component attributes of the interface components in the interface description document. For example, the bound data field path corresponds to its bound data field path, the filter control type corresponds to the target component type, and the conditional activation rule generates x-visible-when and x-enable-when conditional expressions. The target API endpoint, request parameter mapping rules, etc., of each operation instruction are filled with the specific content of the x-ui-action extended keyword. Furthermore, the inter-dimensional dependencies (such as price filtering depending on the prior selection of product categories) and operation chain relationships (such as adding to the shopping cart triggering a recalculation of the total price) in the above business semantic asset compilation and identification process, along with the dependency relationship sketch, can be used as prior knowledge to construct a dependency graph.

[0052] In some embodiments, the atomic encapsulation of the business filtering dimension and the operation instruction set includes: Each independent business filtering dimension is broken down into atomic dimension components, and each dimension component encapsulates input parameter definitions, filtering logic rules, and output data structures. Each operation instruction in the operation instruction set is encapsulated into an atomic operation component. Each operation component encapsulates a trigger condition, API endpoint, request method, parameter binding mapping, pre-validation rules, and post-state change declaration. The output data structure of the dimensional component is parsed and mapped to the parameter binding of the operation component, as well as the data filtering chain between the dimensional components, and directed edges of the data flow are established. Parse the post-state change declaration after each operation instruction is executed, identify the UI components whose state changes are triggered by the execution of the operation instruction, and establish event triggering dependency edges; Identify explicit call chains between operation components and establish sequential dependency edges between operation components; Based on the directed edges of the data stream, the event-triggered dependency edges, and the sequential dependency edges, a dependency graph is constructed. The nodes of the dependency graph represent atomic components, the directed edges represent the dependencies between components, and the direction of the directed edges represents the direction of influence.

[0053] In this embodiment, when generating the DSL configuration, the business filtering dimensions and operation instruction sets need to be encapsulated into corresponding atomic components. A dependency graph of these components is constructed through dependency analysis to provide core data structure support for hot reloading and atomic rollback during subsequent version changes. Specifically, the business filtering dimensions and operation instruction sets are atomically encapsulated on the server side. For the business filtering dimensions, each independent filtering logic unit is split into an atomic dimension component. Each dimension component encapsulates: input parameter definitions, filtering logic rules, output data structures, and default values, forming a self-contained, independently versionable minimum business unit. For the operation instruction sets, each operation instruction is encapsulated into an independent atomic operation component. Each operation component encapsulates: trigger conditions, API endpoints, request methods, parameter binding mappings, pre-validation rules, and post-state change declarations, constituting a complete atomic description unit of interactive behavior.

[0054] Specifically, taking the price range filtering component in the aforementioned business requirement of "the product list needs to support filtering by price" as an example, let's construct an atomic dimension component. This price range filtering component is a range filtering dimension, and its component unique identifier is priceRangeFilter. The input parameters include minimum value boundary parameters, maximum value boundary parameters, sliding step parameters, and display format template parameters. The filtering logic rules include rule type, target field, matching logic, and boundary handling, etc. The output data structure includes the currently selected minimum value, the currently selected maximum value, whether it is in the default full range state, and formatted display text. The default values ​​include the default selected minimum value and the default selected maximum value. The values ​​of each attribute can be determined through the dimension attributes of the corresponding price range filtering component. For the operation components, taking the "Add to Cart" operation component as an example, the interaction requirement for this component is for the user to add products to the shopping cart. Its triggering conditions include the triggering event type, the triggering source component, and the triggering pre-state requirements; API endpoint: the backend interface path for adding products to the shopping cart, corresponding to the target API endpoint of the instruction attribute; HTTP method is POST, corresponding to the instruction attribute; parameter binding mapping includes product identifier, purchase quantity, product rules, user session token, etc., corresponding to the request parameter mapping rules of the instruction attribute; pre-validation rules correspond to the various rules in the pre-validation rule set in its instruction attribute, such as if the user is logged in and the session token has not expired, a login guide interface will pop up when the validation fails; if the current inventory quantity of the product is greater than or equal to the purchase quantity selected by the user, a "Insufficient inventory, X items remaining" prompt will be displayed next to the button and the button will be disabled when the validation fails, etc.; post-state change declarations include the changes to the interface components when the request is successful and when the request fails.

[0055] In some embodiments, the composition relationship declaration between atomic components is preserved during the encapsulation process, including container-subcomponent nesting relationships and slot placeholder definitions, so that multiple atomic components can be assembled into composite business components, while maintaining the independent version identifier and replaceability of each atomic component. In this process, an independent semantic version identifier is assigned to each atomic component, which is determined by the hash digest of the component content and the business semantic change level, so that each atomic component has independent version evolution and traceability capabilities.

[0056] Furthermore, the data flow and triggering relationships between each atomic component are identified to generate a dependency graph. This process employs a multi-stage dependency analysis method. In the first stage, data flow dependency analysis is used to analyze the output data structure of each atomic dimensional component and the parameter binding mapping of the operation component to identify the data flow dependencies between components, such as "the rendering of component B depends on the output value of component A". At the same time, it analyzes whether there are data filtering chains between dimensional components, such as the output of the "product list" serving as the input of "price filtering", thereby establishing directed edges of data flow. In the second stage, event-triggered dependency analysis is used to analyze the post-state change declarations of each operation component and identify the UI components whose state changes are triggered by the execution of operation instructions. For example, the execution of the "add to cart" operation will trigger a state change of the "cart badge quantity" UI component, thereby establishing an event-triggered dependency edge of "operation component → affected UI component". In the third stage, explicit call dependency analysis is used to identify explicit call chains between atomic operation components. For example, the "submit order" operation depends on the completion of the "address verification" operation. Sequential dependency edges between operation components are established, and this process can be identified by the dependency relationship sketch.

[0057] Therefore, based on the analysis results of the above three stages, a complete dependency graph is constructed in the form of a directed graph. In the graph, nodes represent atomic components, corresponding to dimensional components, operation components, and interface components. Each atomic component is assigned a semantic version identifier. In some embodiments, this semantic version identifier is jointly determined by the node attribute hash digest and the business semantic change level, enabling each atomic component to have independent version evolution and traceability capabilities. In addition, the directed edges of the dependency graph represent the dependency relationships between components, and the direction of the edge indicates the direction of influence. For example, A→B means that a change in component A will affect component B. The attributes of the edge mark its dependency type and dependency strength. The dependency type includes data flow dependency, event-triggered dependency, and explicit call dependency. The dependency strength corresponds to strong dependency and weak dependency, where strong dependency means that a change will definitely be affected, and weak dependency means that it is only possible to be affected.

[0058] In some embodiments, when generating a dependency graph, the method further includes: pre-calculating the influence domain for each atomic component node. Specifically, the influence domain is the set of all downstream nodes reachable by directed traversal along the dependency edges, and the influence domain is used as embedded metadata of the dependency graph so that the influence domain of the changed component can be directly queried when subsequent versions are changed, thereby accelerating the determination of the minimum change set.

[0059] In addition, for dependency graph generation of non-first versions, the atomic component set of the current version is compared with the previous version by differential comparison. Only the dependency relationships of newly added or changed components are re-analyzed to generate an incremental dependency graph and merge it into the original graph.

[0060] S300. In the front end, the DSL configuration is received, the interface description document package is reconstructed and verified, and interface components are dynamically instantiated and generated according to the verification result. In some embodiments, step S300 above includes: The system receives the DSL configuration and deserializes it into a structured message object, while extracting the version identifier, dependency graph, and bidirectional mapping table embedded in the DSL configuration. Based on the bidirectional mapping table, the structured message object is restored field by field to the first data contract representation structure; Based on the first data contract representation structure, attribute-level validation, business constraint-level validation, and condition evaluation validation are performed on the interface data. Based on the verification results and the platform layout hints in the first data contract representation structure, the native components of the corresponding platform are selected for dynamic instantiation.

[0061] In this embodiment, the front end receives the DSL configuration generated by the server and dynamically instantiates the front end interface. This process includes deserializing the DSL configuration to reconstruct and verify the interface description document package, and then dynamically instantiating the interface components. This transforms the server-side declarative description into a user-visible and interactive interface instance, and provides a runtime component mapping basis for subsequent version change detection and hot reloading.

[0062] In this embodiment, a unified parsing engine is built at the front end, and a multi-stage pipeline architecture is adopted to connect each stage serially, realize the unidirectional flow of data, and ensure the controllability and traceability of the parsing process. Specifically, it includes the protocol deserialization stage, the schema reverse reconstruction stage, the data verification stage, and the platform adaptation instantiation stage.

[0063] Specifically, in the protocol deserialization stage, the DSL configuration sent by the server is received and efficiently deserialized using file descriptors, thereby restoring the binary DSL configuration into a structured message object. At the same time, the version identifier, dependency graph, and bidirectional mapping table embedded in the DSL configuration are extracted and passed to the subsequent processing stages. The version identifier is passed to the front end for version comparison to determine whether the subsequent version change analysis process needs to be triggered; the dependency graph and bidirectional mapping table are passed to the subsequent platform adaptation instantiation stage and schema reverse reconstruction stage, respectively.

[0064] Specifically, in the schema reverse reconstruction phase, the structured message objects and bidirectional mapping table generated during the protocol deserialization phase are read, and the JSON Schema interface description document package is reverse-reconstructed. In this phase, based on the correspondence between the component attributes of each interface component in the interface description document and the field identifiers in Protocol Buffers format recorded in the bidirectional mapping table, the message objects are restored field by field to the first data contract representation structure, i.e., the JSON Schema document structure. Specifically, during the restoration process, Protocol Buffers format fields are mapped back to standard JSON Schema keywords and custom extended keywords.

[0065] Specifically, during the data validation phase, the reverse-engineered JSON Schema document structure is loaded, and the interface data to be rendered is validated in stages. This staged validation is divided into three levels: attribute-level validation, business constraint-level validation, and conditional evaluation validation. Attribute-level validation verifies whether the type, format, and value range of each field meet the requirements of the component attributes in the JSON Schema. Business constraint-level validation verifies whether the cross-field validation rules in the interface description document are met. Conditional evaluation validation uses custom extended keywords `x-visible-when` and `x-enable-when` to evaluate the component visibility and availability under the current business state. In some embodiments, this validation phase employs a tiered processing strategy. For blocking-level errors, such as incorrect required field types, rendering of the component and its subtrees is blocked, replaced with a preset downgraded placeholder, and the error is reported to the server. For alarm-level errors, such as format deviations of non-required fields, logs are recorded, but rendering continues. More importantly, when a component fails to validate, the system queries the set of downstream components affected by the failed component based on the dependency graph, and generates independent candidate rendering schemes for these components, such as using cached data or default values, to prevent local anomalies from spreading along the dependency chain to global rendering failure, thus ensuring the resilience of the system.

[0066] Specifically, during the platform adaptation instantiation phase, after successful verification, the engine selects the appropriate interaction implementation method based on the platform layout hints in the JSON Schema (i.e., the x-layout-hint extended keyword) and the currently running platform identifier. It then instantiates the native components for the corresponding platform and establishes data binding and event listening relationships between runtime component instances based on the dependency graph. Specifically, during instantiation, the unified parsing engine synchronously establishes a component instance registry, recording the unique identifier, current version number, position in the component tree, and associated view node references for each dynamically generated component instance. Simultaneously, the unified parsing engine establishes data binding and event listening relationships between runtime component instances based on the dependency graph—when the output value of the data source component changes, downstream components that depend on that value automatically refresh; when an operation component completes its execution, its declared post-state change events automatically trigger updates in the affected components.

[0067] S400. When a version change of the DSL configuration is detected, a minimum change set is calculated based on the dependency graph of the old and new versions using a graph difference algorithm, and a hot reload update is performed based on the minimum change set.

[0068] In some embodiments, when a version change of the DSL configuration is detected, calculating the minimum change set based on the dependency graph of the old and new versions using a graph difference algorithm includes: Detect whether a new version of the DSL configuration exists on the server by at least one of the following methods: long-connection push, periodic polling, or user behavior triggering. When a new version is detected, the dependency graph of the new version is obtained and compared with the dependency graph of the current running version at the node level. Atomized component nodes whose node attributes, version identifiers or dependency edges have changed are marked as change source nodes. Query the pre-calculated influence domain of each change source node in the dependency graph, take the union of all change source nodes and their influence domains as the minimum change set, and sort the components in the minimum change set according to the dependency topology order.

[0069] In this embodiment, after the initial instantiation of the interface components and the establishment of the component instance registry, the front-end continuously monitors the version status of the server-side DSL configuration. When a version change is detected, a graph difference algorithm based on dependency graphs is used to calculate the minimum set of atomic components affected by the change, providing precise operational scope constraints for hot reloading and atomic rollback.

[0070] Specifically, this application provides three complementary change-aware modes to adapt to different business scenarios, including a long-connection push detection mode, a periodic polling detection mode, and a user behavior-triggered detection mode. Among them, the long-connection push detection mode maintains a WebSocket or Server-Sentence Protocol between the front-end and the server. The Events long-connection channel actively pushes version change events to all connected frontend instances when the server releases a new version of the DSL configuration. Each version change event includes a new version identifier, a change summary, and a change type. Upon receiving the event, the frontend immediately triggers a version comparison process. The periodic polling detection mode sends version probe requests to the server at configurable time intervals, carrying the currently cached DSL configuration version identifier. The server compares the requests and returns the existence of a new version and its change summary. This detection mode serves as a reliable fallback solution when the long-connection push detection mode is interrupted, ensuring no change detection is missed under network fluctuations. The user behavior-triggered detection mode proactively performs a version probe when a user performs a specific navigation operation (such as page switching or pull-to-refresh) or when the application resumes from the background. This detection mode utilizes natural user actions to complete version synchronization, saving network resources in low-frequency business scenarios.

[0071] Furthermore, upon detecting a version change, a minimum change set calculation process is performed. This process is based on the dependency graphs of the old and new versions, combined with pre-calculated impact domain information and the established component instance registry, to achieve a change range calculation accurate to the atomic component level. Specifically, the dependency graph carried in the new version's DSL configuration is obtained from the server, and it is compared with the dependency graph of the current running version at the node level. The comparison dimensions include the independent semantic version identifier of each atomic component node, the hash digest of node attributes, and the dependency edge topology of the node. Nodes whose version identifier, node attributes, and inter-component dependency edges change are marked as "change source nodes".

[0072] Furthermore, for each change source node, its pre-computed influence domain can be directly queried in the dependency graph. It can be understood that the influence domain is the set of all downstream nodes that can be reached by directed traversal along the dependency edges and are pre-stored when the dependency graph is generated. Since the influence domain has been pre-computed and embedded in the graph metadata, the time complexity of this query operation is O(1), and there is no need to perform expensive graph traversal at runtime.

[0073] More specifically, the union of all change source nodes and their respective affected domains is used to form a preliminary minimum change set. Based on this, deduplication and topological sorting are performed to arrange the components in the minimum change set according to their dependency topological order. Specifically, the dependent components are placed before the dependent components to ensure that upstream components are updated before downstream components during subsequent hot reloading, thus avoiding temporary data inconsistencies.

[0074] In addition, for downstream nodes marked as "weakly dependent", a secondary evaluation is performed based on the specific change attributes of the change source node. If the change source is only a non-critical attribute, such as copywriting adjustment or style fine-tuning, the weakly dependent downstream node can be removed from the minimum change set to further narrow the hot reloading scope.

[0075] In this embodiment, while calculating the minimum change set, change conflict detection is performed. Specifically, by querying the component instance registry, it checks whether there are currently interacting components in the minimum change set, such as those in editing mode, animation playback, or data submission. These "active" components are marked as "delayed updates," and hot reloading is performed after their interaction ends. Furthermore, if multiple consecutive version changes are detected within a short period, the change source nodes and affected domains of multiple versions are aggregated to calculate the cumulative minimum change set. A single aggregated update replaces multiple consecutive hot reloadings, avoiding frequent interface disturbances. In addition, during the change process, the optimal update strategy is automatically selected based on the change scope, user interaction status, and network conditions. For minor changes involving only a single component and that component is inactive, immediate replacement is performed; for medium-sized changes involving multiple components or active components, delayed batch updates are performed; and for major changes involving global components, a full refresh can be implemented, with a user-friendly transition prompt displayed.

[0076] In some embodiments, the hot reload update based on the minimum changes set includes: Obtain the incremental DSL configuration corresponding to the minimum change set from the server. The incremental DSL configuration contains only the Protocol Buffers data of the atomic components that have changed. In the front end, the new component instance corresponding to the incremental DSL configuration is rendered and verified. If the verification passes, the new component instance replaces the corresponding old component instance in the current interface; otherwise, the update is deemed to have failed and an atomic rollback is triggered.

[0077] In this embodiment, the unique semantic version identifier of each atomic component in the minimal changeset and the current DSL configuration version number are obtained to form a component-level requirement list. The server receives this component-level requirement list and extracts only the sequence data packets in the new version Protocol Buffers format for the corresponding components, assembling them into an incremental DSL configuration package. The incremental DSL configuration package only contains the sequence data packets of the Protocol Buffers of the changed components, the corresponding bidirectional mapping table fragments, and component-level dependency edge change information, and does not contain any data of the unchanged components, making its size much smaller than the full configuration. In the front end, after receiving the incremental configuration, it verifies whether the unique semantic version identifier of each component is consistent with the request to prevent component mismatch or version downgrade during transmission.

[0078] In some embodiments, before applying new components, the front-end constructs a sandbox environment completely isolated from the main rendering environment for pre-rendering and verification of the new components. The sandbox is a memory rendering space independent of the main interface component tree, possessing its own component instance registry and virtual view nodes. Its rendering process is completely invisible to the user, producing no visual output. Furthermore, the new component instance in the sandbox obtains rendering input consistent with the real environment by reading real-time input data from the corresponding old component in the current main interface, ensuring the validity of the verification results. Thus, in the sandbox environment, rendering success verification, data validation pass verification, interactive behavior simulation verification, and dependency consistency verification are sequentially performed on the new component. After all verification items pass, the new component is marked as "replaceable". In addition, a sandbox verification timeout is set; failure to complete verification within the timeout period is considered a verification failure, triggering a rollback process. This timeout mechanism prevents the hot reloading process from being permanently suspended due to infinite loops or blocking operations of the new component.

[0079] Furthermore, after the sandbox verification is passed, an atomic replacement operation is performed, replacing the new component instance with the main interface component tree. Within one rendering cycle, the unloading of the old component, the mounting of the new component, and the state transfer are completed, ensuring that the user perceives an instantaneous switch rather than a gradual update. Before the replacement, the runtime state of the old component is read, and user interaction-related state data, such as input box text and scroll position, are migrated to the new component instance if the state structure of the old and new components is compatible, maximizing the continuity of user operations. During the replacement process, the replacement is performed in the order of the minimum change set, that is, the upstream data source component is replaced before the downstream consumer component, ensuring the consistency of the data flow direction and the correct transfer of temporary states during the replacement process.

[0080] Furthermore, once the new component is mounted, a runtime verification is immediately performed to verify that the output of the new component in the real environment is consistent with the sandbox verification results. If a difference is found, a rollback is triggered.

[0081] Specifically, when sandbox verification fails, atomic replacement fails, or post-replacement verification fails, an atomic rollback is triggered. Based on the dependency graph and the influence domain of the corresponding atomic component, the scope of components requiring rollback is precisely determined. Only the components whose changes failed and their affected downstream components are rolled back, without affecting other normally functioning parts of the page. Furthermore, based on the old version data of each component instance before replacement stored in the component instance registry, the corresponding information is directly read from the component instance registry during rollback, and the old component instances are restored in reverse order of the dependency topology.

[0082] Please see Figure 2 As shown, the present invention also provides a front-end and back-end collaborative interaction system based on server-side driving, the system comprising: First processing module 201: Used to build a declarative metadata description engine, using the first data contract to define the attribute specifications and interaction behavior specifications of the interface components, and generate an interface description document package; The second processing module 202 is used to convert the interface description document package into a serialized data packet of the second data contract through a protocol bidirectional conversion engine, and generate a DSL configuration carrying a version identifier, wherein the DSL configuration encapsulates business filtering dimensions and operation instruction sets. The third processing module 203 is used to receive the DSL configuration in the front end, reconstruct the interface description document package and perform verification, and dynamically instantiate and generate interface components based on the verification result. The fourth processing module 204 is used to calculate the minimum change set based on the dependency graph of the old and new versions using a graph difference algorithm when a version change of the DSL configuration is detected, and to perform hot reloading update based on the minimum change set.

[0083] It is understandable that, such as Figure 1 The content shown in the server-driven front-end and back-end collaborative interaction method embodiment is applicable to this server-driven front-end and back-end collaborative interaction system embodiment. The specific functions implemented in this server-driven front-end and back-end collaborative interaction system embodiment are the same as those shown in the example. Figure 1 The illustrated implementation of the server-driven front-end and back-end collaborative interaction method is the same, and achieves the same beneficial effects as shown in the example. Figure 1 The beneficial effects achieved by the server-driven front-end and back-end collaborative interaction method shown in the embodiment are also the same.

[0084] It should be noted that the information interaction and execution process between the above systems are based on the same concept as the method embodiments of the present invention. For details on their specific functions and technical effects, please refer to the method embodiments section, which will not be repeated here.

[0085] Those skilled in the art will clearly understand that, for the sake of convenience and brevity, the above-described division of functional units and modules is merely an example. In practical applications, the above functions can be assigned to different functional units and modules as needed, that is, the internal structure of the system can be divided into different functional units or modules to complete all or part of the functions described above. The functional units and modules in the embodiments can be integrated into one processing unit, or each unit can exist physically separately, or two or more units can be integrated into one unit. The integrated unit can be implemented in hardware or as a software functional unit. Furthermore, the specific names of the functional units and modules are only for easy differentiation and are not intended to limit the scope of protection of this application. The specific working process of the units and modules in the above system can be referred to the corresponding process in the foregoing method embodiments, and will not be repeated here.

[0086] Please see Figure 3 As shown, this embodiment of the invention also provides a computer device 3, including: a memory 302 and a processor 301, and a computer program 303 stored on the memory 302. When the computer program 303 is executed on the processor 301, it implements the front-end and back-end collaborative interaction method based on server-side driver as described in any of the above methods.

[0087] The computer device 3 may be a desktop computer, laptop, handheld computer, or cloud server, etc. The computer device 3 may include, but is not limited to, a processor 301 and a memory 302. Those skilled in the art will understand that... Figure 3 The computer device 3 is merely an example and does not constitute a limitation on the computer device 3. It may include more or fewer components than shown in the figure, or combine certain components, or different components, such as input / output devices, network access devices, etc.

[0088] The processor 301 may be a Central Processing Unit (CPU), or it may be other general-purpose processors, digital signal processors (DSPs), application-specific integrated circuits (ASICs), field-programmable gate arrays (FPGAs), or other programmable logic devices, discrete gate or transistor logic devices, discrete hardware components, etc. A general-purpose processor may be a microprocessor or any conventional processor.

[0089] In some embodiments, the memory 302 may be an internal storage unit of the computer device 3, such as a hard disk or memory of the computer device 3. In other embodiments, the memory 302 may be an external storage device of the computer device 3, such as a plug-in hard disk, smart media card (SMC), secure digital (SD) card, flash card, etc., equipped on the computer device 3. Furthermore, the memory 302 may include both internal and external storage units of the computer device 3. The memory 302 is used to store the operating system, applications, bootloader, data, and other programs, such as the program code of the computer program. The memory 302 can also be used to temporarily store data that has been output or will be output.

[0090] This invention also provides a computer-readable storage medium storing a computer program thereon, which, when executed by a processor, implements the server-driven front-end and back-end collaborative interaction method as described in any of the above methods.

[0091] In this embodiment, if the integrated unit is implemented as a software functional unit and sold or used as an independent product, it can be stored in a computer-readable storage medium. Based on this understanding, all or part of the processes in the methods of the above embodiments can be implemented by a computer program instructing related hardware. The computer program can be stored in a computer-readable storage medium, and when executed by a processor, it can implement the steps of the various method embodiments described above. The computer program includes computer program code, which can be in the form of source code, object code, executable files, or certain intermediate forms. The computer-readable medium can include at least: any entity or device capable of carrying computer program code to a photographic device / computer device, a recording medium, a computer memory, a read-only memory (ROM), a random access memory (RAM), an electrical carrier signal, a telecommunication signal, and a software distribution medium. Examples include USB flash drives, portable hard drives, magnetic disks, or optical disks. In some jurisdictions, according to legislation and patent practice, computer-readable media cannot be electrical carrier signals or telecommunication signals.

[0092] The above-described embodiments are only used to illustrate the technical solutions of this application, and are not intended to limit them. Although this application has been described in detail with reference to the foregoing embodiments, those skilled in the art should understand that modifications can still be made to the technical solutions described in the foregoing embodiments, or equivalent substitutions can be made to some of the technical features. Such modifications or substitutions do not cause the essence of the corresponding technical solutions to deviate from the spirit and scope of the technical solutions of the embodiments of this application, and should all be included within the protection scope of this application.

Claims

1. A server-driven front-end and back-end collaborative interaction method, characterized in that, include: Build a declarative metadata description engine, use the first data contract to define the attribute specifications and interaction behavior specifications of the interface components, and generate an interface description document package; The interface description document package is converted into a serialized data packet of the second data contract through a protocol bidirectional conversion engine, and a DSL configuration carrying a version identifier is generated. The DSL configuration encapsulates business filtering dimensions and operation instruction sets. In the front end, the DSL configuration is received, the interface description document package is reconstructed and verified, and interface components are dynamically instantiated and generated based on the verification result. When a version change of the DSL configuration is detected, a minimum change set is calculated based on the dependency graph of the old and new versions using a graph difference algorithm, and a hot reload update is performed based on the minimum change set.

2. The method as described in claim 1, characterized in that, The first data contract is a JSON Schema; The declarative metadata description engine includes a metadata collection and abstraction layer, a specification compilation and constraint verification layer, and a version and relationship analysis layer; wherein... The metadata collection and abstraction layer is used to receive declarative interface requirements and abstract them into structured metadata entries. The specification compilation and constraint verification layer has a built-in JSON Schema generator, which is used to automatically compile the structured metadata entries into a JSON Schema interface description document based on the pre-set component knowledge graph and cross-platform rendering constraints, and declare the interaction behavior specifications of the interface components through custom extended keywords during the compilation process. The version and relationship analysis layer is used to simultaneously analyze the dependencies between component attributes when generating the interface description document, generate a dependency diagram of atomic components, and encapsulate the dependency diagram and the interface description document into an interface description document package.

3. The method as described in claim 1, characterized in that, The second data contract is Protocol Buffers; The step of converting the interface description document package into a serialized data packet of the second data contract through a bidirectional protocol conversion engine includes: Load and parse the interface description document package, extract standard keywords and custom extended keywords, and construct an enhanced abstract syntax tree; Establish a contract mapping rule base, traverse the enhanced abstract syntax tree, and map component attribute definitions to message bodies in ProtocolBuffers format; Construct a bidirectional mapping table to record the correspondence between the component attributes of each interface component in the interface description document and the field identifiers in Protocol Buffers format; The message body in the Protocol Buffers format is optimized for serialization to generate a serialized data packet.

4. The method as described in claim 3, characterized in that, The generated DSL configuration carries a version identifier. The DSL configuration encapsulates service filtering dimensions and operation instruction sets, including: Receive business requirements and compile them into business filtering dimensions and operation instruction sets. The business filtering dimensions include a unique dimension identifier, a bound data field path, a filter control type, a default value, optional data sources, and condition activation rules. The operation instruction set includes an instruction identifier, a trigger condition, a target API endpoint, an HTTP method, request parameter mapping rules, a pre-validation rule set, and a post-state change declaration. The service filtering dimensions and the operation instruction set are atomically encapsulated and appended to the DSL configuration.

5. The method as described in claim 4, characterized in that, The atomic encapsulation of the business filtering dimensions and the operation instruction set includes: Each independent business filtering dimension is broken down into atomic dimension components, and each dimension component encapsulates input parameter definitions, filtering logic rules, and output data structures. Each operation instruction in the operation instruction set is encapsulated into an atomic operation component. Each operation component encapsulates a trigger condition, API endpoint, request method, parameter binding mapping, pre-validation rules, and post-state change declaration. The output data structure of the dimensional component is parsed and mapped to the parameter binding of the operation component, as well as the data filtering chain between the dimensional components, and directed edges of the data flow are established. Parse the post-state change declaration after each operation instruction is executed, identify the UI components whose state changes are triggered by the execution of the operation instruction, and establish event triggering dependency edges; Identify explicit call chains between operation components and establish sequential dependency edges between operation components; Based on the directed edges of the data stream, the event-triggered dependency edges, and the sequential dependency edges, a dependency graph is constructed. The nodes of the dependency graph represent atomic components, the directed edges represent the dependencies between components, and the direction of the directed edges represents the direction of influence.

6. The method as described in claim 1, characterized in that, In the front-end, the DSL configuration is received, the interface description document package is reconstructed and validated, and interface components are dynamically instantiated and generated based on the validation result, including: The system receives the DSL configuration and deserializes it into a structured message object, while extracting the version identifier, dependency graph, and bidirectional mapping table embedded in the DSL configuration. Based on the bidirectional mapping table, the structured message object is restored field by field to the first data contract representation structure; Based on the first data contract representation structure, attribute-level validation, business constraint-level validation, and condition evaluation validation are performed on the interface data. Based on the verification results and the platform layout hints in the first data contract representation structure, the native components of the corresponding platform are selected for dynamic instantiation.

7. The method as described in claim 1, characterized in that, When a version change in the DSL configuration is detected, the minimum change set is calculated using a graph difference algorithm based on the dependency graph between the old and new versions, including: Detect whether a new version of the DSL configuration exists on the server by at least one of the following methods: long-connection push, periodic polling, or user behavior triggering. When a new version is detected, the dependency graph of the new version is obtained and compared with the dependency graph of the current running version at the node level. Atomized component nodes whose node attributes, version identifiers or dependency edges have changed are marked as change source nodes. Query the pre-calculated influence domain of each change source node in the dependency graph, take the union of all change source nodes and their influence domains as the minimum change set, and sort the components in the minimum change set according to the dependency topology order.

8. The method as described in claim 7, characterized in that, The hot reload update based on the minimum change set includes: Obtain the incremental DSL configuration corresponding to the minimum change set from the server. The incremental DSL configuration contains only the Protocol Buffers data of the atomic components that have changed. In the front end, the new component instance corresponding to the incremental DSL configuration is rendered and verified. If the verification passes, the new component instance replaces the corresponding old component instance in the current interface; otherwise, the update is deemed to have failed and an atomic rollback is triggered.

9. A server-driven front-end and back-end collaborative interaction system, characterized in that, include: The first processing module is used to build a declarative metadata description engine, which uses the first data contract to define the attribute specifications and interaction behavior specifications of the interface components and generate an interface description document package. The second processing module is used to convert the interface description document package into a serialized data packet of the second data contract through a bidirectional protocol conversion engine, and generate a DSL configuration carrying a version identifier. The DSL configuration encapsulates business filtering dimensions and operation instruction sets. The third processing module is used in the front end to receive the DSL configuration, reconstruct the interface description document package and perform verification, and dynamically instantiate and generate interface components based on the verification result. The fourth processing module is used to calculate the minimum change set based on the dependency graph of the old and new versions using a graph difference algorithm when a version change of the DSL configuration is detected, and to perform hot reloading update based on the minimum change set.

10. A computer 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 computer program, it implements the method as described in any one of claims 1 to 8.

Images