Plug-in routing management method for database tool

Abstract

The invention relates to the technical field of database architecture and management, and provides a database tool plug-in routing management method, which comprises the following steps of: dynamically distributing a globally unique namespace identifier for each functional plug-in; adding a namespace prefix for a front-end routing path of each plug-in according to the namespace identifier to realize centralized registration and life cycle management of routing; all application program interface requests are intercepted in a front-end communication link and a rear-end communication link, namespaces of corresponding plug-ins are automatically associated based on request paths, and standardized request and response processing flows including identity authentication and error processing are implemented; based on an event-driven architecture, an event bus supporting plug-in identifier tracking is established, and an event publishing and subscribing mechanism with context information is provided between plug-ins. According to the invention, routing conflicts can be eliminated, stable operation of the system is guaranteed, standardization of a communication process and centralization of management and control are realized, communication efficiency and consistency are improved, and plug-in development and system maintenance costs are greatly reduced.

Description

A plugin routing management method for database tools Technical Field

[0001] This invention relates to the field of database architecture and management technology, and in particular to a plugin routing management method for database tools. Background Technology

[0002] In the field of database management tools, plug-in architecture enables tools to integrate various heterogeneous functions such as installation and deployment, performance monitoring, real-time alerting, log analysis, and data migration. Each functional module is developed and deployed as an independent plug-in, theoretically enabling parallel development, independent upgrades, and on-demand loading. However, this high degree of modularity and dynamism also brings significant challenges to system communication management, especially in handling front-end and back-end interactions between plug-ins and between plug-ins and the host program.

[0003] Currently, when implementing plug-in architectures, especially for rich client applications such as database tools, the following key technical bottlenecks and shortcomings of existing solutions are typically encountered:

[0004] 1. Disorganized and conflict-ridden routing management: There is a lack of a global coordination mechanism for plugin front-end routes. Each plugin often uses independent, locally optimal path designs (e.g., / dashboard, / login) when defining its own front-end routes. When multiple plugins are loaded into the same runtime environment simultaneously, duplicate route definitions are highly likely, leading to route resolution failures or navigation to the wrong functional module, severely impacting user experience and system stability. Traditional single-page application routing libraries do not have built-in namespace isolation and conflict resolution mechanisms for routes originating from multiple plugins.

[0005] 2. Lack of unified governance in API communication: At the API communication level, existing technical solutions tend to encapsulate the network request logic independently for each plugin. Common logic such as authentication tokens, request header processing, and basic URL configuration are repeatedly implemented in each plugin, generating a large amount of redundant code. The lack of a unified request interception and response processing center makes it difficult to implement global error handling (such as a unified redirect to the login page for 401 unauthorized redirects), request retries, logging, and performance monitoring. When plugins call backend services, their API endpoints lack mandatory association with the plugin's identity, increasing the complexity of request distribution and permission verification for backend services.

[0006] 3. Dispersed and inconsistent access control: Because each plugin handles communication with the backend independently, their user authentication and permission verification logic varies. This dispersed and non-standard access control method easily leaves security blind spots in the system, leading to security vulnerabilities such as privilege escalation or unauthorized access, lacking a unified and standardized mechanism for permission interception and verification at the communication entry point.

[0007] 4. The inter-plugin communication mechanism is primitive and highly coupled: Plugins often need to exchange data or synchronize states (for example, a monitoring plugin needs to trigger an alarm plugin to send a notification after detecting an anomaly). Existing technologies typically use direct function calls, global state sharing, or simple custom events (lacking unified management) to achieve this, resulting in tight coupling between plugin codes, reducing module independence and reusability, making the communication process difficult to trace, debug, and control permissions, and leading to poor reliability and maintainability of communication.

[0008] Chinese patent CN118672744A discloses a component-based communication method and system. This solution standardizes inter-component calls through a centralized interface proxy. However, its design is suitable for mobile terminal component-based scenarios where communication relationships are relatively fixed and static page navigation and method calls are the main functions. When facing dynamic plug-in architectures, especially complex desktop or web applications that require unified front-end and back-end routing, complete conflict isolation, and support for efficient loosely connected database tools, this solution has significant shortcomings in terms of architectural thoroughness, performance efficiency, security control, and overall solution completeness.

[0009] Therefore, how to provide a centralized, unified, isolated, and manageable communication routing management method for plug-in architectures, ensuring that the system maintains a clear, stable, and secure architecture while being highly scalable, has become an urgent technical problem to be solved. Summary of the Invention

[0010] In view of this, in order to overcome the shortcomings of the prior art, the present invention aims to provide a plugin routing management method for database tools.

[0011] According to a first aspect of the present invention, a plugin routing management method for a database tool is provided, the method being applied to a database tool with a plugin-based architecture, comprising:

[0012] Step S1: Dynamically assign a globally unique namespace identifier to each functional plugin;

[0013] Step S2: Add a namespace prefix to the front-end route path of each plugin according to the namespace identifier to achieve centralized registration and lifecycle management of routes;

[0014] Step S3: Intercept all application interface requests in the front-end and back-end communication links, automatically associate the corresponding plugin namespaces based on the request path, and implement a standardized request and response processing flow including identity authentication and error handling;

[0015] Step S4: Based on the event-driven architecture, establish an event bus that supports plugin identifier tracking, and provide an event publishing and subscription mechanism with context information between plugins.

[0016] Optionally, in the plugin routing management method of the database tool of the present invention, in step S1, a globally unique namespace identifier is dynamically assigned to each functional plugin in the following manner:

[0017] A namespace manager component is predefined, through which a namespace allocation interface is provided;

[0018] When a plugin is loaded or initialized, the namespace allocation interface is called and the plugin's unique identifier is passed in.

[0019] The namespace allocation interface generates a structured string as a namespace identifier based on predefined rules and the input plugin identity. The structured string is in a specific path format with the plugin identity as its core.

[0020] Optionally, in the plugin routing management method of the database tool of the present invention, the namespace identifier constitutes a unified basis for resource addressing within the system. All front-end routing access paths and back-end application interface service request paths of the same plugin use the namespace identifier assigned to the plugin as the root path.

[0021] Optionally, the plugin routing management method of the database tool of the present invention includes step S2, which comprises:

