Zero-code platform page data management method and system based on JSON and content distribution network

Abstract

The invention relates to the technical field of zero-code development platforms, and discloses a zero-code platform page data management method and system based on a JSON and a content distribution network. The method comprises the following steps: when a client requests data, a content distribution server encrypts the data by using an asymmetric encryption technology and then issues the data, and the client decrypts and renders the data; dynamic binding and rendering of a page structure JSON and independent service data JSON are achieved by configuring a data mapping rule; a versioned file and a list index mechanism are adopted, and incremental updating of page data by a client is supported. According to the method, the page data is stripped from the central database, and the CDN is used for safe and efficient distribution, so that the pressure of the database is remarkably reduced, and the system performance, the publishing agility, the safety and the flexibility are improved.

Description

Technical Field

[0001] This invention relates to the field of computer application technology, specifically to no-code / low-code development platform technology, and more particularly to a no-code platform page data management method and system based on JSON (JavaScript Object Notation) and Content Delivery Network (CDN). Background Technology

[0002] As enterprises deepen their digital transformation, no-code development platforms have gained widespread attention due to their ability to significantly lower the barrier to application development and improve development efficiency. Users can quickly build business application pages through visual drag-and-drop and configuration methods. A core technical challenge in these platforms is how to efficiently and securely manage the page data generated by the designer (i.e., page structure, component configuration, etc.) and achieve rapid rendering and updates.

[0003] Currently, there are two main common solutions: The first is a real-time API call solution based on a centralized database. Page data is stored in a central database in JSON format or database tables, requiring database read / write operations for each save and render. This solution leads to enormous database input / output (I / O) pressure in high-concurrency scenarios, becoming a system performance bottleneck, with poor scalability and high maintenance costs. The second is a static build and deployment solution. Page data and the rendering engine are compiled into static files and then deployed. While this solution alleviates server pressure, any minor content modification requires a complete rebuild and deployment process, making real-time updates impossible, and resulting in a cumbersome and inefficient deployment process.

[0004] In addition, the existing solutions also have the following problems: (1) The security mechanism is weak. The traditional model based on database session and interface authentication is difficult to adapt to the scenario of using CDN for data distribution. Data faces security risks when transmitted on the public network and stored at CDN edge nodes; (2) The page structure is too tightly coupled with dynamic business data. It is difficult to flexibly update dynamic data generated by external business systems while keeping the page structure unchanged. The platform is not flexible enough.

[0005] Therefore, there is an urgent need for a new page data management solution to address the performance bottlenecks, slow updates, weak security, and poor flexibility of existing technologies. Summary of the Invention

[0006] To address the problems mentioned in the background, this invention provides a no-code platform page data management method and system based on JSON and a content delivery network. The aim is to manage page data as an independent, versionable, encrypted static resource through architectural innovation, and to utilize CDN for efficient and secure distribution, thereby comprehensively improving the performance, agility, security, and flexibility of the no-code platform.

[0007] To achieve the above objectives, the present invention adopts the following technical solution: In a first aspect, the present invention provides a no-code platform page data management system based on JSON and a content delivery network, comprising: A zero-code designer for generating page structure data and serializing it into a page structure JSON file; The account and directory management module is used to automatically create associated sub-accounts and predefined directory spaces on the content distribution server integrated with the no-code platform when a user registers on the no-code platform. The data security communication module, deployed on the client and the content distribution server, is used to perform streaming encryption and transmission of the uploaded page structure JSON file, and to perform asymmetric encryption and decryption of the distributed JSON file; The content delivery server connects to the object storage service and the content delivery network (CDN) to receive, verify, and store encrypted page structure JSON files, as well as respond to client requests, encrypt the requested JSON files, and distribute them via the CDN. The client-side rendering engine requests an encrypted JSON file from the content distribution server, decrypts it, parses and renders the page, and performs dynamic business data binding and rendering according to the configuration. The application packaging and update module is used to package pages into standalone applications, embed an application directory manifest file containing remote resource addressing information, and manage the client version checking and incremental update process.

[0008] Preferably, the data security communication module adopts a dual encryption mode of "front-end streaming encryption + server-side asymmetric encryption" and integrates a composite anti-tampering verification mechanism based on tokens, request routing and file hashes to ensure the confidentiality and integrity of data throughout the entire transmission and storage chain.

[0009] Preferably, the directory space initialized by the content distribution server for each user account includes at least a pages directory for storing page structure JSON files, a vars directory for storing global variables, and a user directory for users to freely manage business data JSON files.

[0010] Preferably, the client-side rendering engine achieves decoupling and dynamic binding between the page structure and external business data by reading the data source identifier and mapping rules recorded in the component metadata.

[0011] Preferably, the application packaging and update module enables the client to intelligently detect local changes and perform incremental updates through the collaborative mechanism of the "application directory manifest file" and the "page information overview JSON", without having to rebuild and deploy the entire application.

