A low-code platform and Wasm high-performance computing integration system and method

Abstract

The present invention discloses a low-code platform and Wasm high-performance computing integration system and method, which relates to the field of front-end development technology. In response to the problems of limited computing performance and poor security isolation in existing low-code platforms, the adopted solution includes five modules: a description and registration module establishes a metadata structure for the Wasm module; a dynamic loading and asynchronous compilation module realizes on-demand loading and runtime compilation, and supports caching, version verification and hot replacement; a permission sandbox and resource isolation module builds a secure environment based on permission configuration to prevent illegal operations; a parameter binding and security bridging module encapsulates a unified interface to achieve standardized interaction; and an encapsulation and lifecycle management module encapsulates the module as a visual component to support full lifecycle management. The present invention realizes the high-performance, high-security and visual integration of the Wasm module in the low-code platform.

Description

Technical Field

[0001] The present invention relates to the field of front-end development technology, and more specifically to a system and method for integrating a low-code platform with Wasm high-performance computing. Background Art

[0002] With the development of low-code platforms, more and more companies are relying on them to build front-end applications. However, traditional low-code platforms typically use JavaScript to implement modules, making them difficult to support complex logic or computationally intensive tasks such as large file compression, AI model inference, and image processing. These tasks place high demands on performance, and JavaScript presents significant bottlenecks in execution efficiency and memory management.

[0003] Wasm (WebAssembly) is a bytecode format that runs in browsers with near-native performance, supports multi-language compilation, and boasts high efficiency, portability, and security. However, existing low-code platforms generally lack native support for Wasm modules, making it difficult to dynamically integrate, configure, and use them.

[0004] Therefore, there is an urgent need for a method to embed Wasm modules into low-code platforms in a high-performance, configurable, and visual manner to improve system capabilities. Summary of the Invention

[0005] The present invention addresses the core issues of existing low-code platforms, such as limited computing performance, poor security isolation, and high module access costs, and provides a low-code platform and Wasm high-performance computing integration system and method. By systematically integrating Wasm technology into the low-code platform, standardized access, visual configuration, and secure execution of high-performance modules are achieved, significantly improving the operating efficiency and scalability of the low-code platform.

[0006] In the first aspect, the present invention provides a low-code platform and Wasm high-performance computing integrated system, and the technical solutions adopted to solve the above technical problems are as follows:

[0007] A low-code platform and Wasm high-performance computing integrated system, whose structure includes:

[0008] Wasm description and registration module, used to establish a metadata structure for each Wasm module that can be identified, reviewed, and visually edited by the low-code platform;

[0009] Dynamic loading and asynchronous compilation modules are used to implement on-demand loading and runtime compilation of Wasm modules. They support caching, version verification, and hot replacement of Wasm modules. Through asynchronous execution of the front-end Wasm compiler, they improve the resource utilization efficiency and response performance of the low-code platform.

[0010] The permission sandbox and resource isolation module is used to build a secure operating environment for Wasm modules. It implements fine-grained resource access control based on the permission configuration in the description file. It prevents illegal operations, memory leaks, and mutual interference between different Wasm modules through an independent sandbox isolation mechanism, ensuring the security and stability of the low-code platform during operation.

[0011] The parameter binding and security bridging module is used to encapsulate a unified execution interface for Wasm modules, supporting variable binding, automatic type conversion, and call scheduling in a visual interface, thus achieving standardized interaction between the low-code platform and Wasm modules.

[0012] The encapsulation and lifecycle management module is used to encapsulate registered Wasm modules into visual drag-and-drop components, supporting full lifecycle management, state tracking, exception handling, and debugging enhancements, enabling visual configuration and observability of high-performance logic components in a low-code environment.

[0013] Optionally, the Wasm description and registration modules involved specifically include:

[0014] The compilation and export unit is used to support developers to implement Wasm module business logic using compiled languages ​​and export function names and parameter structures that need to be exposed externally;

[0015] A description file generation unit is used to automatically generate a standardized description file in JSON or YAML format based on the exported Wasm module information, to implement structured definition of Wasm module metadata, input parameters, return structure, permission configuration, and low-code platform UI adaptation; metadata includes moduleName, moduleId, and version fields; input parameters include type, default value, and binding method; permission configuration includes memoryLimit, threading, and network fields;

[0016] The legality verification unit is used to automatically verify the legality of the standardized description file through the description file schema verification rules predefined by the low-code platform to ensure that it meets the constraints of parameter non-conflict and field completeness;

[0017] The component template generation unit is used to automatically extract the description file metadata and store it in the module management center of the low-code platform after the Wasm module is registered, generate a visual drag-and-drop component template, and support plug-and-play in the low-code development environment.

[0018] Optionally, the dynamic loading and asynchronous compilation modules involved specifically include:

[0019] The parsing trigger unit is used to monitor the drag event of the designer component, automatically parse the metadata of the Wasm module description file and extract the moduleId, trigger the Wasm module loading process, and achieve seamless connection between user operation and system response;

[0020] The verification and judgment unit is used to verify the validity of the locally cached Wasm module and determine whether it needs to be reloaded based on the moduleId and version. If the cache is invalid, the loading process is triggered to ensure the version consistency and loading efficiency of the Wasm module;

[0021] Load compilation units, which are used to implement non-blocking loading and compilation of Wasm modules in WebWorker through the fetch API combined with WebAssembly.compileStreaming(), supporting resource sharding and parallel processing to avoid main thread blocking;