[0022] A plugin route registry is predefined, and a route registry is maintained through the plugin route registry. The route registry adopts a key-value pair data structure, where the key is the plugin identity identifier and the value is an array of route configurations that have been processed for the corresponding plugin.

[0023] When a plugin is loaded, the registration interface of the plugin's route registry center is called, passing in the plugin's identity identifier and its original route configuration array;

[0024] The registration interface of the plugin route registry center traverses the original route configuration array. For each route configuration object in the array, it generates a corresponding route-level namespace prefix based on the plugin's identity. It then concatenates the route-level namespace prefix with the original path field in the current route configuration object to generate a new and isolated complete path. Finally, it uses this complete path to update the path field of the current route configuration object.

[0025] Store the route configuration array containing the updated path field into the entry in the route registry with the plugin's identity as the key, thus completing the route registration;

[0026] When a plugin is uninstalled, the uninstallation interface of the plugin route registry is called and the plugin identity identifier is passed in. The entry for the corresponding key is deleted from the route registry, and the route cleanup is completed.

[0027] Optionally, in the plugin routing management method of the database tool of the present invention, in step S2, a route-level namespace prefix is ​​generated and concatenated with the original path field in the following manner: a format string consisting of the prefix static-plugin and the plugin identity is generated as the route-level namespace prefix; the original path field is checked to see if it starts with a forward slash; if so, the forward slash is removed; and the route-level namespace prefix is ​​concatenated with the original path field after the removal process to form a complete path.

[0028] Optionally, in the plugin routing management method of the database tool of the present invention, step S3 automatically associates the namespace of the corresponding plugin based on the request path in the following manner:

[0029] In the front-end request interceptor, pattern matching is performed on the Uniform Resource Locator (URL) of the upcoming request;

[0030] If the Uniform Resource Locator (URL) matches the preset plugin application interface path pattern, the plugin identity identifier is parsed from a specific section of the URL.

[0031] The parsed plugin identity is injected into the header information of the request as metadata for the backend service to identify and route.

[0032] Optionally, in step S3 of the plugin routing management method for the database tool of the present invention, the standardized request and response processing flow further includes:

[0033] In the front-end request interceptor, the user authentication token is automatically read from the client's local persistent storage and added to the authorization header field of all requests in the format of a bearer token.

[0034] In the response interceptor, the received response data packet is structurally parsed;

[0035] If a predefined success status code is parsed from the response data packet, the business data payload is extracted from the data packet and passed to the business logic that initiated the request;

[0036] If a predefined error status code is parsed from the response data packet, or if a network or server error is encountered, a pre-defined unified error handling process is triggered.

[0037] Optionally, in the plugin routing management method of the database tool of the present invention, in step S3, when triggering the preset unified error handling process, different operations are performed according to different error types in the following manner:

[0038] For errors with an unauthorized status code, control the front-end application to navigate to the user login page;

[0039] For errors with a status code of "Access Denied", trigger and display an insufficient permission message in the front-end user interface;

[0040] For other types of errors, the error message text parsed from the response packet is displayed first; otherwise, the default system error message text is displayed.

[0041] Optionally, in the plugin routing management method of the database tool of the present invention, in step S4, an event bus supporting plugin identifier tracking is established in the following manner:

[0042] Instantiate an event bus object, which internally maintains a mapping structure to store the correspondence between event names and a list of listeners;

[0043] It provides an event subscription method. When a plugin needs to listen to a specific event, it calls this event subscription method and passes in the event name, callback function, and the plugin's identity identifier. The event bus object associates and encapsulates the callback function with the plugin's identity identifier to form a listener unit, which is then added to the listener list of the corresponding event.

[0044] It provides an event publishing method. When a plugin needs to trigger an event, it calls this event publishing method and passes in the event name, event data, and the identity identifier of the publishing plugin. The event bus object retrieves the list of listeners for the corresponding event and executes the callback function in each listener unit in turn. When calling, it passes in not only the event data, but also a context object containing the identity identifier of the publishing plugin and the identity identifier of the plugin to which the current listener belongs.

[0045] Optionally, the plugin routing management method of the database tool of the present invention further includes lifecycle management of inter-plugin communication resources, specifically:

[0046] Provides a method to remove event listeners, allowing plugins to unregister specific listeners from the event bus by specifying the event name, callback function reference, and their own plugin identity.

[0047] Provides a batch cleanup method for plugin-level listeners. When a plugin is uninstalled, based on the plugin's identity, it iterates through the listener list of all events within the event bus, automatically filters and removes all listener units associated with the plugin's identity, and completes the reclamation of communication resources.

[0048] The plugin routing management method for the database tool of the present invention has the following beneficial technical effects:

[0049] 1. Eliminate routing conflicts and ensure stable system operation.

[0050] By dynamically assigning and enforcing a unique namespace prefix for each plugin, the path conflict issue between front-end routing and back-end API interfaces in multi-plugin environments is fundamentally resolved. Both the front-end access path and the back-end service request path of a plugin are automatically normalized to independent namespaces such as ` / plugin / pluginID / ` or ` / static-plugin / pluginID / `, achieving physical-level isolation. This enables the parallel execution of any number of plugins, and theoretically reduces the routing conflict rate to zero, fundamentally avoiding system malfunctions or failures caused by routing resolution errors, and significantly improving the overall stability and reliability of complex pluggable systems.

[0051] 2. Achieve standardization of communication processes and centralized management and control to improve communication efficiency and consistency.

[0052] A unified communication management layer is constructed to centrally intercept and process all API requests. Global authentication information is automatically appended via request interceptors, and unified error code parsing and user prompts are implemented via response interceptors. Plugin identifiers are injected into request headers for accurate backend distribution. This eliminates redundancy and inconsistency arising from each plugin implementing its own communication logic, ensuring consistency and predictability of communication behavior across the entire system. This mechanism significantly improves the success rate of API requests while reducing duplicate and redundant network requests, optimizing overall communication efficiency.

[0053] 3. Enhance overall system security

