Codeless online plug-in development and publishing method and system, computer device, computer readable storage medium
By interacting with the open platform and Node.js services, online development and deployment of plugins are achieved, solving the problem of low efficiency in secondary plugin development in existing technologies, improving development efficiency and quality, and promoting collaborative development among enterprises.
Patent Information
- Authority / Receiving Office
- CN · China
- Patent Type
- Patents(China)
- Current Assignee / Owner
- 江苏数睿数据科技有限公司
- Filing Date
- 2025-12-12
- Publication Date
- 2026-04-21
AI Technical Summary
The secondary development of existing plugins relies on the local environment, which is cumbersome to configure, has scattered version management, and a lengthy testing and deployment chain, which reduces development efficiency and collaboration flexibility, and makes it difficult to guarantee development quality.
Plugins are packaged and uploaded through an open platform to generate a source code directory tree, enabling online development and debugging. The WebSocket protocol is used to interact with Node.js services, building an integrated development environment and integrating a continuous integration toolchain to support real-time online development, debugging, and deployment of plugins.
It significantly improves plugin development efficiency, lowers the development threshold, ensures development quality and system stability, promotes deep collaboration between enterprise technical teams and business departments, and builds an open and win-win plugin ecosystem.
Smart Images

Figure CN121300752B_ABST
Abstract
Description
Technical Field
[0001] This application relates to the field of plug-in development technology, and in particular to a no-code online plug-in development and distribution method and system, computer device, and computer-readable storage medium. Background Technology
[0002] With the acceleration of enterprise digital transformation, a thriving plugin ecosystem based on existing business systems for secondary development has emerged. Currently, plugin secondary development primarily relies on local development environments. However, local development environments suffer from cumbersome configuration, fragmented code version management, and lengthy testing and deployment processes. Writing source code in a local editor, manually packaging the plugin, and then uploading the artifacts to the corresponding server for deployment creates a lengthy process. Enabling local online debugging requires uploading a local debug package, preventing other users from using the function and causing downtime, significantly reducing development efficiency and collaboration flexibility. Furthermore, the cumbersome local development process and frequent manual package switching increase development complexity, making it difficult to guarantee consistent development and packaging script quality, thus reducing collaborative development flexibility—a contradiction of the core principle of no-code configuration platforms: lowering the development barrier. Summary of the Invention
[0003] This application aims to provide a no-code online plugin development and publishing method and system, computer equipment, and computer-readable storage medium, which lowers the development threshold, ensures development quality, and improves development efficiency and flexibility.
[0004] To achieve the above objectives, the technical solution of this application is as follows:
[0005] A no-code online plugin development and deployment method, including:
[0006] Package the plugin and upload it to the open platform, including the plugin source code compressed file in the package;
[0007] After initializing the plugin source code, continuously output execution logs and generate a source code directory tree;
[0008] Perform joint debugging and testing on the open platform environment to ensure joint debugging and real-time status feedback. Obtain the plugin source code according to the source code directory tree, modify the entry path field maintained in the plugin information table to the current configured service address, and complete the online development and startup of the plugin.
[0009] The plugin can be developed and debugged online in real time on the open platform. A new directory tree and hot-updated real-time artifacts are generated based on the modified source code and file paths to achieve online development.
[0010] Restore the plugin's entry path field to the online address to complete the plugin's online development and close it;
[0011] Package the plugin on the open platform, call the plugin upload interface to handle the plugin deployment logic and source code updates in the plugin production environment, and complete the plugin packaging and release;
[0012] This involves modifying the entry path field maintained in the plugin information table to the currently configured service address to complete the online development startup of the plugin, including:
[0013] The open platform sends a message to the Node service via the WebSocket protocol to start online plugin development. The Node service starts a sub-thread to execute the command to install dependencies in the target plugin source code directory. After the dependencies are installed, the plugin development service is started to perform development and integration testing on the packaged plugin.
[0014] The Node service obtains the plugin development service address, calls the Java service interface, and uses the Java service to modify the entry path field value maintained in the information table of the packaged plugin on the Node service to the obtained plugin development service port address; the Node service runs in a sandbox environment.
[0015] After successfully modifying the entry path field value, the Java service returns a message indicating successful modification to the Node service, and the Node service completes the online plugin development and startup.
[0016] After the Node service completes the online plugin development and starts, it returns information about the completion of the online plugin development and starts to the open platform via the WebSocket protocol. After the open platform refreshes, it enters the business requirement development stage.
[0017] Optionally, after initializing the plugin source code, the execution log is continuously output to generate the source code directory tree, specifically including: steps S21 to S26;
[0018] Step S21: Visually edit the packaged plugin using the online editing interface of the open platform. Establish a connection between the open platform and the Node service via the WebSocket protocol and send the initialization parameters of the packaged plugin to the Node service. The initialization parameters include: plugin ID, source code compressed package address, and packaging timestamp.
[0019] Step S22: After the WebSocket protocol connection is successfully established, the execution logs of the Node service are continuously and dynamically displayed on the control interface based on the open platform.
[0020] Step S23: The Node service receives the initialization parameters of the packaged plugin and determines whether the packaged plugin exists in the source code folder of the Node service based on the initialization parameters of the packaged plugin. If not, proceed to step S24; if yes, proceed to step S25.
[0021] Step S24: The Node service calls the plugin source code compressed package from the distributed source code storage of the Node service, generates the corresponding source code folder in the Node service according to the initialization parameters of the packaged plugin, and proceeds to step S25.
[0022] Step S25: Generate a source code directory tree based on the source code folder;
[0023] Step S26: The node service sends feedback to the open platform via the websocket protocol that the plugin initialization is complete, and the source code directory tree is loaded on the open platform.
[0024] Optionally, the Node service retrieves the plugin source code archive from the distributed source code storage and generates a corresponding source code folder in the Node service based on the initialization parameters of the packaged plugin. This folder includes:
[0025] Based on the source code compressed package address, the Node service retrieves the plugin source code compressed package from the distributed source code storage of the Node service and decompresses the source code compressed package to the source code folder of the Node service;
[0026] Generate the corresponding source code folder in the source code folder of the Node service based on the plugin ID.
[0027] Optionally, obtain the plugin source code based on the source code directory tree, including:
[0028] Select the target directory tree file in the source code directory tree of the open platform;
[0029] The open platform requests the corresponding target static resource file from the Node static resource server based on the selected target directory tree file path; where the Node static resource server is specified as the source code folder mapped to the Node service, and the target static resource file is the source code of the target plugin;
[0030] The node service returns the target static resource file to the open platform.
[0031] Optionally, plugins can be developed and debugged online in real time on the open platform. A new directory tree and real-time hot-update artifacts can be generated based on the modified source code and file paths, enabling online development, including:
[0032] Modify the plugin source code and source code directory tree online on the open platform, and send the modified plugin source code and its file path to the node service via the WebSocket protocol.
[0033] In an independent sandbox environment, the Node service modifies the target files in the Node service's source code folder based on the content and file path of the modified plugin source code, and automatically generates a new source code directory tree based on the modified Node service's source code folder.
[0034] The Node service returns a new source code directory tree to the open platform via the WebSocket protocol. The open platform then refreshes the source code directory tree in the online editing interface based on the new source code directory tree.
[0035] The plugin development service detects an update to the source code folder of the node service and triggers the hot update service, returning the hot update artifacts to the open platform in the form of logs.
[0036] The open platform receives hot-update outputs that refresh the online editing interface in real time, enabling online development and obtaining the developed plugins.
[0037] Optionally, restore the plugin's entry path field to the online address, completing the plugin's online development shutdown, including:
[0038] Upon entering the online development shutdown process, the open platform sends a message to the Node service via the WebSocket protocol to shut down online development, and the Node service releases the port address occupied by the plugin development service.
[0039] The Node service calls the Java service interface to restore the entry path field value maintained in the information table of the packaged plugin on the Node service to the previous value.
[0040] After the entry path field value is restored, a message indicating successful modification is returned to the Node service. The Node service then sends a message indicating successful closure of online plugin development to the open platform via the WebSocket protocol.
[0041] Optionally, the plugin is packaged on the open platform, and the plugin upload interface is called to handle plugin deployment logic and source code updates in the plugin production environment, completing the plugin packaging and release, including:
[0042] Once the plugin release process begins, the open platform sends information about the packaged plugin to the Node service via the WebSocket protocol. The Node service executes the packaging command in an independent sandbox environment to obtain the developed plugin package.
[0043] The Node service calls the plugin upload interface of the Java service to upload the developed plugin package to the application server, performs a production environment update operation, replaces the production environment plugin artifact of the target plugin with the developed plugin package, and completes the deployment of the developed plugin package.
[0044] After the Java service completes the deployment of the developed plugin package, it returns a message indicating successful upload to the Node service. The Node service then sends the message to the open platform via the WebSocket protocol.
[0045] A no-code online plugin development and deployment system for executing the no-code online plugin development and deployment method described above, comprising: an open platform, a Node server, and a Java server, which are connected sequentially.
[0046] The open platform includes:
[0047] The receiving module is used to package and upload plugins to the open platform;
[0048] The initialization module is used to initialize the plugin source code and continuously output execution logs, generating a source code directory tree.
[0049] The integration and testing module is used to perform integration and testing on the open platform environment to ensure integration and real-time status feedback. It obtains the plugin source code based on the source code directory tree, modifies the entry path field maintained in the plugin information table to the current configured service address, and completes the online development and startup of the plugin.
[0050] The online development module is used to develop and debug plugins in real time on the open platform. It generates a new directory tree and hot-update real-time artifacts based on the modified source code and file paths, thus enabling online development.
[0051] The restore module is used to restore the plugin's entry path field to the online address, thus completing the online development and shutdown of the plugin;
[0052] The packaging and publishing module is used to package plugins on the open platform, call the plugin upload interface to handle plugin deployment logic and source code updates in the plugin production environment, and complete the packaging and publishing of the plugin.
[0053] A computer device may include a memory and a processor, the memory storing a computer program, and the processor executing the computer program to implement the steps of the above-described no-code online plug-in development and distribution method.
[0054] A computer-readable storage medium having a computer program stored thereon, which, when executed by a processor, implements the steps of the above-described no-code online plugin development and distribution method.
[0055] This application provides a no-code online plugin development and release method and system, computer equipment, and computer-readable storage medium. Responding to developers' urgent needs for agile engineering practices, it connects Node.js and Java services through an open platform to build an integrated online development environment. It pre-configures a standardized development framework, integrates a continuous integration toolchain, and establishes a seamless connection between sandbox testing and production environments. This enables a full lifecycle process from plugin development, integration testing, release, to deployment, significantly improving plugin development efficiency and allowing users to focus on business logic innovation rather than environment maintenance, freeing them from local environment constraints. Simultaneously, the system's complete verification system and the security isolation mechanism of the sandbox environment ensure the stability of the core development system, reducing the likelihood of problems, minimizing reliance on manual verification, and lowering risks. Furthermore, the open platform's visual online editing interface supports plugin configuration and development, forming an independent closed-loop plugin business logic development process. Environment standardization eliminates configuration differences, lowering the entry barrier for development. This aligns with the current trend of low-code development and effectively promotes deep collaboration between enterprise technical teams and business departments, expanding the plugin development system and accelerating the construction of an open and win-win plugin ecosystem.
[0056] To make the above-mentioned features and advantages of the application more apparent and understandable, specific embodiments are provided below, and detailed descriptions are given in conjunction with the accompanying drawings. Attached Figure Description
[0057] Figure 1 This is a flowchart illustrating the no-code online plugin development and publishing method proposed in this application.
[0058] Figure 2 A module diagram of a no-code online plugin development and publishing system provided in this application. Detailed Implementation
[0059] To make the objectives and technical solutions of the embodiments of this application clearer, the technical solutions of the embodiments of this application will be clearly and completely described below with reference to the accompanying drawings. Obviously, the described embodiments are only some, not all, of the embodiments of this application. All other embodiments obtained by those skilled in the art based on the described embodiments of this application without creative effort are within the scope of protection of this application.
[0060] Please see Figure 1 , Figure 1 This is a flowchart of the no-code online plugin development and release method proposed in this application. The no-code online plugin development and release method proposed in this application includes steps S1 to S6.
[0061] Step S1: Package the plugin and upload it to the open platform;
[0062] Step S2: After initializing the plugin source code, continuously output execution logs and generate a source code directory tree;
[0063] Step S3: Perform integration testing on the open platform environment to ensure integration testing and real-time status feedback. Obtain the plugin source code according to the source code directory tree, modify the entry path field maintained in the plugin information table to the current configured service address, and complete the online development startup of the plugin.
[0064] Step S4: Develop and debug the plugin in real time on the open platform, generate a new directory tree and hot-update real-time artifacts based on the modified source code and file paths, and realize online development;
[0065] Step S5: Restore the plugin's entry path field to the online address, and close the online plugin development.
[0066] Step S6: Package the plugin on the open platform, call the plugin upload interface to handle the plugin deployment logic and source code updates in the plugin production environment, and complete the plugin packaging and release.
[0067] This application proposes a no-code online plugin development and deployment method that responds to developers' urgent need for agile engineering practices. By connecting Node.js and Java services through an open platform, it constructs an integrated online development environment. This environment includes a pre-built standardized development framework, integrated continuous integration toolchain, and a seamless connection between sandbox testing and production environments. It achieves a full lifecycle process from plugin development, integration testing, deployment, to deployment, significantly improving plugin development efficiency. Users can break free from local environment constraints and focus on business logic innovation rather than environment maintenance. Simultaneously, the system's complete verification system and the security isolation mechanism of the sandbox environment ensure the operational stability of the core development system, reducing the likelihood of problems, decreasing reliance on manual verification, and mitigating risks. Furthermore, the open platform's visual online editing interface supports plugin configuration and development, forming an independent closed-loop plugin business logic development process. Environment standardization eliminates configuration differences, lowering the development entry barrier. This aligns with the current trend of low-code development and effectively promotes deep collaboration between enterprise technical teams and business departments, expanding the plugin development system and accelerating the construction of an open and win-win plugin ecosystem.
[0068] In step S1, please refer to Figure 1 In step S1, the plugin is packaged and uploaded to the open platform.
[0069] As an example, the open platform refers to the plugin management page, which is used to add, update, download, or manage the enabled status of plugins, such as the smadaten platform.
[0070] As an example, the open platform includes an online editing interface, a control interface, a preview interface, and a task scheduling interface, used to implement the entire lifecycle process from plugin development, integration testing, release to deployment. The interaction between the open platform and Node.js and Java services includes: visual editing of online development activities, previewing plugin page content, and task orchestration and scheduling on the open platform. The visual editing of online development activities includes: file operations, saving, applying changes, and rolling back.
[0071] Package the plugin and upload it to the open platform, specifically including steps S11 to S12.
[0072] Step S11: Modify the packaging logic of the plugin template to include the plugin source code compressed package during packaging;
[0073] Step S12: Generate plugin artifacts through the build process, package the plugin artifacts and plugin source code compressed package to obtain the packaged plugin, and upload it to the open platform.
[0074] As an example, in step S11, in the prior art, the packaging logic of the plugin template is usually only used to generate plugin artifacts that adapt to the online running environment, such as plugin packages that meet server deployment specifications. In this application, by modifying the packaging logic of the plugin template, the packaging logic of the plugin template is to compress the complete source code file of the plugin into a plugin source code compressed package while generating the plugin artifact, and package the plugin source code compressed package and the plugin artifact into a packaged plugin, which provides a foundation for the subsequent open platform to directly develop and debug based on the source code.
[0075] As an example, in step S12, the plugin artifacts include: plugin entities that can be directly loaded and run by the online application server; wherein, the online application server includes: Tomcat server.
[0076] In one specific embodiment of this application, the build process is implemented through pnpm's build script to generate plugin artifacts.
[0077] Furthermore, the packaged plugin is uploaded to the open platform. Since the open platform has different plugin types, and the plugin type was determined according to the business when packaging, you only need to select the corresponding type and upload the packaged compressed file when uploading. No other additional parameter configuration is required through the interface.
[0078] In step S2, please refer to Figure 1 In step S2, after initializing the plugin source code, execution logs are continuously output, generating a source code directory tree.
[0079] As an example, after initializing the plugin source code, the execution log is continuously output to generate the source code directory tree, specifically including steps S21 to S26.
[0080] Step S21: Visually edit the packaged plugin using the online editing interface of the open platform, establish a connection between the open platform and the node service via the websocket protocol, and send the initialization parameters of the packaged plugin to the node service;
[0081] Step S22: After the WebSocket protocol connection is successfully established, the execution logs of the Node service are continuously and dynamically displayed on the control interface based on the open platform.
[0082] Step S23: The Node service receives the initialization parameters of the packaged plugin and determines whether the packaged plugin exists in the source code folder of the Node service based on the initialization parameters of the packaged plugin. If not, proceed to step S24; if yes, proceed to step S25.
[0083] Step S24: The Node service calls the plugin source code compressed package from the distributed source code storage (git) of the Node service, generates the corresponding source code folder in the Node service according to the initialization parameters of the packaged plugin, and proceeds to step S25;
[0084] Step S25: Generate a source code directory tree based on the source code folder;
[0085] Step S26: The node service sends feedback to the open platform via the websocket protocol that the plugin initialization is complete, and the source code directory tree is loaded on the open platform.
[0086] As an example, in step S21, the service deployed and running in the Node.js runtime environment is directly connected using the WebSocket protocol. A connection is established between the open platform and the Node.js service's application programming interface (API) via the WebSocket protocol, and the initialization parameters of the packaged plugin are sent to the Node.js service. These initialization parameters include: plugin ID, source code archive address, and packaging timestamp. The source code archive address includes: the storage link of the distributed source code storage terminal and its version number.
[0087] As an example, the Node service runs in a sandbox environment. Environment isolation is used to implement a secure isolation mechanism within the sandbox environment, ensuring the stability of the core system. This environment isolation refers to an independent Node packaged interactive service.
[0088] In one specific embodiment of this application, after the user enters the online editing interface, a loading process prompt is triggered, indicating that the node service is initializing the packaged plugin in an independent sandbox environment after establishing a connection with the open platform.
[0089] As an example, in step S22, the control interface of the open platform continuously and dynamically displays the execution logs of the Node service, including: the Node service continuously and dynamically displays its execution logs to the control interface of the open platform via the WebSocket protocol. This achieves bidirectional real-time interaction between the open platform and the Node service.
[0090] As an example, in step S23, determining whether the packaged plugin exists in the source code folder of the Node.js service based on the initialization parameters of the packaged plugin includes: determining whether the packaged plugin exists in the source code folder of the Node.js service based on the plugin ID and the packaging timestamp. This dual verification using the plugin ID and packaging timestamp ensures the uniqueness and version traceability of the plugin source code, avoiding duplicate storage or version conflicts. Specifically, determining whether the packaged plugin exists in the source code folder of the Node.js service based on the plugin ID and packaging timestamp is achieved through version caching, avoiding the waste of time repeatedly fetching source code.
[0091] In one specific embodiment of this application, the source code folder of the node service is the sourceCode folder of the node service.
[0092] As an example, in step S24, the node service calls the plugin source code compressed package from the distributed source code storage terminal, and generates the corresponding source code folder in the node service according to the initialization parameters of the packaged plugin, including steps S241 to S242.
[0093] Step S241: The Node service retrieves the plugin source code compressed package from the distributed source code storage terminal of the Node service according to the source code compressed package address, and decompresses the source code compressed package to the source code folder of the Node service;
[0094] Step S242: Generate the corresponding source code folder in the source code folder of the Node service based on the plugin ID.
[0095] Specifically, the distributed source code storage of the Node service stores every modified version of the plugin source code.
[0096] As an example, in step S25, the source code compressed package is automatically retrieved and decompressed through the node service to generate a source code directory tree, thereby achieving automated plugin initialization.
[0097] As an example, in step S26, the source code directory tree is loaded on the open platform, including loading the source code directory tree in the online editing interface of the open platform.
[0098] In one specific embodiment of this application, the Node service sends feedback to the open platform via the WebSocket protocol after the plugin initialization is complete. The online editing interface then cancels the loading process prompt, loads the source code directory tree, and completes the initialization of the packaged plugin.
[0099] In step S3, please refer to Figure 1 Step S3 involves performing integration testing on the open platform environment to ensure integration and real-time status feedback. The plugin source code is obtained based on the source code directory tree. The entry path field maintained in the plugin information table is modified to the current configured service address to complete the online development and startup of the plugin.
[0100] As an example, integration testing and debugging in the open platform environment ensures real-time status feedback. This includes: In the test environment, an interactive command is input into the open platform's debugging control interface. The open platform transmits a string containing the interactive command to the Node.js service in real time via the WebSocket protocol. After receiving the command, the Node.js service parses and executes it in an independent sandbox environment. The interactive command is a shell command; the debugging control interface can be a terminal command line (cmd) interface within an online editing interface. If the interactive command cannot be parsed and executed, indicating that the integration testing is unsuccessful, the plugin source code is modified, and the modification results are automatically updated in the Node.js service.
[0101] As an example, the plugin source code is obtained from the source code directory tree, including steps S31 to S33.
[0102] Step S31: Select the target directory tree file in the source code directory tree of the open platform;
[0103] Step S32: The open platform requests the corresponding target static resource file from the node static resource server based on the selected target directory tree file path;
[0104] Step S33: The node service returns the target static resource file to the open platform.
[0105] As an example, in step S32, the Node static resource server specifies the source code folder mapped to the Node service. The target static resource file is the source code of the target plugin.
[0106] As an example, in step S33, after the node service returns the target static resource file to the open platform, it also includes: displaying the plugin source code in the online editing interface of the open platform.
[0107] As an example, after obtaining the plugin source code from the source code directory tree, online plugin development is started. Specifically, the entry path field maintained in the plugin information table is modified to the currently configured service address to complete the online plugin development startup, including steps S34 to S37.
[0108] Step S34: The open platform sends a message to the Node service to start online plugin development via the WebSocket protocol. The Node service starts a sub-thread and executes the command to install dependencies in the directory of the target plugin source code. After the dependencies are installed, the plugin development service is started to perform development and integration testing on the packaged plugin.
[0109] Step S35: The Node service obtains the plugin development service address, calls the Java service interface, and uses the Java service to modify the entry path field value maintained in the information table of the packaged plugin on the Node service to the obtained plugin development service port address.
[0110] Step S36: After successfully modifying the entry path field value, the Java service returns a message indicating successful modification to the Node service, and the Node service completes the online plugin development startup.
[0111] Step S37: After the node service completes the online plugin development startup, it returns the information of the completed online plugin development startup to the open platform through the WebSocket protocol. After the open platform refreshes, it enters the business requirement development.
[0112] As an example, in step S34, the plugin development service can be a devServer service. After the plugin development service starts, it continuously listens to the node service through the plugin development service port address, providing a hot module replacement development server instance to handle requests for development and integration testing of the packaged plugin. When the plugin source code changes, the plugin development service immediately detects the file change through its built-in file listening mechanism, and then automatically triggers the hot module replacement service, feeding back the status and other information of the packaged plugin to the open platform in real time via the WebSocket protocol, without the need for manual refresh.
[0113] As an example, in step S35, the information table of the packaged plugin is a structured data table in the plugin artifact used to centrally store the plugin's full lifecycle metadata, configuration information and status. It may include the following fields: plugin id, plugin name, entry path field, storage link of the distributed source code storage terminal, version number, packaging timestamp and plugin status, etc.; among which, the entry path field is coded as main_path, which is the entry path when the plugin runs.
[0114] Furthermore, the entry path field value pointing to the online address is modified to the obtained plugin development service port address. For example, the plugin's Tomcat deployment address is modified to the plugin development service port address http: / / localhost:3000. The modification of the entry path field value only takes effect during the development process and does not affect the online formal use, thereby achieving isolation between the Node service sandbox environment and the production environment.
[0115] In step S4, please refer to Figure 1 The S4 step involves real-time online development and debugging of plugins on the open platform, generating a new directory tree and hot-updating artifacts based on the modified source code and file paths, thus achieving online development.
[0116] As an example, the plugin is developed and debugged online in real time on the open platform. A new directory tree and hot update real-time artifacts are generated based on the modified source code and file path to realize online development, including steps S41 to S45.
[0117] Step S41: Modify the plugin source code and source code directory tree online on the open platform, and send the modified plugin source code and its file path to the node service via the websocket protocol;
[0118] Step S42: In an independent sandbox environment, the Node service modifies the target files in the source code folder of the Node service according to the content and file path of the modified plugin source code, and automatically generates a new source code directory tree based on the modified source code folder of the Node service.
[0119] Step S43: The node service returns the new source code directory tree to the open platform via the websocket protocol. The open platform refreshes the source code directory tree of the online editing interface based on the new source code directory tree.
[0120] Step S44: The plugin development service detects an update to the source code folder of the node service, triggers the hot update service, and returns the hot update artifacts to the open platform in the form of logs;
[0121] Step S45: The open platform receives hot-update real-time outputs to refresh the online editing interface, enabling online development and obtaining the developed plugin.
[0122] As an example, in step S41, the plugin source code and source code directory tree are modified, including file operations such as adding files, editing content, and deleting files. After modifying the plugin source code and source code directory tree, the modified plugin source code content and the file path of the plugin source code are generated.
[0123] As an example, in step S42, the node service modifies the target file in the source code folder of the node service in an independent sandbox environment according to the content of the modified plugin source code and the file path of the plugin source code, including steps S421 to S422.
[0124] Step S421: The Node service locates the target file in the Node service's source code folder based on the modified plugin source code file path;
[0125] Step S422: The node service dynamically modifies the target file based on the modified plugin source code.
[0126] As an example, in step S44, the Node service, in an independent sandbox environment, modifies the target files in the Node service's source code folder based on the content and file path of the modified plugin source code. Simultaneously, the plugin development service detects the update to the Node service's source code folder, triggering the hot update service and returning the real-time hot update artifacts to the open platform in log form. The hot update service includes: monitoring code changes, generating real-time hot update artifacts, and providing a real-time preview of the plugin modifications.
[0127] As an example, in step S45, after the open platform receives the hot update real-time output and refreshes the online editing interface, the modifications to the plugin source code and source code directory tree take effect, thus realizing online development.
[0128] In step S5, please refer to Figure 1 Step S5 restores the plugin's entry path field to the online address, completing the plugin's online development and closing.
[0129] As an example, the plugin's entry path field is restored to the online address to complete the plugin's online development shutdown, including steps S51 to S53.
[0130] Step S51: Enter the online development shutdown process. The open platform sends a message to the Node service to shut down online development via the WebSocket protocol. The Node service releases the port address occupied by the plugin development service.
[0131] Step S52: The Node service calls the Java service interface to restore the entry path field value maintained in the information table of the packaged plugin on the Node service to the previous value;
[0132] Step S53: After the entry path field value is restored, a message indicating successful modification is returned to the node service. The node service then sends a message indicating successful closure of online plugin development to the open platform via the WebSocket protocol.
[0133] As an example, in step S52, the entry path field value maintained in the information table of the packaged plugin on the node service is restored to the previous value. For example, the entry path field value pointing to the plugin development service port address http: / / localhost:3000 is restored to the plugin's Tomcat deployment address.
[0134] In one specific embodiment of this application, after the open platform receives the information that the online development of the plugin has been successfully closed, the control interface of the open platform updates the log and pops up a notification to the user that the online development has been successfully closed.
[0135] In step S6, please refer to Figure 1 In step S6, the plugin is packaged on the open platform, and the plugin upload interface is called to handle the plugin deployment logic and source code updates in the plugin production environment, thus completing the plugin packaging and release.
[0136] As an example, the plugin is packaged on the open platform, and the plugin upload interface is called to handle the plugin deployment logic and the source code update of the plugin production environment, and the plugin packaging and release is completed, including steps S61 to S63.
[0137] Step S61: Enter the plugin release process. The open platform sends the information of the packaged plugin to the Node service through the WebSocket protocol. The Node service executes the packaging command in an independent sandbox environment to obtain the developed plugin package.
[0138] Step S62: The Node service calls the plugin upload interface of the Java service to upload the developed plugin package to the application server, performs a production environment update operation, replaces the production environment plugin artifact of the target plugin with the developed plugin package, and completes the deployment of the developed plugin package.
[0139] Step S63: After the Java service completes the deployment of the developed plugin package, it returns a message indicating successful upload to the Node service. The Node service then sends the message indicating successful upload of the developed plugin package to the open platform via the WebSocket protocol.
[0140] As an example, in step S61, the executed packaging commands include: predefined standardized plugin packaging commands, such as `npm run build`, or custom packaging logic. The developed plugin package includes: plugin artifacts generated through the build process and plugin package parameters. The developed plugin package can be a ZIP format compressed file; the plugin package parameters include: plugin ID, source code compressed file address, and packaging timestamp.
[0141] As an example, in step S62, the Node service calls the plugin upload interface of the Java service to upload the developed plugin package to the application server. This includes: using the entry path field in the developed plugin package, the plugin upload interface of the Java service is used to achieve data connection, and the developed plugin package is uploaded to the application server.
[0142] In one specific embodiment of this application, after the open platform receives the information that the developed plugin package has been successfully uploaded, the control interface of the open platform updates the log and pops up a notification to the user that the developed plugin package has been successfully uploaded.
[0143] As another example, after packaging the plugin on the open platform, calling the plugin upload interface to handle plugin deployment logic and source code updates in the plugin production environment, and completing the plugin packaging and release, the process also includes:
[0144] Step S7: The open platform closes the online editing interface and disconnects the websocket protocol connection with the node service.
[0145] This application also provides a no-code online plugin development and deployment system for executing the aforementioned no-code online plugin development and deployment method. Please refer to [link to relevant documentation]. Figure 2 , Figure 2 The module diagram of a no-code online plugin development and deployment system provided in this application includes: an open platform 21, a node server 22, and a Java server 23, which are connected in sequence.
[0146] As an example, the open platform 21 is used to implement the entire lifecycle process from plugin development, integration testing, release to deployment and launch; the node server 22 is used to deploy node services, receive and process requests from the open platform 21; the Java server 23 is used to deploy Java services, and collaborates with the open platform 21 to handle plugin release and deployment through the node services.
[0147] As an example, Open Platform 21 includes:
[0148] The receiving module 211 is used to package and upload plugins to the open platform 21;
[0149] Initialization module 212 is used to continuously output execution logs and generate source code directory tree after initializing the plugin source code;
[0150] The integration and testing module 213 is used to perform integration and testing on the open platform 21 environment to ensure integration and real-time status feedback. It obtains the plugin source code according to the source code directory tree, modifies the entry path field maintained in the plugin information table to the current configured service address, and completes the online development and startup of the plugin.
[0151] The online development module 214 is used to perform real-time online development and debugging of plugins on the open platform 21. It generates a new directory tree and hot-updating real-time artifacts based on the modified source code and file paths, thus realizing online development.
[0152] The restore module 215 is used to restore the plugin's entry path field to the online address, thus completing the online development and closing of the plugin.
[0153] The packaging and publishing module 216 is used to package plugins on the open platform 21, call the plugin upload interface to handle plugin deployment logic and source code updates in the plugin production environment, and complete the packaging and publishing of plugins.
[0154] As another example, Open Platform 21 also includes a shutdown module for closing the online editing interface and disconnecting the WebSocket protocol connection to the Node service. Figure 2 (not shown in the image)
[0155] This application responds to developers' urgent need for agile engineering practices. By connecting Node.js and Java services through an open platform, it constructs an integrated online development environment. It pre-configures a standardized development framework, integrates a continuous integration toolchain, and bridges the gap between sandbox testing and production environments. This enables a full lifecycle workflow from plugin development, integration testing, release, to deployment, significantly improving plugin development efficiency. Users can break free from local environment constraints and focus on business logic innovation rather than environment maintenance. Simultaneously, the system's complete verification system and the security isolation mechanism of the sandbox environment ensure the stability of the core development system, reducing the likelihood of problems, minimizing reliance on manual verification, and lowering risks. Furthermore, the open platform's visual online editing interface supports plugin configuration and development, forming an independent closed-loop plugin business logic development process. Environment standardization eliminates configuration differences, lowering the entry barrier for development. This aligns with the current trend of low-code development and effectively promotes deep collaboration between enterprise technical teams and business departments, expanding the plugin development system and accelerating the construction of an open and win-win plugin ecosystem.
[0156] This application also provides a computer device, which may include a memory and a processor. The memory stores a computer program, and the processor executes the computer program to implement the steps of the above-described no-code online plug-in development and release method.
[0157] As an example, the computer device can be a server, including a processor, memory, network interface, and database connected via a system bus. The processor provides computing and control capabilities. The memory includes non-volatile storage media and internal memory. The non-volatile storage media stores the operating system, computer programs, and database. The internal memory provides an environment for the operation of the operating system and computer programs in the non-volatile storage media. The database stores data such as region parameters and deployment strategies. The network interface communicates with external terminals via a network connection. When the computer program is executed by the processor, it implements the no-code online plug-in development and release method described in the above embodiments.
[0158] This application also provides a computer-readable storage medium storing a computer program thereon, which, when executed by a processor, implements the steps of the no-code online plug-in development and release method in the above embodiments.
[0159] Those skilled in the art will understand that all or part of the processes in the methods of the above embodiments can be implemented by a computer program instructing related hardware. The computer program can be stored in a non-volatile computer-readable storage medium. When executed, the computer program can include the processes of the embodiments of the above methods. Any references to memory, storage, databases, or other media used in the embodiments provided by this invention can include non-volatile and / or volatile memory. Non-volatile memory can include read-only memory (ROM), programmable ROM (PROM), electrically programmable ROM (EPROM), electrically erasable programmable ROM (EEPROM), or flash memory. Volatile memory can include random access memory (RAM) or external cache memory. By way of illustration and not limitation, RAM is available in various forms, such as static RAM (SRAM), dynamic RAM (DRAM), synchronous DRAM (SDRAM), dual data rate SDRAM (DDRSDRAM), enhanced SDRAM (ESDRAM), synchronous link DRAM (SLDRAM), Rambus direct RAM (RDRAM), direct memory bus dynamic RAM (DRDRAM), and memory bus dynamic RAM (RDRAM), etc.
[0160] Although this application has been disclosed above with reference to embodiments, it is not intended to limit this application. Anyone skilled in the art may make some modifications and refinements without departing from the spirit and scope of this application. Therefore, the scope of protection of this application shall be determined by the appended claims.
Claims
1. A no-code online plugin development and deployment method, characterized in that, include, Package the plugin and upload it to the open platform, including the plugin source code compressed file in the package; After initializing the plugin source code, continuously output execution logs and generate a source code directory tree; Perform joint debugging and testing on the open platform environment to ensure joint debugging and real-time status feedback. Obtain the plugin source code according to the source code directory tree, modify the entry path field maintained in the plugin information table to the current configured service address, and complete the online development and startup of the plugin. The plugin can be developed and debugged online in real time on the open platform. A new directory tree and hot-updated real-time artifacts are generated based on the modified source code and file paths to achieve online development. Restore the plugin's entry path field to the online address to complete the plugin's online development and close it; Package the plugin on the open platform, call the plugin upload interface to handle the plugin deployment logic and source code updates in the plugin production environment, and complete the plugin packaging and release; This involves modifying the entry path field maintained in the plugin information table to the currently configured service address to complete the online development startup of the plugin, including: The open platform sends a message to the Node service via the WebSocket protocol to start online plugin development. The Node service starts a sub-thread to execute the command to install dependencies in the target plugin source code directory. After the dependencies are installed, the plugin development service is started to perform development and integration testing on the packaged plugin. The Node service obtains the plugin development service address, calls the Java service interface, and uses the Java service to modify the entry path field value maintained in the information table of the packaged plugin on the Node service to the obtained plugin development service port address; the Node service runs in a sandbox environment. After successfully modifying the entry path field value, the Java service returns a message indicating successful modification to the Node service, and the Node service completes the online plugin development and startup. After the Node service completes the online plugin development and starts, it returns information about the completion of the online plugin development and starts to the open platform via the WebSocket protocol. After the open platform refreshes, it enters the business requirement development stage.
2. The no-code online plugin development and release method as described in claim 1, characterized in that, After initializing the plugin source code, the execution log is continuously output and the source code directory tree is generated, specifically including: steps S21 to S26; Step S21: Visually edit the packaged plugin using the online editing interface of the open platform. Establish a connection between the open platform and the Node service via the WebSocket protocol and send the initialization parameters of the packaged plugin to the Node service. The initialization parameters include: plugin ID, source code compressed package address, and packaging timestamp. Step S22: After the WebSocket protocol connection is successfully established, the execution logs of the Node service are continuously and dynamically displayed on the control interface based on the open platform. Step S23: The Node service receives the initialization parameters of the packaged plugin and determines whether the packaged plugin exists in the source code folder of the Node service based on the initialization parameters of the packaged plugin. If not, proceed to step S24; if yes, proceed to step S25. Step S24: The Node service calls the plugin source code compressed package from the distributed source code storage of the Node service, generates the corresponding source code folder in the Node service according to the initialization parameters of the packaged plugin, and proceeds to step S25. Step S25: Generate a source code directory tree based on the source code folder; Step S26: The node service sends feedback to the open platform via the websocket protocol that the plugin initialization is complete, and the source code directory tree is loaded on the open platform.
3. The no-code online plugin development and release method as described in claim 2, characterized in that, The Node.js service retrieves the plugin source code archive from the distributed source code storage and generates a corresponding source code folder in the Node.js service based on the initialization parameters of the packaged plugin. This folder includes: Based on the source code compressed package address, the Node service retrieves the plugin source code compressed package from the distributed source code storage of the Node service and decompresses the source code compressed package to the source code folder of the Node service; Generate the corresponding source code folder in the source code folder of the Node service based on the plugin ID.
4. The no-code online plugin development and release method as described in claim 2, characterized in that, Obtain the plugin source code from the source code directory tree, including: Select the target directory tree file in the source code directory tree of the open platform; The open platform requests the corresponding target static resource file from the Node static resource server based on the selected target directory tree file path; where the Node static resource server is specified as the source code folder mapped to the Node service, and the target static resource file is the source code of the target plugin; The node service returns the target static resource file to the open platform.
5. The no-code online plugin development and publishing method as described in claim 4, characterized in that, The open platform enables real-time online development and debugging of plugins, generating new directory trees and hot-updating artifacts based on modified source code and file paths, thus achieving online development, including: Modify the plugin source code and source code directory tree online on the open platform, and send the modified plugin source code and its file path to the node service via the WebSocket protocol. In an independent sandbox environment, the Node service modifies the target files in the Node service's source code folder based on the content and file path of the modified plugin source code, and automatically generates a new source code directory tree based on the modified Node service's source code folder. The Node service returns a new source code directory tree to the open platform via the WebSocket protocol. The open platform then refreshes the source code directory tree in the online editing interface based on the new source code directory tree. The plugin development service detects an update to the source code folder of the node service and triggers the hot update service, returning the hot update artifacts to the open platform in the form of logs. The open platform receives hot-update outputs that refresh the online editing interface in real time, enabling online development and obtaining the developed plugins.
6. The no-code online plugin development and release method as described in claim 5, characterized in that, Restore the plugin's entry path field to the online address, and close the online plugin development process, including: Upon entering the online development shutdown process, the open platform sends a message to the Node service via the WebSocket protocol to shut down online development, and the Node service releases the port address occupied by the plugin development service. The Node service calls the Java service interface to restore the entry path field value maintained in the information table of the packaged plugin on the Node service to the previous value. After the entry path field value is restored, a message indicating successful modification is returned to the Node service. The Node service then sends a message indicating successful closure of online plugin development to the open platform via the WebSocket protocol.
7. The no-code online plugin development and release method as described in claim 6, characterized in that, The plugin is packaged on the open platform, and the plugin upload interface is called to handle plugin deployment logic and source code updates in the plugin production environment, completing the plugin packaging and release, including: Once the plugin release process begins, the open platform sends information about the packaged plugin to the Node service via the WebSocket protocol. The Node service executes the packaging command in an independent sandbox environment to obtain the developed plugin package. The Node service calls the plugin upload interface of the Java service to upload the developed plugin package to the application server, performs a production environment update operation, replaces the production environment plugin artifact of the target plugin with the developed plugin package, and completes the deployment of the developed plugin package. After the Java service completes the deployment of the developed plugin package, it returns a message indicating successful upload to the Node service. The Node service then sends the message to the open platform via the WebSocket protocol.
8. A no-code online plugin development and deployment system, used to execute the no-code online plugin development and deployment method as described in any one of claims 1 to 7, characterized in that, include: The open platform, node server, and Java server are connected sequentially. The open platform includes: The receiving module is used to package and upload plugins to the open platform; The initialization module is used to initialize the plugin source code and continuously output execution logs, generating a source code directory tree. The integration and testing module is used to perform integration and testing on the open platform environment to ensure integration and real-time status feedback. It obtains the plugin source code based on the source code directory tree, modifies the entry path field maintained in the plugin information table to the current configured service address, and completes the online development and startup of the plugin. The online development module is used to develop and debug plugins in real time on the open platform. It generates a new directory tree and hot-update real-time artifacts based on the modified source code and file paths, thus enabling online development. The restore module is used to restore the plugin's entry path field to the online address, thus completing the online development and shutdown of the plugin; The packaging and publishing module is used to package plugins on the open platform, call the plugin upload interface to handle plugin deployment logic and source code updates in the plugin production environment, and complete the packaging and publishing of the plugin.
9. A computer device, characterized in that, The computer device includes a memory and a processor, the memory storing a computer program, and the processor executing the computer program to implement the steps of the no-code online plug-in development and release method as described in any one of claims 1-7.
10. A computer-readable storage medium having a computer program stored thereon, characterized in that, When a computer program is executed by a processor, it implements the steps of the no-code online plugin development and distribution method as described in any one of claims 1-7.
Citation Information
Patent Citations
The method for implementing open source code on web side and MC-Studio plug-in
CN109359438A
Mobile terminal productization configuration method and system
CN120892016A