[0022] Instance storage unit, used to store compiled Wasm module instances and compiled modules, mark status, support fast retrieval and reuse, avoid repeated compilation overhead, and optimize memory resource management;

[0023] The monitoring update unit is used to monitor Wasm module version change notifications, supports one-click hot update function, ensures real-time update of Wasm module code through preloading mechanism, is compatible with grayscale release and rollback strategies, and ensures the system's dynamic update capability.

[0024] Optionally, the permission sandbox and resource isolation modules involved specifically include:

[0025] The permission declaration verification unit is used to verify the legitimacy of the permission declaration in the Wasm module description file, ensuring that the permission field is declared according to the specification and avoiding security risks caused by undeclared permissions;

[0026] WASI permission control unit, which is used to implement fine-grained control of system resource access for Wasm modules based on the WebAssembly System Interface or a custom runner, to implement the principle of minimum permissions.

[0027] The thread data isolation unit is used to use the browser's native WebAssembly.Memory, SharedArrayBuffer, and postMessage technologies to achieve thread isolation and controlled data exchange between different Wasm modules, preventing memory out-of-bounds access and thread resource contention;

[0028] The sandbox environment creation unit is used to create an independent sandbox context before the Wasm module runs, ensuring that the Wasm module operation is restricted to an isolated environment;

[0029] The runtime monitoring unit is used to set the Wasm module operation timeout mechanism and exception capture callback, monitor dead loops and memory leaks in real time, and trigger automatic resource recovery and error isolation.

[0030] Optionally, the parameter binding and security bridging modules involved specifically include:

[0031] Configuration UI generation unit, used to automatically generate a visual configuration interface based on the Wasm module description file, and implement graphical configuration of Wasm module parameters;

[0032] The variable mapping unit is used to support users to map low-code platform variables to Wasm module input parameters through dragging or binding operations, and establish an association between front-end variables and module interfaces;

[0033] The type conversion unit is used to automatically convert JavaScript values ​​into the memory structure required by the Wasm module through the low-code platform's preprocessor before the Wasm module runs, ensuring parameter format compatibility;

[0034] The unified calling interface unit is used to provide a standardized calling interface, encapsulate Wasm module instantiation, parameter passing, and exception handling logic, and implement one-click triggering of Wasm modules.

[0035] The result parsing unit is used to parse the memory pointer value returned by the Wasm module and convert the linear memory data into JavaScript raw data for easy front-end processing.

[0036] Optionally, the packaging and lifecycle management modules involved specifically include:

[0037] The visualization generation unit is used to encapsulate the registered Wasm modules into visualization components, automatically generate independent icons, color identifiers and data binding interfaces, and realize the graphical abstraction of Wasm modules;

[0038] The lifecycle hook configuration unit is used to support the lifecycle hook configuration of visual components, allowing users to customize the response logic of each stage and enhance the controllability of visual component behavior;

[0039] The line interaction unit is used to realize the line interaction between visual components in the flowchart or page construction, supports receiving upstream output and passing it to downstream, and builds a visual data flow link;

[0040] The visualization display unit is used to provide a visual debugging window, display the visual component operation log, output data structure and execution time in real time, and improve the observability of the visual component operation status;

[0041] The update notification unit is used to trigger the visual component replacement notification when the Wasm module is updated or abnormal. It supports hot update interface calls and UI refresh to ensure that the visual component status is synchronized with the Wasm module version.

[0042] In the second aspect, the present invention provides a method for integrating a low-code platform with Wasm high-performance computing. The technical solutions adopted to solve the above technical problems are as follows:

[0043] A method for integrating a low-code platform with Wasm high-performance computing includes the following steps:

[0044] S1. Build a metadata structure for each Wasm module, including identification information that can be recognized by the low-code platform, functional description, and attribute configuration required for visual editing, forming a standardized description file to support low-code platform review and analysis;

[0045] S2. Implement on-demand dynamic loading of Wasm modules, combining caching mechanisms and version verification strategies to optimize loading efficiency; perform asynchronous compilation through the front-end Wasm compiler, support runtime module hot replacement, and improve resource utilization and responsiveness of the low-code platform;

[0046] S3. Based on the permission configuration in the description file, a permission sandbox for the Wasm module is built to implement fine-grained resource access control. Through the independent sandbox isolation mechanism, illegal operations, memory leaks, and mutual interference between different Wasm modules are prevented, ensuring safe and stable runtime.

[0047] S4. Encapsulates a unified execution interface for Wasm modules, supporting variable binding, automatic type conversion, and call scheduling in a visual interface; and implements standardized parameter interaction and data transmission between the low-code platform and the Wasm module through a secure bridging mechanism.

[0048] S5. Encapsulate registered Wasm modules into draggable visual components, integrating status tracking, exception handling, and debugging functions; provide full lifecycle management capabilities to achieve visual configuration and runtime observability of visual components in a low-code environment.

[0049] Optionally, step S1 specifically includes:

[0050] S1.1. Developers use compiled languages ​​to implement Wasm module business logic and export function names and parameter structures that need to be exposed externally.

[0051] S1.2. Based on the exported Wasm module information, a standardized description file in JSON or YAML format is automatically generated to implement the structured definition of Wasm module metadata, input parameters, return structure, permission configuration, and low-code platform UI adaptation; metadata includes moduleName, moduleId, and version fields; input parameters include type, default value, and binding method; permission configuration includes memoryLimit, threading, and network fields;