[0012] Secondly, this invention provides a no-code platform page data management method based on JSON and a content delivery network, applied to the aforementioned system, comprising: S1. Account and Directory Initialization: In response to the user's registration operation on the no-code platform, automatically create the corresponding sub-account and predefined directory space on the content distribution server; S2. Encrypted Upload and Storage of Page Data: The page structure generated by the no-code designer is serialized into a JSON file, encrypted on the client side, and then transmitted to the content distribution server. After verification and decryption, it is stored in the specified directory of the object storage. S3. Client Data Request and Rendering: The client requests the page JSON file from the content delivery server based on the embedded addressing information. The content delivery server encrypts the file using the client's public key and then sends it out. The client decrypts the file and uses the rendering engine to parse and render it. S4. Dynamic binding of business data: During the page design phase, configure the data source and field mapping rules for the components to point to independent business data JSON files; when the page is rendered, the client requests business data according to the configuration and populates the data into the components according to the mapping rules. S5. Application Packaging and Incremental Updates: Package the project as an independent application and embed a manifest file that records remote resource addressing information; after a page is updated, the content distribution server generates a new version file and updates the version index. The client detects the update by comparing the index and pulls the updated content to achieve incremental rendering.

[0013] Thirdly, the present invention provides an electronic device and a computer-readable storage medium for performing the above-described method.

[0014] Compared with the prior art, the present invention has the following beneficial effects: Significant improvements in system performance and scalability: By offloading page data from the central database and relocating it to CDN and object storage, the pressure of high-concurrency rendering requests is shifted to CDN edge nodes, fundamentally resolving the database I / O bottleneck. Page data is stored in JSON file format, naturally aligning with CDN caching mechanisms, enabling globally fast loading and excellent horizontal scalability.

[0015] An end-to-end secure communication mechanism has been built: an innovative dual encryption and anti-tampering verification mechanism ensures the security of data throughout the entire chain, from leaving the user's browser to storage, and then from CDN distribution to the client, providing enterprise-level security for the distribution of sensitive data in the public network environment.

[0016] It achieves revolutionary release agility: supporting "incremental hot updates" for pages. Page modifications take effect within seconds of release, and the client automatically detects and pulls the latest content without needing to rebuild and deploy the application package. This reduces the update process from hours to seconds, greatly improving business iteration efficiency.

[0017] Enhanced platform flexibility and application capabilities: By separating the management of business data JSON from page structure JSON and introducing declarative data mapping rules, the static page structure and dynamic business data are decoupled. This enables pages to flexibly consume external data, expanding the no-code platform's ability to handle complex and dynamic business scenarios.

[0018] It has significant cost reduction and efficiency improvement value: reducing database load directly reduces hardware and operation and maintenance costs; automated security and distribution mechanisms reduce manual intervention; real-time update capabilities accelerate business launch and A / B testing cycles, and improve the overall economic benefits and reliability of the platform. Attached Figure Description

[0019] To more clearly illustrate the technical solutions in the embodiments of the present invention or the prior art, 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 the present invention. For those skilled in the art, other drawings can be obtained based on these drawings without creative effort.

[0020] Figure 1 This is a schematic diagram of the system functional modules provided in the embodiments of the present invention.

[0021] Figure 2 This is a flowchart of page data publishing and encrypted storage provided in an embodiment of the present invention.

[0022] Figure 3 This is a flowchart of client data request and decryption rendering provided in an embodiment of the present invention.

[0023] Figure 4 This is a flowchart of dynamic binding and rendering of business data provided in an embodiment of the present invention.

[0024] Figure 5 This is a flowchart of the application packaging and incremental update mechanism provided in the embodiments of the present invention. Detailed Implementation

[0025] The technical solutions of the embodiments of the present invention will be clearly and completely described below with reference to the accompanying drawings. Obviously, the described embodiments are only some embodiments of the present invention, and not all embodiments. All other embodiments obtained by those skilled in the art based on the embodiments of the present invention without creative effort are within the scope of protection of the present invention.

[0026] In embodiments of the present invention, JSON (JavaScript Object Notation) is a lightweight, text-based data interchange format. It is essentially a standardized, readable way of describing structured data.

[0027] In embodiments of this invention, the Content Delivery Network (CDN) is a distributed geographic network consisting of a large number of servers (called edge nodes or POPs) located around the world. Its core function is to cache static content from websites or applications (such as images, videos, style sheets, script files, and JSON files as described in this invention) on these nodes that are closest to the end user in both physical and network distance.

[0028] In embodiments of the present invention, a no-code platform is an application development tool or environment that allows users to build fully functional software applications (such as websites, mobile applications, workflows, databases, etc.) without writing traditional programming code.

[0029] It should be noted that the core of this invention lies in constructing a novel architecture that treats no-code platform page data as encrypted static resources and manages and distributes them securely and efficiently through a CDN. The following embodiments illustrate the specific implementation of this architecture in detail.

[0030] Example 1 This embodiment describes the overall architecture and basic workflow of a no-code platform page data management system based on JSON and a content delivery network provided by the present invention. Please refer to... Figure 1 The system mainly includes a zero-code designer for communication connections, an account and directory management module, a data security communication module, a content distribution server, a client-side rendering engine, and an application packaging and update module. These modules work together to achieve full-lifecycle management of page data from generation to rendering.

[0031] The zero-code designer is used to generate page structure data and serialize it into a page structure JSON file. The core task of the zero-code designer is to accurately, efficiently, and structurally transform the user's visual operations into a page structure JSON file that the subsequent system can understand, distribute, and render.

[0032] The zero-code designer is a core tool for building visual applications, and its workflow follows a complete transformation path from visual design to structured data output. The entire process begins with building the visual design interface. The system provides an interactive canvas and a modular component library. Users can place basic components, layout components, and advanced components in designated positions on the canvas through intuitive drag-and-drop operations. When a user drags a component, the front-end framework captures the operation intent through an event listener mechanism, triggering the component instantiation process in the canvas area—the system creates a corresponding data model object based on the component type, automatically calculates coordinates and dimensions, adds the object to the page component tree, and renders the visual form in real time through a two-way binding mechanism.