[0054] A unified communication entry point provides a solid foundation for implementing global security policies. Enforcing authentication token verification during the request interception phase, combined with centralized processing of security-related status codes such as 401 and 403 by the response interceptor, standardizes and strengthens authentication and authorization logic. Furthermore, the inter-plugin communication bus requires all event transmissions to identify the source and target plugin, effectively restricting unauthorized cross-plugin access, thereby reducing potential security vulnerabilities and improving overall security protection.

[0055] 4. Significantly reduce plugin development and system maintenance costs.

[0056] By shielding developers from complex underlying technical details such as routing isolation, communication encapsulation, and error handling, developers only need to focus on the business logic and original path definition of their own plugins. They don't need to worry about conflicts with other plugins or repeatedly write boilerplate code for authentication and request formatting, significantly lowering the entry barrier and technical complexity of plugin development and improving the development efficiency of functional modules. All plugin routing and communication behaviors are managed through a centralized registry, interceptors, and event bus, resulting in a clear architecture and traceable status. Dynamic loading and unloading of plugins, accompanied by automatic registration and cleanup of their resources, simplifies and streamlines system expansion and maintenance, significantly reducing the surge in operational costs that occur with the increase in the number of plugins.

[0057] 5. Provides flexible, loosely coupled inter-plugin collaboration capabilities.

[0058] This plugin communication model, based on an event bus mechanism, replaces tightly coupled direct calls with a publish / subscribe pattern. Plugins interact through events, independent of each other's specific implementation details, achieving a high degree of decoupling. This not only improves system scalability—new plugins can easily subscribe to existing events and integrate into the ecosystem—but also enhances system robustness, preventing exceptions in a single plugin from propagating through the direct call chain. Furthermore, the communication context logging function provides strong support for debugging, monitoring, and understanding complex interactions between plugins. Attached Figure Description

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

[0060] Figure 1 is a flowchart illustrating a plugin routing management method for a database tool according to an exemplary embodiment 1 of the present invention;

[0061] Figure 2 is a schematic diagram of the system architecture corresponding to an embodiment of a plugin routing management method for a database tool according to an exemplary embodiment 2 of the present invention;

[0062] Figure 3 is a schematic diagram of the API request processing flow of a plugin routing management method for a database tool according to an exemplary embodiment 2 of the present invention;

[0063] Figure 4 is a schematic diagram of the layered architecture of an embodiment system corresponding to a plug-in routing management method for a database tool according to an exemplary embodiment 2 of the present invention;

[0064] Figure 5 is a schematic diagram of the application process of an embodiment system corresponding to a plug-in routing management method for a database tool according to an exemplary embodiment 2 of the present invention. Detailed Implementation

[0065] The embodiments of the present invention will now be described in detail with reference to the accompanying drawings.

[0066] It should be noted that, unless otherwise specified, the following embodiments and features can be combined with each other; and, based on the embodiments of this disclosure, all other embodiments obtained by those skilled in the art without creative effort are within the scope of protection of this disclosure.

[0067] It should be noted that various aspects of embodiments within the scope of the appended claims are described below. It will be apparent that the aspects described herein can be embodied in a wide variety of forms, and any particular structure and / or function described herein is merely illustrative. Based on this disclosure, those skilled in the art will understand that one aspect described herein can be implemented independently of any other aspect, and two or more of these aspects can be combined in various ways. For example, any number of aspects set forth herein can be used to implement the device and / or practice the method. Additionally, this device and / or method can be implemented using structures and / or functionalities other than one or more of the aspects set forth herein.

[0068] Example 1

[0069] Exemplary embodiment 1 of the present invention provides a plugin routing management method for a database tool. Figure 1 is a flowchart illustrating a plugin routing management method for a database tool according to Exemplary Embodiment 1 of the present invention. As shown in Figure 1, the method of this embodiment is applied to a plugin-based database tool, and is implemented in the following manner:

[0070] Step S1: Dynamically assign a globally unique namespace identifier to each functional plugin.

[0071] As an optional example, in this embodiment, a namespace manager component is predefined, which provides a namespace allocation interface. When a plugin is loaded or initialized, the namespace allocation interface is called and the plugin's unique identifier is passed in. The namespace allocation interface generates a structured string as a namespace identifier based on predefined rules and the passed plugin identifier. The structured string is in a specific path format with the plugin identifier as its core.

[0072] In this embodiment, the namespace identifier forms a unified basis for resource addressing within the system. All front-end routing access paths and back-end application interface service request paths of the same plugin use the namespace identifier assigned to the plugin as the root path.

[0073] Step S2: Add a namespace prefix to the front-end route path of each plugin according to the namespace identifier to achieve centralized registration and lifecycle management of routes.

[0074] In this embodiment, a predefined plugin route registry center is used to maintain a route registry. This route registry uses a key-value pair data structure, where the key is the plugin's identity identifier and the value is the array of route configurations that the plugin has already processed. When a plugin is loaded, the registration interface of the plugin route registry center is called, passing in the plugin's identity identifier and its original route configuration array. The registration interface of the plugin route registry center iterates through the original route configuration array. For each route configuration object in the array, a corresponding route-level namespace prefix is ​​generated based on the plugin's identity identifier. This route-level namespace prefix is ​​concatenated with the original path field in the current route configuration object to generate a new, isolated complete path. This complete path is then used to update the path field of the current route configuration object. The route configuration array containing the updated path field is stored in the route registry under the entry with the plugin's identity identifier as the key, completing the route registration. When a plugin is uninstalled, the uninstallation interface of the plugin route registry center is called, passing in the plugin's identity identifier, to delete the entry with the corresponding key from the route registry, completing the route cleanup.

[0075] It should be noted that in this embodiment, the route-level namespace prefix is ​​generated and concatenated with the original path field in the following manner: a format string consisting of the prefix static-plugin and the plugin identity is generated as the route-level namespace prefix; the original path field is checked to see if it starts with a forward slash; if so, the forward slash is removed; and the route-level namespace prefix is ​​concatenated with the original path field after the removal process to form a complete path.

[0076] Step S3: Intercept all application interface requests in the front-end and back-end communication links, automatically associate the corresponding plugin namespaces based on the request path, and implement a standardized request and response processing flow including identity authentication and error handling.