[0052] S1.3. Automatically verify the legitimacy of standardized description files through the predefined description file schema verification rules of the low-code platform to ensure that they meet the constraints of parameter non-conflict and field completeness;

[0053] S1.4. After the Wasm module is registered, the description file metadata is automatically extracted and stored in the module management center of the low-code platform, generating a visual drag-and-drop component template to support plug-and-play in the low-code development environment.

[0054] Further optionally, the step S2 specifically includes:

[0055] S2.1. Listen for designer component drag events, automatically parse the metadata of the Wasm module description file and extract the moduleId, triggering the Wasm module loading process to achieve seamless connection between user operations and system responses;

[0056] S2.2. Verify the validity of the locally cached Wasm module and determine whether it needs to be reloaded based on the moduleId and version. If the cache is invalid, the loading process is triggered to ensure the version consistency and loading efficiency of the Wasm module.

[0057] S2.3. Implement non-blocking loading and compilation of Wasm modules in Web Workers through the fetch API combined with WebAssembly.compileStreaming(), supporting resource sharding and parallel processing to avoid main thread blocking.

[0058] S2.4. Store compiled Wasm module instances and compiled modules, mark their status, support fast retrieval and reuse, avoid repeated compilation overhead, and optimize memory resource management;

[0059] S2.5. Monitor Wasm module version change notifications, support one-click hot update function, ensure real-time update of Wasm module code through preloading mechanism, be compatible with grayscale release and rollback strategies, and ensure the system's dynamic update capability;

[0060] The step S3 specifically includes:

[0061] S3.1. Verify the legitimacy of permission declarations in the Wasm module description file to ensure that permission fields are declared according to specifications and to avoid security risks caused by undeclared permissions.

[0062] S3.2. Based on the WebAssembly System Interface or a custom runner, fine-grained control is provided over the system resource access of the Wasm module to implement the principle of minimum privileges.

[0063] S3.3. Utilize the browser's native WebAssembly.Memory, SharedArrayBuffer, and postMessage technologies to achieve thread isolation and controlled data exchange between different Wasm modules, preventing out-of-bounds memory access and thread resource contention.

[0064] S3.4. Create an independent sandbox context before the Wasm module runs to ensure that the Wasm module operation is restricted to an isolated environment;

[0065] S3.5. Set the Wasm module running timeout mechanism and exception capture callback to monitor dead loops and memory leaks in real time, triggering automatic resource recovery and error isolation.

[0066] Further optionally, step S4 specifically includes:

[0067] S4.1. Automatically generate a visual configuration interface based on the Wasm module description file to implement graphical configuration of Wasm module parameters.

[0068] S4.2. Users map low-code platform variables to Wasm module input parameters by dragging or binding, establishing an association between front-end variables and module interfaces.

[0069] S4.3. Before the Wasm module runs, the low-code platform's preprocessor automatically converts JavaScript values ​​into the memory structure required by the Wasm module to ensure parameter format compatibility;

[0070] S4.4. Provide a standardized calling interface, encapsulate Wasm module instantiation, parameter passing, and exception handling logic, and implement one-click triggering of Wasm modules;

[0071] S4.5. Parse the memory pointer value returned by the Wasm module and convert the linear memory data into JavaScript raw data for easy front-end processing.

[0072] The step S5 specifically includes:

[0073] S5.1. Encapsulate the registered Wasm module as a visual component, automatically generate independent icons, color identifiers, and data binding interfaces, and implement graphical abstraction of the Wasm module.

[0074] S5.2. Visual components support lifecycle hook configuration, allowing users to customize the response logic at each stage and enhance the controllability of visual component behavior;

[0075] S5.3. Implement line interactions between visual components in flowcharts or page construction, and build visual data flow links by receiving upstream output and passing it downstream;

[0076] S5.4. Provide a visual debugging window to display the visual component's running log, output data structure, and execution time in real time, improving the observability of the visual component's running status;

[0077] S5.5. When the Wasm module is updated or an exception occurs, a visual component replacement notification is triggered. The hot update interface call and UI refresh are used to ensure that the visual component status is synchronized with the Wasm module version.

[0078] The low-code platform and Wasm high-performance computing integration system and method of the present invention have the following beneficial effects compared with the existing technology:

[0079] 1. The present invention supports on-demand dynamic loading and asynchronous compilation of Wasm modules, effectively reducing the initialization resource consumption of the low-code platform; introduces permission sandbox and operation isolation mechanism to ensure the safe operation of low-code modules and prevent unauthorized operations; through standardized call bridging and parameter binding processes, users can use Wasm modules efficiently without understanding the underlying details, significantly lowering the usage threshold; low-code modules are encapsulated as visual components within the platform, with lifecycle management capabilities, support for hot updates, log tracking and debugging information output, and enhance the controllability and usability of high-performance logic for developers and non-technical users; overall, it not only improves the low-code platform's carrying capacity for complex business logic, but also promotes low-cost integration and high-frequency use of Wasm modules, and has good technology promotion value and industrial application prospects;

[0080] 2. This invention systematically integrates Wasm technology into the low-code platform, achieving standardized access, visual configuration, and secure execution of high-performance modules, significantly improving the operating efficiency and scalability of the low-code platform. It is suitable for scenarios where the modularization capabilities and operating efficiency of the low-code platform are enhanced.

[0081] 3. The present invention realizes the high-performance, high-security, and visual integration of Wasm modules in the low-code platform. It lowers the development threshold by standardizing the Wasm module registration process, improves execution efficiency by using the Wasm runtime, and ensures system security by combining double-layer sandbox isolation. Ultimately, it gives the low-code platform the business expansion capability with high scalability, high-performance computing capabilities, and production-level security standards. BRIEF DESCRIPTION OF THE DRAWINGS