[0033] After completing the component layout, users can fine-tune the selected components through the property panel. The property panel establishes a two-way binding with the component data model; any modifications to style, data, or behavioral attributes by the user will immediately synchronize to the memory model and trigger a canvas re-render, achieving a WYSIWYG editing experience. To enable dynamic interaction, the system provides event and action configuration functions. Users can bind predefined events to components and associate corresponding actions. Specifically, when configuring the "Load Remote Data" action, the system guides the user to specify the path to the business data JSON file on the content server and defines the binding rules from data fields to component properties through a visual mapping interface.

[0034] All design operations ultimately converge into a page structure data model in memory, a deep JavaScript object containing a complete component tree, style rules, attribute values, and event configurations. When a user triggers a publish command, the system converts this model into a well-formatted string through JSON serialization, forming a JSON file containing the entire page blueprint. This file then serves as the data payload, triggering subsequent encryption and upload processes, entering a secure management system based on a content delivery network, completing the full closed loop of transformation from visual design to distributable data artifacts.

[0035] The embodiments of the present invention use a zero-code designer to accurately translate the user's visual drag-and-drop configuration into machine-readable, structured JSON data semantics. At the same time, it can also translate the JSON data semantics back into graphical semantics in real time for the user to preview, thus building a powerful, bidirectional "translator" for the system of the present invention.

[0036] The account and directory management module is used to automatically create associated sub-accounts and predefined directory spaces on the content distribution server integrated with the no-code platform when a user registers on the no-code platform.

[0037] The account and directory management module acts as a bridge between the no-code platform and the content delivery server, responsible for the synchronous mapping of user identities and the automatic initialization of storage space. Its workflow begins with a user successfully registering a primary account on the no-code platform. At this point, the platform's identity management system captures the registration event and extracts key user information (such as user ID and username). Subsequently, this module securely calls the content delivery server's account management service through a pre-built application programming interface (API), passing the user information as a parameter, and requesting the content server to create a logically strictly corresponding sub-account for this user within its own system. This process ensures a one-to-one correspondence between the platform's account system and the content delivery system.

[0038] Once the account is successfully created, the directory management function is immediately activated. Based on the standardized directory structure template predefined by the no-code platform, the module instructs the content server to initialize a dedicated file storage space for the new sub-account. This standardized structure contains at least three core directories: the `pages` directory, used to store the page structure JSON files generated by the no-code designer; the `vars` directory, used to store global variables and configuration information; and the `user` directory, providing users with a self-managed space where they can freely create subdirectories and files to organize business data JSON. The entire initialization process is automated, requiring no manual user intervention. This provides users with an immediate, isolated, and structured cloud storage foundation for subsequent design, deployment, and data management activities on the no-code platform, paving the way for encrypted storage, secure distribution, and dynamic binding of subsequent data.

[0039] The data security communication module, deployed on both the client and the content distribution server, is used for streaming encryption and transmission of uploaded page structure JSON files, and for asymmetric encryption and decryption of distributed JSON files. This module employs a dual encryption mode of "front-end streaming encryption + server-side asymmetric encryption," and integrates a composite anti-tampering verification mechanism based on tokens, request routing, and file hashes to ensure the confidentiality and integrity of data throughout the entire transmission and storage chain. Specifically, the data security communication module includes: A front-end streaming encryption unit is used to convert the page structure JSON file into a binary stream and encrypt it on the client side; A security request construction unit is used to generate a security request header containing an access token and a tamper-proof hash value, wherein the tamper-proof hash value is generated based on the hash value of the access token, request route, target storage path, and file data portion; The server-side verification and decryption unit, deployed on the content distribution server, is used to verify the legitimacy of the security request header and decrypt the received encrypted binary stream. The server-side response encryption unit, deployed on the content distribution server, is used to encrypt the target JSON file using a public key bound to the requester's account before returning it when responding to a client's data request.

[0040] The data security communication module ensures end-to-end security for page data transmission and storage between the client and the content distribution server through a rigorous security process. The specific steps include: Its operation begins during the data upload phase: When a user publishes a page, the front-end streaming encryption unit converts the serialized JSON file into a binary stream on the client side and encrypts it in real time. Simultaneously, the secure request construction unit generates a secure request header. This header not only contains the access token but also generates a crucial tamper-proof hash value—this hash value is generated by concatenating and encrypting the access token, request route, target storage path, and partial file data hashes, forming a multi-layered verification base. The encrypted data stream and the secure request header are then sent to the content delivery server.

[0041] Upon receiving a request, the server-side verification and decryption unit first verifies the token's validity. Then, it uses the corresponding public key to decrypt the tamper-proof hash value and compares it to verify the request's integrity and legitimacy. After successful verification, the unit decrypts the encrypted binary stream, restoring the plaintext JSON file, which is then stored. When a client needs to retrieve data, the server-side encryption unit takes over the process: it reads the target JSON file from storage, performs asymmetric encryption using the public key bound to the requester's account, and then distributes the ciphertext via the content delivery network. The client can then decrypt the data using its local private key to obtain the plaintext data. This dual-mode approach—"front-end streaming encryption ensures upload security, while server-side asymmetric encryption ensures distribution security"—combined with a composite verification mechanism based on tokens, routing, and hashes, constructs an end-to-end trusted data channel.