[0077] In this embodiment, the front-end request interceptor performs pattern matching on the Uniform Resource Locator (URL) of the request to be sent. If the URL matches the preset plugin application interface path pattern, the plugin identity identifier is parsed from a specific segment of the URL. The parsed plugin identity identifier is injected into the header information of the request as the request's metadata for the back-end service to identify and route.

[0078] In this embodiment, the standardized request and response processing flow further includes:

[0079] In the front-end request interceptor, the user authentication token is automatically read from the client's local persistent storage and added to the authorization header field of all requests in the format of a bearer token. In the response interceptor, the received response data packet is parsed. If a predefined success status code is parsed from the response data packet, the business data payload is extracted from the data packet and passed to the business logic that initiated the request. If a predefined error status code is parsed from the response data packet, or if a network or server error is encountered, a preset unified error handling process is triggered.

[0080] Specifically, in the pre-defined unified error handling process, different operations are performed according to different error types in the following manner:

[0081] For errors with an "Unauthorized" status code, control the front-end application to navigate to the user login page; for errors with an "Access Denied" status code, trigger and display an insufficient permissions message in the front-end user interface; for other types of errors, prioritize displaying the error message text parsed from the response data packet, and if none is available, display the default system error message text.

[0082] Step S4: Based on the event-driven architecture, establish an event bus that supports plugin identifier tracking, and provide an event publishing and subscription mechanism with context information between plugins.

[0083] In this embodiment, an event bus supporting plug-in identifier tracking is established in the following manner:

[0084] An event bus object is instantiated, which internally maintains a mapping structure to store the correspondence between event names and listener lists. An event subscription method is provided; when a plugin needs to listen to a specific event, it calls this method, passing in the event name, callback function, and the plugin's identifier. The event bus object encapsulates the callback function with the plugin identifier, forming a listener unit, and adds it to the listener list for the corresponding event. An event publishing method is provided; when a plugin needs to trigger an event, it calls this method, passing in the event name, event data, and the publisher plugin's identifier. The event bus object retrieves the listener list for the corresponding event and executes the callback function in each listener unit sequentially. During the call, in addition to the event data, a context object containing the publisher plugin's identifier and the identifier of the plugin to which the current listener belongs is passed in.

[0085] It should be noted that the method in this embodiment also includes lifecycle management of inter-plugin communication resources, specifically: providing an event listener removal method, allowing plugins to deregister specific listeners from the event bus by specifying the event name, callback function reference, and their own plugin identity; providing a plugin-level listener batch cleanup method, when a plugin is uninstalled, based on the plugin's identity, traversing the listener list of all events within the event bus, automatically filtering and removing all listener units associated with the plugin's identity, thus completing the reclamation of communication resources.

[0086] Example 2

[0087] Exemplary Example 2 of the present invention provides a plugin routing management method for a database tool. The method of this embodiment is implemented in the following system. Figure 2 is a schematic diagram of the architecture of an embodiment system corresponding to the plugin routing management method for a database tool according to Exemplary Example 2 of the present invention. As shown in Figure 2, the system includes the following components: a namespace management module, a front-end routing management module, an API request management module, and an inter-plugin communication module.

[0088] Specifically, the namespace management module includes:

[0089] Plugin namespace allocation unit: Assign a unique namespace prefix to each plugin, in the format: / plugin / {pluginID}.

[0090] Route isolation unit: All plugin routes are automatically prefixed with a namespace to avoid route conflicts between different plugins.

[0091] API Namespace Units: Plugin API requests also add a namespace prefix to achieve modular management of API calls.

[0092] Specifically, the front-end routing management module includes:

[0093] Route scanning unit: Automatically scans and parses the front-end route configuration file when the plugin is loaded.

[0094] Route Registration Unit: Centrally manages the routing information of all plugins, and supports dynamic registration and uninstallation.

[0095] Routing interception unit: handles the logic of permission verification and parameter checking before route redirection in a unified manner.

[0096] Specifically, the API request management module includes:

[0097] Request interception unit: Unifies the processing of authentication information, parameter formatting, etc. for all plugin API requests.

[0098] Response interception unit: handles API response error codes, data formatting, etc. in a unified manner.

[0099] Request caching unit: Supports caching of API request results, reducing duplicate requests and improving performance. Figure 3 is a schematic diagram of the API request processing flow of a plugin routing management method for a database tool according to an exemplary embodiment 2 of the present invention.

[0100] Specifically, the inter-plugin communication module includes:

[0101] Event publishing unit: Based on the event-driven model, it enables event publishing between plugins.

[0102] Event subscription unit: Provides an event subscription mechanism, allowing plugins to receive events published by other plugins.

[0103] Communication permission control unit: restricts the scope of communication between plug-ins to ensure system security.

[0104] Figure 4 is a schematic diagram of the layered architecture of an embodiment system corresponding to a plug-in routing management method for a database tool according to an exemplary embodiment 2 of the present invention. As shown in Figure 4, the system in this embodiment includes:

[0105] The plugin layer contains multiple functional plugins, such as installation and deployment plugins, operation and maintenance plugins, monitoring plugins, alarm plugins, log analysis plugins, etc.

[0106] The routing management layer includes a namespace management module, a front-end routing management module, an API request management module, and an inter-plugin communication module.

[0107] Backend service layer. Provides the backend services and API interfaces required by the plugin.

[0108] During system deployment, service deployment is performed by compiling and deploying the front-end and back-end code to the application server, including the main program and the front-end and back-end code of each plugin. A database such as Vastbase is also deployed.

[0109] Figure 5 is a schematic diagram of the application flow of an embodiment system corresponding to a plug-in routing management method for a database tool according to Exemplary Embodiment 2 of the present invention. As shown in Figure 5, the system of this embodiment is applied in the following manner:

[0110] 1. Plugin loading: Installed plugins are automatically loaded when the system starts.

[0111] 2. Route registration: After the plugin is loaded, its front-end routes are automatically registered.

[0112] 3. API calls: The front end calls the back end service through a unified API request mechanism.

[0113] 4. Inter-plugin communication: Plugins communicate with each other through an event bus.

[0114] 5. Plugin Uninstallation: The system supports dynamic plugin uninstallation, automatically cleaning up related resources during uninstallation.

[0115] Example 3