[0082] Attachment Figure 1 This is a module connection block diagram of the first embodiment of the present invention;

[0083] Attachment Figure 2 This is a flow chart of the method of embodiment 2 of the present invention. DETAILED DESCRIPTION

[0084] In order to make the technical solution, the technical problems solved and the technical effects of the present invention more clear, the technical solution of the present invention is clearly and completely described below in conjunction with specific embodiments.

[0085] Example 1: Refer to the attached Figure 1 This embodiment proposes a low-code platform and Wasm high-performance computing integrated system, whose structure includes:

[0086] Wasm description and registration module, used to establish a metadata structure for each Wasm module that can be identified, reviewed, and visually edited by the low-code platform;

[0087] Dynamic loading and asynchronous compilation modules are used to implement on-demand loading and runtime compilation of Wasm modules. They support caching, version verification, and hot replacement of Wasm modules. Through asynchronous execution of the front-end Wasm compiler, they improve the resource utilization efficiency and response performance of the low-code platform.

[0088] The permission sandbox and resource isolation module is used to build a secure operating environment for Wasm modules. It implements fine-grained resource access control based on the permission configuration in the description file. It prevents illegal operations, memory leaks, and mutual interference between different Wasm modules through an independent sandbox isolation mechanism, ensuring the security and stability of the low-code platform during operation.

[0089] The parameter binding and security bridging module is used to encapsulate a unified execution interface for Wasm modules, supporting variable binding, automatic type conversion, and call scheduling in a visual interface, thus achieving standardized interaction between the low-code platform and Wasm modules.

[0090] The encapsulation and lifecycle management module is used to encapsulate registered Wasm modules into visual drag-and-drop components, supporting full lifecycle management (initialization, operation, destruction, etc.), state tracking, exception handling, and debugging enhancements, enabling visual configuration and observability of high-performance logic components in a low-code environment.

[0091] In this embodiment, the Wasm description and registration module involved specifically includes:

[0092] The compilation and export unit is used to support developers to implement Wasm module business logic using compiled languages ​​(such as Rust / C++) and export function names and parameter structures that need to be exposed externally;

[0093] The description file generation unit is used to automatically generate a standardized description file in JSON or YAML format based on the exported Wasm module information, to implement the structured definition of Wasm module metadata, input parameters, return structure, permission configuration and low-code platform UI adaptation; among them, the metadata includes three fields: module name moduleName, module unique identifier moduleId and module version number version; the input parameters include three core attributes: type, default value and binding method; the permission configuration includes three fields: memory limit memoryLimit, thread support threading and network access permission network;

[0094] The legality verification unit is used to automatically verify the legality of the standardized description file through the description file schema verification rules predefined by the low-code platform to ensure that it meets the constraints of parameter non-conflict and field completeness;

[0095] The component template generation unit is used to automatically extract the description file metadata and store it in the module management center of the low-code platform after the Wasm module is registered, generate a visual drag-and-drop component template, and support plug-and-play in the low-code development environment.

[0096] In this embodiment, the dynamic loading and asynchronous compilation modules involved specifically include:

[0097] The parsing trigger unit is used to listen to the drag event of the designer component, automatically parse the metadata of the Wasm module description file and extract the module's unique identifier moduleId, triggering the Wasm module loading process to achieve seamless connection between user operations and system responses;

[0098] The verification and judgment unit is used to verify the validity of the locally cached Wasm module and determine whether it needs to be reloaded based on the module's unique identifier moduleId and module version number version. If the cache is invalid, the loading process is triggered to ensure the version consistency and loading efficiency of the Wasm module;

[0099] Load compilation units, which are used to implement non-blocking loading and compilation of Wasm modules in WebWorker through the fetch API combined with WebAssembly.compileStreaming(), supporting resource sharding and parallel processing to avoid main thread blocking;

[0100] Instance storage unit, used to store compiled Wasm module instances and compiled modules, marked as "Ready", supports fast retrieval and reuse, avoids repeated compilation overhead, and optimizes memory resource management;

[0101] The monitoring update unit is used to monitor Wasm module version change notifications, supports one-click hot update function, ensures real-time update of Wasm module code through preloading mechanism, is compatible with grayscale release and rollback strategies, and ensures the system's dynamic update capability.

[0102] In this embodiment, the permission sandbox and resource isolation module involved specifically include:

[0103] The permission declaration verification unit is used to verify the legitimacy of the permission declaration in the Wasm module description file, ensuring that the permission field is declared according to the specification and avoiding security risks caused by undeclared permissions;

[0104] The WASI permission control unit is used to provide fine-grained control over system resource access for Wasm modules based on the WebAssembly System Interface (WASI) or a custom runner, implementing the principle of minimum permissions.

[0105] The thread data isolation unit is used to implement thread isolation and controlled data exchange between different Wasm modules by leveraging the browser's native WebAssembly.Memory (WebAssembly memory object, used to manage linear memory space), SharedArrayBuffer (shared array buffer, allowing multi-threaded shared memory area), and postMessage (send message, the browser's cross-context communication API) technologies to prevent out-of-bounds memory access and thread resource contention.

[0106] The sandbox environment creation unit is used to create an independent sandbox context based on iframe or WebWorker before the Wasm module runs, ensuring that the Wasm module operation is restricted to an isolated environment;