[0042] The content delivery server, connected to the object storage service and the content delivery network (CDN), is used to receive, verify, and store encrypted page structure JSON files, as well as respond to client requests, encrypt the requested JSON files, and distribute them via the CDN. The directory space initialized by the content delivery server for each user account includes at least: The pages directory is used to store the page structure JSON file; The vars directory is used to store global variable configurations; The user directory allows users to freely create and manage independent business data JSON files.

[0043] As the core hub of the system, the content delivery server is responsible for coordinating the secure storage, verification, and efficient distribution of data. Its workflow begins with receiving upload requests from the no-code platform: the server first rigorously verifies the access token and tamper-proof hash value in the request header using an integrated verification mechanism to ensure the request origin is legitimate and the data has not been tampered with. After successful verification, the server decrypts the encrypted binary data stream transmitted from the front end and persistently stores the restored plaintext page structure JSON file in the backend object storage service according to a pre-defined standardized directory structure—including a `pages` directory for storing page files, a `vars` directory for storing global configurations, and a `user` directory for managing business data—and establishes a file index.

[0044] When a client initiates a data request, the content delivery server retrieves the corresponding JSON file (potentially from the pages or user directory) from object storage based on the file identifier and user token in the request. The server then performs a crucial re-encryption operation, using a public key bound to the requester's account to asymmetrically encrypt the target file, and then efficiently distributes the encrypted ciphertext through integrated content delivery network (CDN) edge nodes. This process, through a closed loop of "receive-verify-store-retrieve-re-encryption-distribution," deeply integrates secure data management capabilities with the high-performance distribution capabilities of CDN, constructing a data service layer that combines security, reliability, and scalability.

[0045] The client-side rendering engine requests an encrypted JSON file from the content distribution server, decrypts it, parses and renders the page, and performs dynamic business data binding and rendering according to the configuration. The client-side rendering engine achieves decoupling and dynamic binding of the page structure and external business data by reading the data source identifier and mapping rules recorded in the component metadata. Specifically, when performing dynamic business data binding, the client-side rendering engine is used for: Read the binding relationships recorded in the component metadata of the page structure JSON, whereby the binding relationships include the unique identifier of the target business data JSON file and the data mapping rules; Request the corresponding business data JSON file from the content distribution server based on the unique identifier; After acquiring and decrypting the business data, the specified field values ​​in the business data JSON are assigned to the corresponding configuration variables in the page component according to the data mapping rules, driving the component to re-render.

[0046] The client-side rendering engine is responsible for transforming encrypted JSON data into a user-visual interactive interface. Its workflow begins with application startup or page navigation. The engine first loads the embedded application manifest file, obtains the storage path of the required page JSON files on the content delivery server, and then sends a request to the server along with the user's token. Upon receiving the asymmetrically encrypted JSON ciphertext of the page structure, the engine decrypts it using the locally stored user private key to obtain the complete page blueprint, including the component tree, styles, and event configurations.

[0047] The core of the rendering engine lies in its dynamic data binding capability: when parsing the page structure, if it finds that the component metadata defines a data binding relationship—containing a unique identifier for the target business data JSON file (such as / user / products / list.json) and detailed data mapping rules—the engine will send an asynchronous request to the content delivery server again based on this identifier. After obtaining the encrypted business data, the engine performs a second decryption and then strictly follows the predefined mapping rules (such as mapping the productName field in the JSON to the title column of the table component) to accurately inject the business data into the configuration variables of the corresponding component. After the data injection is complete, the engine drives the relevant components to re-render, ultimately presenting a complete application interface that integrates static page structure and dynamic business data on the user end, achieving elegant decoupling and real-time synchronization of content and form.

[0048] The application packaging and update module packages pages into independent applications, embeds an application directory manifest file containing remote resource addressing information, and manages the client's version checking and incremental update process. Through a collaborative mechanism between the "application directory manifest file" and the "page information overview JSON," the application packaging and update module enables the client to intelligently detect partial changes and perform incremental updates without needing to rebuild and deploy the entire application. Specifically, the workflow of the application packaging and update module includes: During packaging, an application directory manifest file is generated and embedded. The manifest file records the mapping relationship between the logical identifiers of the remote JSON files required by the application and the storage path keywords on the content distribution server. When a page is updated and published, the content distribution server assigns an incrementing version number to the new page structure JSON file and updates the page information overview JSON file that centrally records the latest version number and path of each page. When the client starts up or polls periodically, it retrieves and compares the overall JSON of page information in the server and local cache, and detects page updates by version number; For an updated page, the client requests the latest version of the page structure JSON file based on the new path keywords in the page information overview JSON, thus achieving incremental updates.

[0049] The application packaging and update module enables a smooth transition and continuous evolution from development to runtime, with its workflow forming a complete "packaging-release-awareness-update" closed loop. During the packaging phase, the module iterates through all remote JSON resources that the application depends on, generates and stores an application directory manifest file within the application package. This manifest establishes a mapping between logical identifiers and content server storage paths, providing the client with an "address map" for dynamic resources.