[0116] Exemplary embodiment 3 of the present invention provides a plugin routing management method for database tools. The method of this embodiment is implemented in the following manner:

[0117] Step 1: Namespace Management

[0118] Implement a namespace manager class named `NamespaceManager` in Java to allocate unique namespaces to plugins and add namespace prefixes to routes / API requests. This class ensures that routes and API requests from different plugins do not conflict by allocating an independent namespace for each plugin and automatically handling path prefixes, thus achieving resource isolation and unified management within the plugin system. The specific method is as follows:

[0119] 1. Implement a common class to uniformly manage the namespace resources of plugins. The class structure is shown below:

[0120] public class NamespaceManager {

[0121] / / Method definition...

[0122] }

[0123] 2. Allocate a unique namespace method (allocateNamespace): Allocates a unique namespace for the specified plugin.

[0124] Parameter: pluginId (a unique identifier for the plugin)

[0125] Return value: A namespace string in the format / plugin / pluginID /

[0126] For example, if pluginId is user-auth, then / plugin / user-auth / will be returned.

[0127] Here is an example of a method for allocating a unique namespace:

[0128] / / Assign a unique namespace to the plugin

[0129] public String allocateNamespace(String pluginId) {

[0130] return " / plugin / " + pluginId + " / ";

[0131] }

[0132] 3. Add a namespace prefix to the route (addNamespaceToRoute): Add a namespace prefix to the plugin's route path.

[0133] Parameter: pluginId (unique identifier for the plugin)

[0134] route (route path, such as / login or dashboard)

[0135] Processing logic: Call allocateNamespace(pluginId) to get the namespace of the plugin, and check if the route path starts with / : if it does, remove the leading / (using substring(1)); if not, keep the original path unchanged.

[0136] Return value: Concatenates the namespace with the processed route path and returns it.

[0137] For example, when pluginId is user-auth and route is / login, it returns / plugin / user-auth / login; when pluginId is user-auth and route is dashboard, it returns / plugin / user-auth / dashboard.

[0138] Here's an example of how to add a namespace prefix to a route:

[0139] / / Add a namespace prefix to the route

[0140] public String addNamespaceToRoute(String pluginId, String route) {

[0141] return allocateNamespace(pluginId) + (route.startsWith(" / ") ?route.substring(1) : route);

[0142] }

[0143] 4. Add a namespace prefix to API requests (addNamespaceToApi): Add a namespace prefix to the plugin's API request path (the logic is the same as routing).

[0144] Parameters: pluginId (unique identifier for the plugin); api (API request path, such as / user / info or data / list).

[0145] Processing logic: It is exactly the same as the addNamespaceToRoute method, the only difference being the parameter name (api instead of route).

[0146] For example, when pluginId is user-auth and api is / user / info, it returns / plugin / user-auth / user / info; when pluginId is user-auth and api is data / list, it returns / plugin / user-auth / data / list.

[0147] Here's an example of how to add a namespace prefix to an API request:

[0148] / / Add a namespace prefix to API requests

[0149] public String addNamespaceToApi(String pluginId, String api) {

[0150] return allocateNamespace(pluginId) + (api.startsWith(" / ") ?api.substring(1) : api);

[0151] }

[0152] Step 2: Automatic Registration of Front-End Routers

[0153] Create a plugin route registry class named PluginRouterRegistry to centrally manage and maintain plugin routing information. This class implements a centralized management mechanism for plugin routes, avoids route conflicts by automatically adding namespace prefixes, and provides complete functionality for registering, uninstalling, and querying routes. It is suitable for managing routes in front-end applications with a plugin-based architecture.

[0154] The specific method is as follows:

[0155] 1. Class Structure and Initialization: The constructor initializes a Map type registry property to store the routing information of each plugin. The Map structure uses the plugin ID as the key and an array of all routes for that plugin as the value.

[0156] Example as follows:

[0157] class PluginRouterRegistry {

[0158] constructor() {

[0159] this.registry = new Map();

[0160] }

[0161] / / ... Method definition

[0162] }

[0163] 2. Register Plugin Routes method (registerPluginRoutes): Registers routes for the specified plugin and automatically adds a namespace prefix.

[0164] parameter:

[0165] pluginId: A unique identifier for the plugin;

[0166] routes: The plugin's raw route array (each route is an object containing properties such as path);

[0167] Processing logic: Generate namespace: in the format / static-plugin / pluginID / , for example, when pluginId is user, the namespace is / static-plugin / user / .

[0168] Processing route paths: Use a map to traverse the original route array. For each route, use the spread operator ...route to retain the original attributes; modify the path attribute, add a namespace prefix, and handle the leading forward slash in the path (if the path starts with / , remove the forward slash before concatenation).

[0169] Store routes: Store the processed route array in a registry map, with the plugin ID as the key.

[0170] Return value: Returns an array of routes with namespace prefixes added.

[0171] For example, if the original route is { path: ' / login', component: Login}, and the plugin ID is user, then the processed route will be: {path:' / static-plugin / user / login',component: Login}

[0172] Here is an example of a plugin routing method:

[0173] registerPluginRoutes(pluginId, routes) {

[0174] const namespace = ` / static-plugin / ${pluginId} / `;

[0175] / / Add namespace prefix to all routes

[0176] const prefixedRoutes = routes.map(route => ({

[0177] ...route,

[0178] path: namespace + (route.path.startsWith(' / ') ?route.path.slice(1) : route.path)

[0179] }));

[0180] this.registry.set(pluginId, prefixedRoutes);

[0181] return prefixedRoutes;

[0182] }

[0183] 3. Unregister PluginRoutes: Unregisters all routes of the specified plugin.

[0184] Parameter: pluginId (unique identifier for the plugin);

[0185] Processing logic: Delete the route entry corresponding to the plugin ID from the registry map.

[0186] Here is an example of a plugin uninstallation routing method:

[0187] unregisterPluginRoutes(pluginId) {

[0188] this.registry.delete(pluginId);

[0189] }

[0190] 4. Get all registered routes using the method getAllRoutes.

[0191] Processing logic: Use registry.values() to get an array of routes for all plugins; use Array.from() to convert it into an array; use the flat() method to flatten the nested array to get a one-dimensional array of all routes.