[0107] The runtime monitoring unit is used to set the Wasm module operation timeout mechanism and exception capture callback, monitor dead loops and memory leaks in real time, and trigger automatic resource recovery and error isolation.

[0108] In this embodiment, the parameter binding and security bridging modules involved specifically include:

[0109] Configuration UI generation unit, which is used to automatically generate a visual configuration interface (such as input box, drop-down box, JSON editor, etc.) according to the Wasm module description file to implement graphical configuration of Wasm module parameters;

[0110] The variable mapping unit is used to support users to map low-code platform variables to Wasm module input parameters through dragging or binding operations, and establish an association between front-end variables and module interfaces;

[0111] The type conversion unit is used to automatically convert JavaScript values ​​into the memory structure required by the Wasm module through the low-code platform's preprocessor before the Wasm module runs, ensuring parameter format compatibility;

[0112] A unified calling interface unit is used to provide a standardized calling interface executeWasm(moduleId, input), encapsulate Wasm module instantiation, parameter passing, and exception handling logic, and implement one-click triggering of Wasm modules.

[0113] The result parsing unit is used to parse the memory pointer value returned by the Wasm module and convert the linear memory data into JavaScript raw data (such as image buffer and structured JSON) for front-end processing.

[0114] In this embodiment, the packaging and lifecycle management modules involved specifically include:

[0115] The visualization generation unit is used to encapsulate the registered Wasm modules into visualization components, automatically generate independent icons, color identifiers and data binding interfaces, and realize the graphical abstraction of Wasm modules;

[0116] The lifecycle hook configuration unit is used to support the configuration of lifecycle hooks such as onInit, onExecute, onError, and onDestroy of visual components, allowing users to customize the response logic of each stage and enhance the controllability of visual component behavior;

[0117] The line interaction unit is used to realize the line interaction between visual components in the flowchart or page construction, supports receiving upstream output and passing it to downstream, and builds a visual data flow link;

[0118] The visualization display unit is used to provide a visual debugging window, display the visual component operation log, output data structure and execution time in real time, and improve the observability of the visual component operation status;

[0119] The update notification unit is used to trigger the visual component replacement notification when the Wasm module is updated or abnormal. It supports hot update interface calls and UI refresh to ensure that the visual component status is synchronized with the Wasm module version.

[0120] Example 2: Refer to the attached Figure 2 This embodiment proposes a method for integrating a low-code platform with Wasm high-performance computing, which includes the following steps:

[0121] S1. Build a metadata structure for each Wasm module, including identification information that can be recognized by the low-code platform, functional description, and attribute configuration required for visual editing, forming a standardized description file to support low-code platform review and analysis. To achieve this, perform the following operations:

[0122] S1.1. Developers use compiled languages ​​(such as Rust / C++) to implement the Wasm module business logic and export the function names and parameter structures that need to be exposed.

[0123] S1.2. Based on the exported Wasm module information, a standardized description file in JSON or YAML format is automatically generated to implement the structured definition of Wasm module metadata, input parameters, return structure, permission configuration, and low-code platform UI adaptation; the metadata includes three fields: module name moduleName, module unique identifier moduleId, and module version number version; the input parameters include three core attributes: type, default value, and binding method; the permission configuration includes three fields: memory limit memoryLimit, thread support threading, and network access permission network;

[0124] S1.3. Automatically verify the legitimacy of standardized description files through the predefined description file schema verification rules of the low-code platform to ensure that they meet the constraints of parameter non-conflict and field completeness;

[0125] S1.4. After the Wasm module is registered, the description file metadata is automatically extracted and stored in the module management center of the low-code platform, generating a visual drag-and-drop component template to support plug-and-play in the low-code development environment.

[0126] S2. Implement on-demand dynamic loading of Wasm modules, combining caching mechanisms and version verification strategies to optimize loading efficiency; perform asynchronous compilation through the front-end Wasm compiler, support runtime module hot replacement, and improve resource utilization and responsiveness of the low-code platform. To achieve this, perform the following operations:

[0127] S2.1. Listen for designer component drag events, automatically parse the metadata of the Wasm module description file, extract the module's unique identifier, moduleId, trigger the Wasm module loading process, and achieve seamless integration between user operations and system responses.

[0128] S2.2. Verify the validity of the locally cached Wasm module and determine whether it needs to be reloaded based on the module's unique identifier moduleId and module version number version. If the cache is invalid, the loading process is triggered to ensure version consistency and loading efficiency of the Wasm module.

[0129] S2.3. Implement non-blocking loading and compilation of Wasm modules in Web Workers through the fetch API combined with WebAssembly.compileStreaming(), supporting resource sharding and parallel processing to avoid main thread blocking.

[0130] S2.4. Stores compiled Wasm module instances and compiled modules, marking them as "Ready" to support fast retrieval and reuse, avoiding repeated compilation overhead and optimizing memory resource management.

[0131] S2.5. Monitor Wasm module version change notifications, support one-click hot update function, ensure real-time update of Wasm module code through preloading mechanism, be compatible with grayscale release and rollback strategies, and ensure the system's dynamic update capability.

[0132] S3. Based on the permission configuration in the description file, a permission sandbox is built for the Wasm module to implement fine-grained resource access control. Through the independent sandbox isolation mechanism, illegal operations, memory leaks, and mutual interference between different Wasm modules are prevented, ensuring runtime security and stability. To achieve this, perform the following operations:

[0133] S3.1. Verify the legitimacy of permission declarations in the Wasm module description file to ensure that permission fields are declared according to specifications and to avoid security risks caused by undeclared permissions.

[0134] S3.2. Based on the WebAssembly System Interface (WASI) or a custom runner, fine-grained control is provided over system resource access for Wasm modules to implement the principle of minimum privileges.

[0135] S3.3. Leverage the browser's native WebAssembly.Memory (WebAssembly memory object, used to manage linear memory space), SharedArrayBuffer (shared array buffer, allowing multi-threaded shared memory area), and postMessage (send message, the browser's cross-context communication API) technologies to achieve thread isolation and controlled data exchange between different Wasm modules, preventing out-of-bounds memory access and thread resource contention.

[0136] S3.4. Before the Wasm module runs, create an independent sandbox context based on iframe or WebWorker to ensure that the Wasm module operation is restricted to an isolated environment;

[0137] S3.5. Set the Wasm module running timeout mechanism and exception capture callback to monitor dead loops and memory leaks in real time, triggering automatic resource recovery and error isolation.

[0138] S4. Encapsulate a unified execution interface for Wasm modules, supporting variable binding, automatic type conversion, and call scheduling in a visual interface; and implement standardized parameter interaction and data transmission between the low-code platform and the Wasm module through a secure bridging mechanism. To achieve this, perform the following operations:

[0139] S4.1. Automatically generate a visual configuration interface (such as input box, drop-down box, JSON editor, etc.) based on the Wasm module description file to implement graphical configuration of Wasm module parameters.

[0140] S4.2. Users map low-code platform variables to Wasm module input parameters by dragging or binding, establishing an association between front-end variables and module interfaces.

[0141] S4.3. Before the Wasm module runs, the low-code platform's preprocessor automatically converts JavaScript values ​​into the memory structure required by the Wasm module to ensure parameter format compatibility;

[0142] S4.4. Provide a standardized call interface executeWasm(moduleId, input), which encapsulates Wasm module instantiation, parameter passing, and exception handling logic, and implements one-click triggering of Wasm module execution.

[0143] S4.5. Parse the memory pointer value returned by the Wasm module and convert the linear memory data into JavaScript raw data (such as image buffer and structured JSON) for front-end processing.

[0144] S5. Encapsulate registered Wasm modules into draggable visual components, integrating status tracking, exception handling, and debugging functions; provide full lifecycle management capabilities to achieve visual configuration and runtime observability of visual components in a low-code environment.

[0145] S5.1. Encapsulate the registered Wasm module as a visual component, automatically generate independent icons, color identifiers, and data binding interfaces, and implement graphical abstraction of the Wasm module.

[0146] S5.2. Visual components support lifecycle hook configurations such as onInit, onExecute, onError, and onDestroy, allowing users to customize the response logic at each stage and enhancing the controllability of visual component behavior.

[0147] S5.3. Implement line interactions between visual components in flowcharts or page construction, and build visual data flow links by receiving upstream output and passing it downstream;

[0148] S5.4. Provide a visual debugging window to display the visual component's running log, output data structure, and execution time in real time, improving the observability of the visual component's running status;

[0149] S5.5. When the Wasm module is updated or an exception occurs, a visual component replacement notification is triggered. The hot update interface call and UI refresh are used to ensure that the visual component status is synchronized with the Wasm module version.

[0150] In summary, the low-code platform and Wasm high-performance computing integration system and method of the present invention lowers the development threshold by standardizing the Wasm module registration process, improves execution efficiency by using the WASM runtime, and ensures system security by combining double-layer sandbox isolation. Ultimately, the low-code platform is given the business expansion capability with high scalability, high-performance computing capabilities and production-level security standards, solving the core problems of existing low-code platforms such as limited computing performance, poor security isolation, and high module access costs.

[0151] The above specific examples are used to illustrate the principles and implementation methods of the present invention in detail. These examples are only used to help understand the core technical content of the present invention. Based on the above specific embodiments of the present invention, any improvements and modifications made by those skilled in the art without departing from the principles of the present invention should fall within the scope of patent protection of the present invention.

Claims

1. A low-code platform and Wasm high-performance computing integrated system, characterized by: Its structure includes: Wasm description and registration module, used to establish a metadata structure for each Wasm module that can be identified, reviewed, and visually edited by the low-code platform; Dynamic loading and asynchronous compilation modules are used to implement on-demand loading and runtime compilation of Wasm modules. They support caching, version verification, and hot replacement of Wasm modules. Through asynchronous execution of the front-end Wasm compiler, they improve the resource utilization efficiency and response performance of the low-code platform. The permission sandbox and resource isolation module is used to build a secure operating environment for Wasm modules. It implements fine-grained resource access control based on the permission configuration in the description file. It prevents illegal operations, memory leaks, and mutual interference between different Wasm modules through an independent sandbox isolation mechanism, ensuring the security and stability of the low-code platform during operation. The parameter binding and security bridging module is used to encapsulate a unified execution interface for Wasm modules, supporting variable binding, automatic type conversion, and call scheduling in a visual interface, thus achieving standardized interaction between the low-code platform and Wasm modules. The encapsulation and lifecycle management module is used to encapsulate registered Wasm modules into visual drag-and-drop components, supporting full lifecycle management, state tracking, exception handling, and debugging enhancements, enabling visual configuration and observability of high-performance logic components in a low-code environment.