[0050] When designers update and publish pages, the module-driven content delivery server performs versioning: it assigns an incrementing version number to the new page JSON file, combines a logical identifier and the version number to form a new storage path, and simultaneously updates the server-side page information overview JSON file, which centrally maintains an authoritative index of the latest versions and paths of all pages. During client-side runtime, the application locates and requests this overview file through an embedded manifest file, compares the server version with the local cache, and accurately identifies pages whose version numbers have changed. For detected updates, the client only needs to request and retrieve the differentiated new version JSON file based on the new path in the overview file, subsequently triggering a partial re-render. This mechanism revolutionizes the traditional "full replacement" update model into a "precise incremental" update, achieving seamless hot updates of application content and extreme release agility.

[0051] The no-code platform page data management system based on JSON and content delivery networks provided by this invention, through the collaborative work of the above six core modules, achieves closed-loop management of the entire chain from visual design to secure distribution, dynamic rendering and incremental updates, bringing architectural-level innovation to traditional no-code platforms and producing the following significant beneficial effects: A fundamental improvement in system performance and scalability: By decoupling page data from the central database and having the Content Delivery Network (CDN) handle the majority of high-concurrency read requests, the I / O performance bottleneck of the database in the traditional architecture is completely resolved. Page data is stored in the form of versioned JSON files, which naturally aligns with the caching and distribution mechanisms of the CDN, enabling millisecond-level loading and near-infinite horizontal scalability globally.

[0052] Constructing an end-to-end secure communication mechanism: Adopting a dual encryption mode of "front-end streaming encryption + server-side asymmetric encryption", combined with composite anti-tampering verification based on tokens, request routing and file hashes, it ensures that data is always encrypted and controlled throughout the entire process from leaving the user terminal to storage and then from CDN to the client, providing enterprise-level security for distributing sensitive business data in public networks.

[0053] Achieve revolutionary agility in publishing and updating: Support for incremental hot updates of pages. After any page is modified and published, the content is updated to the CDN in the form of versioned files within seconds. The client automatically pulls the differences and partially refreshes the page by intelligently comparing version information, without needing to rebuild and deploy the entire application package. This reduces the traditional publishing process, which takes hours or even days, to seconds, greatly improving the efficiency of business iteration and content operation.

[0054] By decoupling page structure from dynamic data, the platform's capabilities are greatly expanded: Through separate management of page structure JSON and business data JSON, and the introduction of declarative data mapping rules, pages developed with zero code can flexibly and in real-time consume dynamic data from external systems or the platform itself. This loosely coupled design not only supports the construction of highly dynamic and complex applications but also facilitates the independent development, management, and reuse of page templates and business data.

[0055] It provides a complete and automated development and deployment experience: from the automatic initialization of accounts and directories to the entire process of design, encryption, uploading, distribution, rendering and even incremental updates, the system achieves a high degree of automation, which greatly reduces the operational complexity and technical threshold for users, and truly reflects the core value of zero code: "low threshold and high efficiency".

[0056] It has significant commercial and operational cost reduction and efficiency improvement value: reducing database load directly reduces hardware costs and operational complexity; automated security and distribution mechanisms reduce reliance on professional operations and maintenance personnel; real-time update capabilities greatly accelerate the business launch, A / B testing and content operation cycle; distributed architecture avoids single points of failure, improves the overall reliability of the platform, and provides a solid technical and economic foundation for enterprises to apply zero-code platforms at scale.

[0057] Example 2 Based on Embodiment 1, this invention also provides a no-code platform page data management method based on JSON and a content delivery network, comprising the following steps: S1. Automatic Account and Directory Space Initialization: This step is primarily executed by the account and directory management module. In response to user registration on the no-code platform, it automatically creates corresponding sub-accounts and predefined directory spaces on the content distribution server. Specifically: Once a user successfully registers a primary account on the no-code platform, the platform's account and directory management module synchronously calls the content distribution server's API to automatically create a logically related sub-account on the content server using the user's information (such as the user ID). Functionally, the content server resembles a cloud storage system managed by the platform and possessing structured directory capabilities.

[0058] After an account is created, the content server will initialize the account's storage space strictly according to the directory structure predefined by the no-code platform. This standard structure includes at least: The / pages directory is specifically used to store JSON files containing the page structure generated by the designer (such as / pages / home.json, / pages / list.json).

[0059] The / vars directory is used to store platform- or user-defined global variables, configuration information, etc.

[0060] The / user directory is an open area where designers can freely create subdirectories and files to manage their independent business data (such as / user / products / data.json, / user / orders / 2024.json).

[0061] This automated initialization process provides each user with an isolated and ordered data storage environment, which forms the basis for all subsequent data operations.

[0062] S2. Streamed encrypted upload and storage of page design data. This step is mainly executed collaboratively by the data security communication module and the content distribution server. The page structure generated by the no-code designer is serialized into a JSON file, encrypted on the client side, and then transmitted to the content distribution server. After verification and decryption, it is stored in a specified directory of object storage. Specifically: Please see Figure 2 After completing the page design in the no-code designer, the user triggers the "Publish" operation. The specific process is as follows: Serialization: The designer frontend serializes the current page structure (including components, layout, styles, event configurations, etc.) into a standard page structure JSON file.