[0192] Return value: A flattened array containing all plugin routes.

[0193] Here is an example of how to retrieve all registered route methods:

[0194] getAllRoutes() {

[0195] return Array.from(this.registry.values()).flat();

[0196] }

[0197] Step 3: Unified interception and processing of API requests

[0198] By leveraging Axios's interceptor mechanism, automatic authentication, plugin API route identification, unified data format, unified error handling, reduced code duplication, improved maintainability, and unified error messages and authentication redirection logic enhance user experience. This interception mechanism is used in plugin-based front-end applications and effectively manages API request authentication and namespace isolation.

[0199] Specifically, it will be implemented in the following manner:

[0200] 1. API Request Interceptor Configuration

[0201] Automatically add authentication information: Retrieve the authentication token from the browser's local storage (localStorage). If the token exists, add it to the Authorization field in the request header, in the format Bearer{token}.

[0202] Unified handling of plugin API namespaces: Check if the request URL starts with / api / plugin / (the namespace format for plugin APIs). If it is a plugin API, extract the plugin ID (e.g., user-auth in / api / plugin / user-auth / info) by URL splitting, and add the extracted plugin ID to the X-Plugin-Id field in the request header for backend service identification and request distribution.

[0203] Error handling: If request interception fails, wrap the error as a Promise and reject the request.

[0204] Example as follows:

[0205] axios.interceptors.request.use(

[0206] config => {

[0207] / / Automatically add authentication information

[0208] const token = localStorage.getItem('token');

[0209] if (token) {

[0210] config.headers['Authorization'] = `Bearer ${token}`;

[0211] }

[0212] / / Unified handling of plugin API namespace

[0213] / / APIs also use namespace isolation, in the format of / api / plugin / {pluginId}

[0214] if (config.url.startsWith(' / api / plugin / ')) {

[0215] / / Add a plugin identifier header for backend service distribution

[0216] const pluginId = config.url.split(' / ')[3];

[0217] config.headers['X-Plugin-Id'] = pluginId;

[0218] }

[0219] / / Caching logic could be added to reduce frequent duplicate requests, but this is not very meaningful for ordinary business operations.

[0220] / / However, monitoring systems require high timeliness.

[0221] return config;

[0222] },

[0223] error => {

[0224] return Promise.reject(error);

[0225] }

[0226] );

[0227] 2. API Response Interceptor Configuration

[0228] Unified handling of response data format: Assuming the data format returned by the backend is {code: status code, data: response data, message: message}, if the status code is 200 (success), then directly return response.data.data (actual business data); if the status code is not 200, then wrap the error message as a Promise and reject it.

[0229] Unified handling of HTTP errors: First, check if an error response object (error.response) exists, and then handle it differently based on the HTTP status code.

[0230] 401 Unauthorized: Redirecting to the login page (router.push(' / login')).

[0231] 403 Permission Insufficient: Displays the error message "Permission Insufficient" (Message.error()).

[0232] Other status codes: Display the error message returned by the backend. If none is found, the default "Request failed" will be displayed.

[0233] Error handling: If the response processing fails, wrap the error as a Promise and reject it.

[0234] Example as follows:

[0235] axios.interceptors.response.use(

[0236] response => {

[0237] / / Unify the processing of response data format

[0238] if (response.data.code === 200) {

[0239] return response.data.data;

[0240] } else {

[0241] return Promise.reject(new Error(response.data.message));

[0242] }

[0243] },

[0244] error => {

[0245] / / Unified error handling

[0246] if (error.response) {

[0247] switch (error.response.status) {

[0248] Case 401:

[0249] / / Handling unauthorized errors

[0250] router.push(' / login');

[0251] break

[0252] Case 403:

[0253] / / Handling insufficient permissions error

[0254] Message.error('Insufficient permissions');

[0255] break

[0256] default:

[0257] Message.error(error.response.data.message || 'Request failed');

[0258] }

[0259] }

[0260] return Promise.reject(error);

[0261] }

[0262] );

[0263] Step 4: Inter-plugin communication bus

[0264] Implement a plugin communication bus class named EventBus to manage event communication between plugins. It supports event registration, publishing, removal, and cleanup, and adds plugin identification and communication auditing features. This implementation adds plugin-level management compared to a regular event bus, making it more suitable for cross-plugin communication scenarios in a pluggable architecture. It offers the following advantages: Plugin identification tracking: Records the source plugin and event-triggered plugin for each listener, facilitating management and auditing; Communication context passing: Callback functions can obtain the source and target information of events, supporting more complex inter-plugin communication logic; Scalability: Reserves extension points for communication permission control and auditing functions; Lifecycle management: Supports cleaning up all listeners by plugin, facilitating plugin uninstallation and resource release.

[0265] As an optional example, it can be implemented as follows:

[0266] 1. Class structure and initialization: Initialize a Map type events property to store listeners for different events. The Map structure uses the event name as the key and the array of listeners for that event as the value.

[0267] Example as follows:

[0268] / / Plug-in communication bus

[0269] class EventBus {

[0270] constructor() {

[0271] this.events = new Map();

[0272] }

[0273] / / ... Method definition

[0274] }

[0275] 2. Register an event listener (on): Register a listener for the specified event and record the plugins that listen for the event.

[0276] parameter:

[0277] event: Event Name

[0278] callback: The callback function that is executed when the event is triggered.

[0279] pluginId: The plugin ID used to register this listener

[0280] Processing logic: Check if the event already exists in the events Map; if not, create an empty array; store the callback function and plugin ID as objects in the listener array for the event; unlike ordinary event buses: additionally record which plugin registered the listener for easier subsequent management and auditing.

[0281] Example as follows:

[0282] / / Register event listeners

[0283] on(event, callback, pluginId) {

[0284] if (!this.events.has(event)) {

[0285] this.events.set(event, []);

[0286] }

[0287] / / Unlike the usual practice, this section records which plugin is listening to the event.

[0288] this.events.get(event).push({ callback, pluginId});

[0289] }

[0290] 3. Publish an event (emit): Publish the specified event and notify all registered listeners.

[0291] parameter:

[0292] event name

[0293] data passed to the listener