2. A low-code platform and Wasm high-performance computing integrated system according to claim 1, characterized in that: The Wasm description and registration module specifically includes: The compilation and export unit is used to support developers to implement Wasm module business logic using compiled languages ​​and export function names and parameter structures that need to be exposed externally; A description file generation unit is used to automatically generate a standardized description file in JSON or YAML format based on the exported Wasm module information, to implement structured definition of Wasm module metadata, input parameters, return structure, permission configuration, and low-code platform UI adaptation; metadata includes moduleName, moduleId, and version fields; input parameters include type, default value, and binding method; permission configuration includes memoryLimit, threading, and network fields; The legality verification unit is used to automatically verify the legality of the standardized description file through the description file schema verification rules predefined by the low-code platform to ensure that it meets the constraints of parameter non-conflict and field completeness; The component template generation unit is used to automatically extract the description file metadata and store it in the module management center of the low-code platform after the Wasm module is registered, generate a visual drag-and-drop component template, and support plug-and-play in the low-code development environment.

3. A low-code platform and Wasm high-performance computing integrated system according to claim 2, characterized in that: The dynamic loading and asynchronous compilation module specifically includes: The parsing trigger unit is used to monitor the drag event of the designer component, automatically parse the metadata of the Wasm module description file and extract the moduleId, trigger the Wasm module loading process, and achieve seamless connection between user operation and system response; The verification and judgment unit is used to verify the validity of the locally cached Wasm module and determine whether it needs to be reloaded based on the moduleId and version. If the cache is invalid, the loading process is triggered to ensure the version consistency and loading efficiency of the Wasm module; Load compilation units, which are used to implement non-blocking loading and compilation of Wasm modules in WebWorker through the fetch API combined with WebAssembly.compileStreaming(), supporting resource sharding and parallel processing to avoid main thread blocking; Instance storage unit, used to store compiled Wasm module instances and compiled modules, mark status, support fast retrieval and reuse, avoid repeated compilation overhead, and optimize memory resource management; The monitoring update unit is used to monitor Wasm module version change notifications, supports one-click hot update function, ensures real-time update of Wasm module code through preloading mechanism, is compatible with grayscale release and rollback strategies, and ensures the system's dynamic update capability.

4. A low-code platform and Wasm high-performance computing integrated system according to claim 2, characterized in that: The permission sandbox and resource isolation module specifically includes: The permission declaration verification unit is used to verify the legitimacy of the permission declaration in the Wasm module description file, ensuring that the permission field is declared according to the specification and avoiding security risks caused by undeclared permissions; WASI permission control unit, which is used to implement fine-grained control of system resource access for Wasm modules based on the WebAssembly System Interface or a custom runner, to implement the principle of minimum permissions. The thread data isolation unit is used to use the browser's native WebAssembly.Memory, SharedArrayBuffer, and postMessage technologies to achieve thread isolation and controlled data exchange between different Wasm modules, preventing memory out-of-bounds access and thread resource contention; The sandbox environment creation unit is used to create an independent sandbox context before the Wasm module runs, ensuring that the Wasm module operation is restricted to an isolated environment; The runtime monitoring unit is used to set the Wasm module operation timeout mechanism and exception capture callback, monitor dead loops and memory leaks in real time, and trigger automatic resource recovery and error isolation.

5. A low-code platform and Wasm high-performance computing integrated system according to claim 4, characterized in that: The parameter binding and security bridging module specifically includes: Configuration UI generation unit, used to automatically generate a visual configuration interface based on the Wasm module description file, and implement graphical configuration of Wasm module parameters; The variable mapping unit is used to support users to map low-code platform variables to Wasm module input parameters through dragging or binding operations, and establish an association between front-end variables and module interfaces; The type conversion unit is used to automatically convert JavaScript values ​​into the memory structure required by the Wasm module through the low-code platform's preprocessor before the Wasm module runs, ensuring parameter format compatibility; The unified calling interface unit is used to provide a standardized calling interface, encapsulate Wasm module instantiation, parameter passing, and exception handling logic, and implement one-click triggering of Wasm modules. The result parsing unit is used to parse the memory pointer value returned by the Wasm module and convert the linear memory data into JavaScript raw data for easy front-end processing.

6. A low-code platform and Wasm high-performance computing integrated system according to claim 5, characterized in that: The packaging and lifecycle management module specifically includes: The visualization generation unit is used to encapsulate the registered Wasm modules into visualization components, automatically generate independent icons, color identifiers and data binding interfaces, and realize the graphical abstraction of Wasm modules; The lifecycle hook configuration unit is used to support the lifecycle hook configuration of visual components, allowing users to customize the response logic of each stage and enhance the controllability of visual component behavior; The line interaction unit is used to realize the line interaction between visual components in the flowchart or page construction, supports receiving upstream output and passing it to downstream, and builds a visual data flow link; The visualization display unit is used to provide a visual debugging window, display the visual component operation log, output data structure and execution time in real time, and improve the observability of the visual component operation status; The update notification unit is used to trigger the visual component replacement notification when the Wasm module is updated or abnormal. It supports hot update interface calls and UI refresh to ensure that the visual component status is synchronized with the Wasm module version.