[0063] Front-end streaming encryption: To ensure data security during transmission, the JSON file is encrypted using streaming encryption technology on the front end (in the user's browser). The encryption process converts the file into a ciphertext data stream in binary format. This step ensures that the data is encrypted as soon as it leaves the client.

[0064] Constructing a security request: The frontend generates a security request header. This header includes: Access token: Issued by the no-code platform and used for identity authentication.

[0065] Tamper-proof hash value: To enhance security and prevent requests from being tampered with during transmission, a composite hash value is calculated. It is generated by concatenating "access token + routing address of this request + target storage path of the file on the content server + hash value of the first 1KB of the file's binary data", and then encrypting this concatenated string using the user's public key to obtain the tamper-proof hash value.

[0066] Transmission and Server Verification: The encrypted binary data stream, along with the constructed secure request header, is sent to the content delivery server. Upon receiving the request, the content server first verifies the validity of the access token, then decrypts the tamper-proof hash value using the user's public key, and calculates its local hash according to the same rules for comparison, thus verifying the integrity and legitimacy of the request.

[0067] Server-side decryption and storage: After successful verification, the content server decrypts the received encrypted binary stream, restoring the plaintext page structure JSON file. This file is then stored in a specified path under the user's / pages directory in a backend object storage service (such as Alibaba Cloud OSS or AWS S3). Simultaneously, the content server records the new version number and storage path of this file in its index database.

[0068] This process employs a dual-mode approach: front-end streaming encryption ensures secure uploads, while server-side asymmetric encryption ensures secure distribution. Combined with a request verification mechanism, it achieves end-to-end security protection for page data from generation to storage.

[0069] S3. Client Data Request, Decryption, and Rendering: This step is led by the client-side rendering engine and interacts with the content delivery server. The client requests the page's JSON file from the content delivery server based on the embedded addressing information. The content delivery server encrypts the file using the client's public key before sending it to the client. The client then decrypts the file and uses the rendering engine to parse and render it. Specifically: Please see Figure 3 When an end user accesses a page generated by a no-code platform (which could be a designer preview or a packaged standalone application), the rendering process is as follows: Application Startup and Loading Manifest: Client-side startup (typically a web application running in a browser). If it's a packaged, standalone application, it first loads the "application manifest file" embedded in the application package. This manifest file, generated during packaging, records the mapping between the logical identifiers of all remote JSON files (page JSON and business data JSON) required by the application and their actual storage path keywords on the content server.

[0070] Initiating a data request: The client-side rendering engine, based on the identifier of the page to be rendered, looks up the corresponding storage path keyword in the manifest, and then sends an HTTP / HTTPS request to the content delivery server to retrieve the JSON file of that page. A valid user token must be included in the request.

[0071] Server-side encrypted response: After verifying the token, the content delivery server reads the corresponding page structure JSON file (plaintext) from object storage based on the path keywords in the request. Then, the server uses the public key bound to the account that initiated the request (i.e., the page owner's public key, or, in a specific scenario, the visitor's public key) to perform asymmetric encryption on the entire JSON file, generating encrypted response data.

[0072] Client-side decryption and rendering: After receiving the encrypted response data, the client decrypts it using a locally stored private key paired with the encryption public key, obtaining a plaintext JSON file containing the page structure. Finally, the client-side rendering engine (such as a custom renderer based on Vue or React) parses the JSON and renders the complete user interface in the browser according to its definitions.

[0073] This process utilizes asymmetric encryption to ensure the confidentiality of data during transmission from the content server to the client. Even if the data is cached on CDN nodes, a third party without the private key cannot decrypt and obtain the plaintext.

[0074] S4. Dynamic binding and rendering of business data. This step relies on the client-side rendering engine parsing and executing the pre-defined binding configuration in the page structure JSON. During the page design phase, the data source and field mapping rules for each component are configured to point to an independent business data JSON file. During page rendering, the client requests business data according to this configuration and populates the data into the component according to the mapping rules. Specifically: Please see Figure 4 To enable the display of dynamic business data on the page, this invention introduces a declarative data binding mechanism: Configuring binding relationships: During the design phase, users configure event actions for a component (such as a table or list) in the no-code designer, for example, "on page load". In the action's configuration panel, users can: Specify data source: Select a business data JSON file (such as / user / products / list.json) stored in the / user directory of the content server as the data source, and the system records its unique identifier.

[0075] Define mapping rules: Define data mapping rules through a graphical configuration interface. For example, specify that the productName field under the data array in the business JSON is mapped to the title column of the table component; and the price field is mapped to the amount column.

[0076] Storage binding metadata: The "target file identifier" and "data mapping rules" configured above will be serialized into the page structure JSON file as part of the component's metadata.

[0077] Runtime dynamic rendering: When the client-side rendering engine executes the "on page load" event of this component: The engine parses component metadata to obtain the identifier and mapping rules of the business data JSON file.

[0078] The engine sends a request to the content distribution server to obtain the JSON data for this business (the process is similar to obtaining the page JSON in step 3, including request, server encryption, and client decryption).

[0079] After obtaining the decrypted business data JSON, the rendering engine automatically assigns (or binds) the values ​​of specified fields in the business JSON to the corresponding variables or properties in the component configuration according to the preset "data mapping rules".

[0080] After the component receives new data, it triggers a re-render, thereby displaying the dynamic business data.

[0081] This approach achieves complete decoupling between page structure (template) and business data (content). The page structure can remain stable, while the business data can be updated and replaced independently and in real time, greatly enhancing the flexibility of the application.

[0082] S5. Application Packaging, Addressing, and Incremental Update Mechanism: This step is led by the application packaging and update module and works in conjunction with the content delivery server and the client rendering engine. The project is packaged as an independent application, embedding a manifest file that records remote resource addressing information. After a page update, the content delivery server generates a new version file and updates the version index. The client detects the update by comparing the index and retrieves the updated content, achieving incremental rendering. Specifically: Please see Figure 5 To support the deployment of zero-code pages as independently deployable and accessible applications, and to enable agile content updates, this invention designs the following mechanism: Application packaging and manifest burning: Users trigger the "package and publish" operation on the platform. The packaging program will package static code resources such as the client rendering engine and UI component library into a standard web application package (such as a set of HTML, JS, and CSS files).

[0083] Key step: The packaging system scans all remote JSON resources (page JSON and business data JSON) that the current application depends on, generating an application directory manifest file (manifest.json). This manifest file records the mapping relationship between the logical ID of each resource (such as "homePage", "productListData") and its storage path keywords on the content server (such as " / pages / home / v1.json", " / user / products / v2.json").

[0084] This manifest.json file is "burned" (i.e., embedded as an immutable static resource) into the final application package during packaging. When the application starts on the client, it first loads this embedded manifest to know the exact source of all dynamic content.

[0085] Versioning updates and releases: When a designer modifies a page in a no-code platform and clicks "Update & Publish," the content delivery server does not directly overwrite the old file; instead, it performs versioned storage. Assign an incrementing version number (e.g., v2) to the new page JSON file.

[0086] The logical identifier and version number together form the new storage path keyword (e.g., / pages / home / v2.json).

[0087] Update a file named "Page Information Overview JSON" (index.json). This file is stored in the application's directory on the content delivery server and centrally records the latest version number of all page JSON files and their corresponding full storage path keywords. For example: {"homePage": {"version": 2, "path": " / pages / home / v2.json"}, …}.

[0088] Client-side incremental updates: When the packaged client application starts up, or by setting up periodic polling (such as every 5 minutes), it will request the index.json file mentioned above from the content server.

[0089] The client compares the latest index.json file it retrieves with the previous version cached locally. By comparing the version numbers of each page entry, the client can accurately determine which pages have been updated.

[0090] Incremental fetching and rendering: For pages that are detected as updated, the client will initiate a new data request based on the latest path keyword provided in index.json (e.g., / pages / home / v2.json) to fetch and decrypt the latest version of the page's JSON file. The rendering engine will then re-render the page. For pages that have not been updated, the local cache will continue to be used, and there is no need to download them again.

[0091] This entire mechanism enables "incremental hot updates" for applications. After content operators modify a page, users do not need to download a new application package; they can automatically see the latest content on their next visit, maximizing update efficiency while saving user traffic and server bandwidth.

[0092] Example 3 This embodiment, based on Embodiment 2, provides another optional implementation of the anti-tampering verification mechanism in the data security communication module. In step 2 of Embodiment 2, the anti-tampering hash value is generated by encrypting the concatenation of "access token + request route + target path + file header hash".

[0093] In this embodiment, a more fine-grained verification method is employed. Specifically, during the front-end streaming encryption process, the entire file's binary stream can be divided into blocks (e.g., each 1KB block), and the hash value of each data block can be calculated. Then, the hash values ​​of all data blocks are concatenated sequentially, and the overall hash of this concatenated string is calculated as the "file complete hash." When constructing the secure request header, "access token + request route + target storage path + file complete hash" is concatenated and encrypted to generate a tamper-proof hash value.

[0094] After receiving the request and data stream, the content server also segments the received data stream into blocks and calculates the "complete file hash," then compares it with the hash obtained after decrypting the request header. This method can more accurately verify whether any bit-level tampering has occurred during the transmission of the entire file data, providing stronger data integrity guarantees. It is particularly suitable for application scenarios such as finance and government affairs where data integrity requirements are extremely high.

[0095] The other method steps in this embodiment are the same as those in Embodiment 2, and will not be repeated here.

[0096] Example 4 This embodiment describes an electronic device including at least one processor, a memory, and a computer program stored in the memory and executable on the processor. When the processor executes the program, it implements relevant steps in the no-code platform page data management method based on JSON and content delivery networks as described in Embodiment 1 or 2, such as controlling the verification, encryption / decryption, and file management logic of the content delivery server, or controlling the request, decryption, and rendering logic of the client rendering engine.

[0097] Example 5 This embodiment describes a computer-readable storage medium, such as a USB flash drive, external hard drive, read-only memory (ROM), random access memory (RAM), magnetic disk, or optical disk. The storage medium stores a computer program that, when executed by a processor, enables the implementation of a no-code platform page data management method based on JSON and a content delivery network as described in Embodiment 1 or 2.

[0098] In the description of this specification, the references to terms such as "an embodiment," "example," "specific example," etc., indicate that a specific feature, structure, material, or characteristic described in connection with that embodiment or example is included in at least one embodiment or example of the present invention. In this specification, the illustrative expressions of the above terms do not necessarily refer to the same embodiment or example. Furthermore, the specific features, structures, materials, or characteristics described may be combined in any suitable manner in one or more embodiments or examples.

[0099] The above description is merely a specific embodiment of the present invention, enabling those skilled in the art to understand or implement the invention. Various modifications to these embodiments will be readily apparent to those skilled in the art, and the general principles defined herein may be implemented in other embodiments without departing from the spirit or scope of the invention. Therefore, the present invention is not to be limited to the embodiments shown herein, but is to be accorded the widest scope consistent with the principles and novel features claimed herein.

Claims

1. A no-code platform page data management system based on JSON and a content delivery network, characterized in that, include: A zero-code designer for generating page structure data and serializing it into a page structure JSON file; The account and directory management module is used to automatically create associated sub-accounts and predefined directory spaces on the content distribution server integrated with the no-code platform when a user registers on the no-code platform. The data security communication module, deployed on the client and the content distribution server, is used to perform streaming encryption and transmission of the uploaded page structure JSON file, and to perform asymmetric encryption and decryption of the distributed JSON file; The content delivery server connects to the object storage service and the content delivery network (CDN) to receive, verify, and store encrypted page structure JSON files, as well as respond to client requests, encrypt the requested JSON files, and distribute them via the CDN. The client-side rendering engine requests an encrypted JSON file from the content distribution server, decrypts it, parses and renders the page, and performs dynamic business data binding and rendering according to the configuration. The application packaging and update module is used to package pages into standalone applications, embed an application directory manifest file containing remote resource addressing information, and manage the client version checking and incremental update process.

2. The system according to claim 1, characterized in that, The data security communication module includes: A front-end streaming encryption unit is used to convert the page structure JSON file into a binary stream and encrypt it on the client side; A security request construction unit is used to generate a security request header containing an access token and a tamper-proof hash value, wherein the tamper-proof hash value is generated based on the hash value of the access token, request route, target storage path, and file data portion; The server-side verification and decryption unit, deployed on the content distribution server, is used to verify the legitimacy of the security request header and decrypt the received encrypted binary stream. The server-side response encryption unit, deployed on the content distribution server, is used to encrypt the target JSON file using a public key bound to the requester's account before returning it when responding to a client's data request.

3. The system according to claim 1, characterized in that, The directory space initialized by the content distribution server for each user account includes at least: The pages directory is used to store the page structure JSON file; The vars directory is used to store global variable configurations; The user directory allows users to freely create and manage independent business data JSON files.

4. The system according to claim 1, characterized in that, When the client-side rendering engine performs dynamic business data binding, it is specifically used for: Read the binding relationships recorded in the component metadata of the page structure JSON, whereby the binding relationships include the unique identifier of the target business data JSON file and the data mapping rules; Request the corresponding business data JSON file from the content distribution server based on the unique identifier; After acquiring and decrypting the business data, the specified field values ​​in the business data JSON are assigned to the corresponding configuration variables in the page component according to the data mapping rules, driving the component to re-render.

5. The system according to claim 1, characterized in that, The application packaging and update module workflow includes: During packaging, an application directory manifest file is generated and embedded. The manifest file records the mapping relationship between the logical identifiers of the remote JSON files required by the application and the storage path keywords on the content distribution server. When a page is updated and published, the content distribution server assigns an incrementing version number to the new page structure JSON file and updates the page information overview JSON file that centrally records the latest version number and path of each page. When the client starts up or polls periodically, it retrieves and compares the overall JSON of page information in the server and local cache, and detects page updates by version number; For an updated page, the client requests the latest version of the page structure JSON file based on the new path keywords in the page information overview JSON, thus achieving incremental updates.

6. A no-code platform page data management method based on JSON and a content delivery network, applied to the system described in any one of claims 1-5, characterized in that, Including the following steps: S1. Account and Directory Initialization: In response to the user's registration operation on the no-code platform, automatically create the corresponding sub-account and predefined directory space on the content distribution server; S2. Encrypted Upload and Storage of Page Data: The page structure generated by the no-code designer is serialized into a JSON file, encrypted on the client side, and then transmitted to the content distribution server. After verification and decryption, it is stored in the specified directory of the object storage. S3. Client Data Request and Rendering: The client requests the page JSON file from the content delivery server based on the embedded addressing information. The content delivery server encrypts the file using the client's public key and then sends it out. The client decrypts the file and uses the rendering engine to parse and render it. S4. Dynamic binding of business data: During the page design phase, configure the data source and field mapping rules for the components to point to independent business data JSON files; when the page is rendered, the client requests business data according to the configuration and populates the data into the components according to the mapping rules. S5. Application Packaging and Incremental Updates: Package the project as an independent application and embed a manifest file that records remote resource addressing information; after a page is updated, the content distribution server generates a new version file and updates the version index. The client detects the update by comparing the index and pulls the updated content to achieve incremental rendering.

7. The method according to claim 6, characterized in that, In step S2, before client-side encryption, a security request header is constructed. The security request header includes an access token and a tamper-proof hash value. The tamper-proof hash value is generated by concatenating the hash values ​​of the access token, request route, target storage path, and partial file data, and then encrypting them using the user's public key.

8. The method according to claim 6, characterized in that, Step S4 specifically includes: S41. Configure event actions for the component in the designer, and specify a unique identifier for the business data JSON file associated with the event action; S42. Configure data mapping rules, defining the assignment relationship from specific fields of the business data JSON to component attribute variables; S43. Save the unique identifier and data mapping rule as part of the component metadata along with the page structure JSON; S44. When the page rendering triggers an event, the client requests and obtains the business data JSON based on the unique identifier, and performs data assignment and component rendering according to the data mapping rules.

9. An electronic device comprising a processor, a memory, and a computer program stored in the memory, characterized in that, When the processor executes the computer program, it implements the method as described in any one of claims 6 to 8.

10. A computer-readable storage medium having a computer program stored thereon, characterized in that, When the program is executed by the processor, it implements the method as described in any one of claims 6 to 8.

Images