[0294] sourcePluginId is the ID of the source plugin that triggered this event.

[0295] Processing logic: Check if the event exists; if it does, iterate through all its listeners; call the callback function of each listener, passing two parameters:

[0296] data: event data

[0297] Communication context object: contains the source plugin ID and target plugin ID of the event.

[0298] Supports extended functionality: Communication access control can be added (such as restricting event communication between certain plugins), and complete information for each event trigger can be recorded for subsequent auditing.

[0299] Example as follows:

[0300] / / When publishing an event, you need to include the event trigger source plugin.

[0301] emit(event, data, sourcePluginId) {

[0302] if (this.events.has(event)) {

[0303] this.events.get(event).forEach(({ callback, pluginId}) => {

[0304] / / You can add communication permission control

[0305] / / You can also record the source and context of each event for later auditing.

[0306] callback(data, { source: sourcePluginId, target: pluginId});

[0307] });

[0308] }

[0309] }

[0310] 4. Remove event listener (off): Removes a specific listener for a specified event.

[0311] parameter:

[0312] event name

[0313] callback functions to be removed

[0314] pluginId is the plugin ID that registers this listener.

[0315] Processing logic: Check if the event exists; if it does, retrieve its listener list; remove listeners with specified callback functions and plugin IDs through filtering operations; record each removal operation for auditing or debugging.

[0316] Example as follows:

[0317] / / Remove event listener

[0318] off(event, callback, pluginId) {

[0319] / / Record each removal operation

[0320] if (this.events.has(event)) {

[0321] const listeners = this.events.get(event);

[0322] this.events.set(event, listeners.filter(

[0323] listener => listener.callback !== callback ||listener.pluginId !== pluginId

[0324] ));

[0325] }

[0326] }

[0327] 5. Clear all event listeners for the plugin (clearPluginListeners)

[0328] Parameter: pluginId (the plugin ID for the listener to be cleaned up)

[0329] Processing logic: Iterate through all events and their listener lists; for each event, filter out listeners registered by the specified plugin; record each cleanup action for auditing or plugin lifecycle management.

[0330] Example as follows:

[0331] / / Clean up all event listeners in the plugin

[0332] clearPluginListeners(pluginId) {

[0333] / / Record each cleanup action for auditing purposes.

[0334] for (const [event, listeners] of this.events.entries()) {

[0335] this.events.set(event, listeners.filter(listener =>listener.pluginId !== pluginId));

[0336] }

[0337] }

[0338] In practical applications, the plugin routing management method for the database tool of the present invention has the following beneficial technical effects:

[0339] 1. Eliminate routing conflicts and ensure stable system operation.

[0340] By dynamically assigning and enforcing a unique namespace prefix for each plugin, the path conflict issue between front-end routing and back-end API interfaces in multi-plugin environments is fundamentally resolved. Both the front-end access path and the back-end service request path of a plugin are automatically normalized to independent namespaces such as ` / plugin / pluginID / ` or ` / static-plugin / pluginID / `, achieving physical-level isolation. This enables the parallel execution of any number of plugins, and theoretically reduces the routing conflict rate to zero, fundamentally avoiding system malfunctions or failures caused by routing resolution errors, and significantly improving the overall stability and reliability of complex pluggable systems.

[0341] 2. Achieve standardization of communication processes and centralized management and control to improve communication efficiency and consistency.

[0342] A unified communication management layer is constructed to centrally intercept and process all API requests. Global authentication information is automatically appended via request interceptors, and unified error code parsing and user prompts are implemented via response interceptors. Plugin identifiers are injected into request headers for accurate backend distribution. This eliminates redundancy and inconsistency arising from each plugin implementing its own communication logic, ensuring consistency and predictability of communication behavior across the entire system. This mechanism significantly improves the success rate of API requests while reducing duplicate and redundant network requests, optimizing overall communication efficiency.

[0343] 3. Enhance overall system security

[0344] A unified communication entry point provides a solid foundation for implementing global security policies. Enforcing authentication token verification during the request interception phase, combined with centralized processing of security-related status codes such as 401 and 403 by the response interceptor, standardizes and strengthens authentication and authorization logic. Furthermore, the inter-plugin communication bus requires all event transmissions to identify the source and target plugin, effectively restricting unauthorized cross-plugin access, thereby reducing potential security vulnerabilities and improving overall security protection.

[0345] 4. Significantly reduce plugin development and system maintenance costs.

[0346] By shielding developers from complex underlying technical details such as routing isolation, communication encapsulation, and error handling, developers only need to focus on the business logic and original path definition of their own plugins. They don't need to worry about conflicts with other plugins or repeatedly write boilerplate code for authentication and request formatting, significantly lowering the entry barrier and technical complexity of plugin development and improving the development efficiency of functional modules. All plugin routing and communication behaviors are managed through a centralized registry, interceptors, and event bus, resulting in a clear architecture and traceable status. Dynamic loading and unloading of plugins, accompanied by automatic registration and cleanup of their resources, simplifies and streamlines system expansion and maintenance, significantly reducing the surge in operational costs that occur with the increase in the number of plugins.

[0347] 5. Provides flexible, loosely coupled inter-plugin collaboration capabilities.

[0348] This plugin communication model, based on an event bus mechanism, replaces tightly coupled direct calls with a publish / subscribe pattern. Plugins interact through events, independent of each other's specific implementation details, achieving a high degree of decoupling. This not only improves system scalability—new plugins can easily subscribe to existing events and integrate into the ecosystem—but also enhances system robustness, preventing exceptions in a single plugin from propagating through the direct call chain. Furthermore, the communication context logging function provides strong support for debugging, monitoring, and understanding complex interactions between plugins.

[0349] Through the above description of the embodiments, those skilled in the art can clearly understand that each embodiment can be implemented by means of software plus necessary general-purpose hardware platforms, and of course, it can also be implemented by hardware. Based on this understanding, the above technical solutions, in essence or the part that contributes to the prior art, can be embodied in the form of a software product. This computer software product can be stored in a computer-readable storage medium, such as ROM / RAM, magnetic disk, optical disk, etc., including several instructions to cause a computer device (which may be a personal computer, server, or network device, etc.) to execute the methods of various embodiments or some parts of embodiments.