7. A method for integrating a low-code platform with Wasm high-performance computing, characterized in that: The steps include: S1. Build a metadata structure for each Wasm module, including identification information that can be recognized by the low-code platform, functional description, and attribute configuration required for visual editing, forming a standardized description file to support low-code platform review and analysis; S2. Implement on-demand dynamic loading of Wasm modules, and optimize loading efficiency by combining caching mechanism and version verification strategy; Asynchronous compilation is performed through the front-end Wasm compiler, which supports hot module replacement at runtime and improves resource utilization and responsiveness of the low-code platform. S3. Based on the permission configuration in the description file, build the permission sandbox of the Wasm module and implement fine-grained resource access control; Through the independent sandbox isolation mechanism, illegal operations, memory leaks and mutual interference between different Wasm modules are prevented, ensuring safe and stable runtime; S4. Encapsulates a unified execution interface for Wasm modules, supporting variable binding, automatic type conversion, and call scheduling in a visual interface; and implements standardized parameter interaction and data transmission between the low-code platform and the Wasm module through a secure bridging mechanism. S5. Encapsulate registered Wasm modules into draggable visual components, integrating status tracking, exception handling, and debugging functions; provide full lifecycle management capabilities to achieve visual configuration and runtime observability of visual components in a low-code environment.

8. A method for integrating a low-code platform with Wasm high-performance computing according to claim 7, characterized in that: The step S1 specifically includes: S1.

1. Developers use compiled languages ​​to implement Wasm module business logic and export function names and parameter structures that need to be exposed externally. S1.

2. Based on the exported Wasm module information, a standardized description file in JSON or YAML format is automatically generated to implement the structured definition of Wasm module metadata, input parameters, return structure, permission configuration, and low-code platform UI adaptation; metadata includes moduleName, moduleId, and version fields; input parameters include type, default value, and binding method; permission configuration includes memoryLimit, threading, and network fields; S1.

3. Automatically verify the legitimacy of standardized description files through the predefined description file schema verification rules of the low-code platform to ensure that they meet the constraints of parameter non-conflict and field completeness; S1.

4. After the Wasm module is registered, the description file metadata is automatically extracted and stored in the module management center of the low-code platform, generating a visual drag-and-drop component template to support plug-and-play in the low-code development environment.

9. A method for integrating a low-code platform with Wasm high-performance computing according to claim 7, characterized in that: The step S2 specifically includes: S2.

1. Listen for designer component drag events, automatically parse the metadata of the Wasm module description file and extract the moduleId, triggering the Wasm module loading process to achieve seamless connection between user operations and system responses; S2.

2. Verify the validity of the locally cached Wasm module and determine whether it needs to be reloaded based on the moduleId and version. If the cache is invalid, the loading process is triggered to ensure the version consistency and loading efficiency of the Wasm module. S2.

3. Implement non-blocking loading and compilation of Wasm modules in Web Workers through the fetch API combined with WebAssembly.compileStreaming(), supporting resource sharding and parallel processing to avoid main thread blocking. S2.

4. Store compiled Wasm module instances and compiled modules, mark their status, support fast retrieval and reuse, avoid repeated compilation overhead, and optimize memory resource management; S2.

5. Monitor Wasm module version change notifications, support one-click hot update function, ensure real-time update of Wasm module code through preloading mechanism, be compatible with grayscale release and rollback strategies, and ensure the system's dynamic update capability; The step S3 specifically includes: S3.

1. Verify the legitimacy of permission declarations in the Wasm module description file to ensure that permission fields are declared according to specifications and to avoid security risks caused by undeclared permissions. S3.

2. Based on the WebAssembly System Interface or a custom runner, fine-grained control is provided over the system resource access of the Wasm module to implement the principle of minimum privileges. S3.

3. Utilize the browser's native WebAssembly.Memory, SharedArrayBuffer, and postMessage technologies to achieve thread isolation and controlled data exchange between different Wasm modules, preventing out-of-bounds memory access and thread resource contention. S3.

4. Create an independent sandbox context before the Wasm module runs to ensure that the Wasm module operation is restricted to an isolated environment; S3.

5. Set the Wasm module running timeout mechanism and exception capture callback to monitor dead loops and memory leaks in real time, triggering automatic resource recovery and error isolation.

10. A method for integrating a low-code platform with Wasm high-performance computing according to claim 9, characterized in that: The step S4 specifically includes: S4.

1. Automatically generate a visual configuration interface based on the Wasm module description file to implement graphical configuration of Wasm module parameters. S4.

2. Users map low-code platform variables to Wasm module input parameters by dragging or binding, establishing an association between front-end variables and module interfaces. S4.

3. Before the Wasm module runs, the low-code platform's preprocessor automatically converts JavaScript values ​​into the memory structure required by the Wasm module to ensure parameter format compatibility; S4.

4. Provide a standardized calling interface, encapsulate Wasm module instantiation, parameter passing, and exception handling logic, and implement one-click triggering of Wasm modules; S4.

5. Parse the memory pointer value returned by the Wasm module and convert the linear memory data into JavaScript raw data for easy front-end processing. The step S5 specifically includes: S5.

1. Encapsulate the registered Wasm module as a visual component, automatically generate independent icons, color identifiers, and data binding interfaces, and implement graphical abstraction of the Wasm module. S5.

2. Visual components support lifecycle hook configuration, allowing users to customize the response logic at each stage and enhance the controllability of visual component behavior; S5.

3. Implement line interactions between visual components in flowcharts or page construction, and build visual data flow links by receiving upstream output and passing it downstream; S5.

4. Provide a visual debugging window to display the visual component's running log, output data structure, and execution time in real time, improving the observability of the visual component's running status; S5.

5. When the Wasm module is updated or an exception occurs, a visual component replacement notification is triggered. The hot update interface call and UI refresh are used to ensure that the visual component status is synchronized with the Wasm module version.

Images