[0350] The above description is merely a specific embodiment of the present invention, but the scope of protection of the present invention is not limited thereto. Any variations or substitutions that can be easily conceived by those skilled in the art within the technical scope disclosed in the present invention should be included within the scope of protection of the present invention. Therefore, the scope of protection of the present invention should be determined by the scope of the claims.

Claims

1. A plugin routing management method for a database tool, characterized in that, The method is applied to a database tool with a plug-in architecture, including: Step S1: Dynamically assigning a globally unique namespace identifier to each functional plug-in; Step S2: Adding a namespace prefix to the front-end routing path of each plug-in based on the namespace identifier, realizing centralized registration and lifecycle management of routes; Step S3: Intercepting all application interface requests in the front-end and back-end communication links, automatically associating the namespace of the corresponding plug-in based on the request path, and implementing a standardized request and response processing flow including identity authentication and error handling; Step S4: Based on an event-driven architecture, establishing an event bus that supports plug-in identifier tracking, providing an event publishing and subscription mechanism with context information between plug-ins.

2. The plugin routing management method for database tools according to claim 1, characterized in that, In step S1, a globally unique namespace identifier is dynamically assigned to each functional plugin in the following manner: A namespace manager component is predefined, and a namespace allocation interface is provided through this namespace manager component; when a plugin is loaded or initialized, the namespace allocation interface is called and the unique identity identifier of the plugin is passed in; the namespace allocation interface generates a structured string as a namespace identifier according to the predefined rules and the passed plugin identity identifier, wherein the format of the structured string is a specific path format with the plugin identity identifier as the core.

3. The plugin routing management method for database tools according to claim 2, characterized in that, Namespace identifiers form the unified basis for resource addressing within the system. All front-end route access paths and back-end application interface service request paths of the same plugin use the namespace identifier assigned to that plugin as the root path.

4. The plugin routing management method for database tools according to claim 2, characterized in that, Step S2 includes: predefining a plugin route registry center, maintaining a route registry through the plugin route registry center, the route registry adopting a key-value pair data structure, where the key is the plugin identity identifier, and the value is the array of route configurations corresponding to the plugin that have been processed; when the plugin is loaded, calling the registration interface of the plugin route registry center, passing in the plugin identity identifier and its original route configuration array; the registration interface of the plugin route registry center traverses the original route configuration array, for each route configuration object in the array, generating a corresponding route-level namespace prefix according to the plugin identity identifier, concatenating the route-level namespace prefix with the original path field in the current route configuration object to generate a new and isolated complete path, and using the complete path to update the path field of the current route configuration object; storing the route configuration array containing the updated path field in the route registry under the entry with the plugin identity identifier as the key, completing the route registration; when the plugin is uninstalled, calling the uninstallation interface of the plugin route registry center and passing in the plugin identity identifier, deleting the entry with the corresponding key from the route registry, completing the route cleanup.

5. The plugin routing management method for database tools according to claim 4, characterized in that, In step S2, the route-level namespace prefix is ​​generated and concatenated with the original path field in the following manner: a format string consisting of the prefix static-plugin and the plugin identity is generated as the route-level namespace prefix; the original path field is checked to see if it starts with a forward slash; if so, the forward slash is removed; and the route-level namespace prefix is ​​concatenated with the original path field after the removal process to form the complete path.

6. The plugin routing management method for database tools according to claim 1, characterized in that, In step S3, the namespace of the corresponding plugin is automatically associated based on the request path in the following way: In the front-end request interceptor, the Uniform Resource Locator (URL) of the request to be sent is matched for pattern matching; if the URL matches the preset plugin application interface path pattern, the plugin identity identifier is parsed from a specific section of the URL. The parsed plugin identity is injected into the header information of the request as metadata for the backend service to identify and route.

7. The plugin routing management method for database tools according to claim 6, characterized in that, In step S3, the standardized request and response processing flow also includes: in the front-end request interceptor, automatically reading the user authentication token from the client's local persistent storage and adding the token in the format of a bearer token to the authorization header field of all requests; in the response interceptor, performing structural parsing on the received response data packet; if a predefined success status code is parsed in the response data packet, extracting the business data payload from the data packet and passing it to the business logic that initiated the request; if a predefined error status code is parsed in the response data packet, or if a network or server error is encountered, triggering a preset unified error handling process.

8. The plugin routing management method for database tools according to claim 7, characterized in that, In step S3, the preset unified error handling process is triggered, and different operations are performed according to different error types as follows: For errors with the status code "unauthorized", the front-end application is controlled to navigate to the user login page; for errors with the status code "access denied", an insufficient permission prompt message is triggered and displayed on the front-end user interface; for other types of errors, the error information text parsed from the response data packet is displayed first, and if there is no error, the default system error prompt text is displayed.

9. The plugin routing management method for database tools according to claim 1, characterized in that, In step S4, an event bus that supports plugin identifier tracking is established as follows: an event bus object is instantiated, which internally maintains a mapping structure to store the correspondence between event names and listener lists; It provides an event subscription method. When a plugin needs to listen to a specific event, it calls this event subscription method and passes in the event name, callback function, and the plugin's identity identifier. The event bus object associates and encapsulates the callback function with the plugin's identity identifier to form a listener unit, which is then added to the listener list of the corresponding event. It provides an event publishing method. When a plugin needs to trigger an event, it calls this event publishing method and passes in the event name, event data, and the identity identifier of the publishing plugin. The event bus object retrieves the list of listeners for the corresponding event and executes the callback function in each listener unit in turn. When calling, it passes in not only the event data, but also a context object containing the identity identifier of the publishing plugin and the identity identifier of the plugin to which the current listener belongs.

10. The plugin routing management method for database tools according to claim 9, characterized in that, The method also includes lifecycle management of inter-plugin communication resources, specifically: providing an event listener removal method that allows plugins to unregister specific listeners from the event bus by specifying the event name, callback function reference, and their own plugin identity; and providing a plugin-level listener batch cleanup method that, when a plugin is uninstalled, automatically filters and removes all listener units associated with the plugin identity by traversing the listener list of all events within the event bus based on the plugin's identity, thus completing the reclamation of communication resources.

Images