Skip to main content

Core Concepts of the Plugin System

In the Xpert AI plugin system, all plugins follow a unified interface specification and lifecycle management. Through a set of core concepts, developers can easily extend the host system's capabilities without modifying the core code.


2.1 XpertPluginโ€‹

XpertPlugin is the main entry interface for plugins, defining plugin metadata (meta), configuration (config), lifecycle methods, and module registration logic.

export interface XpertPlugin<TConfig extends object = any> 
extends PluginLifecycle, PluginHealth {
meta: PluginMeta; // Plugin metadata
config?: PluginConfigSpec<TConfig>; // Plugin configuration
register(ctx: PluginContext<TConfig>): DynamicModule; // Register plugin module
}
  • meta: Basic plugin metadata, including name, version, category, icon, description, etc.
  • config: Defines the plugin's configuration schema (based on zod), supporting default values and UI form rendering.
  • register: Returns a DynamicModule to mount the plugin to the main application (optionally as global).

2.2 Plugin Lifecycleโ€‹

The plugin system provides a complete set of lifecycle hooks for each plugin, allowing developers to execute initialization or cleanup logic at different stages.

export interface PluginLifecycle {
onInit?(ctx: PluginContext): Promise<void> | void; // Called after module registration
onStart?(ctx: PluginContext): Promise<void> | void; // Called after app startup (services available)
onStop?(ctx: PluginContext): Promise<void> | void; // Called during graceful shutdown
}
  • onInit: Suitable for resource initialization (e.g., loading configs, registering resource pools).
  • onStart: Suitable for starting background tasks or service listeners.
  • onStop: Suitable for cleaning up resources, closing connections, releasing caches.

2.3 Plugin Health Checkโ€‹

Plugins can implement the checkHealth method to report their running status, enabling unified health monitoring by the host system.

export interface PluginHealth {
checkHealth?(ctx: PluginContext): Promise<{ status: 'up' | 'down'; details?: any }>
}
  • status: Running status (up or down)
  • details: Optional dependency check details, such as API connectivity or database status

2.4 Plugin Contextโ€‹

PluginContext provides plugins with runtime access to the host system, including application context, logging service, and configuration.

export interface PluginContext<TConfig extends object = any> {
app: INestApplicationContext; // Nest runtime context
logger: PluginLogger; // SDK-provided logging wrapper
config: TConfig; // Final validated and merged config
resolve<TInput, TResult>(token: any): TResult; // Dependency injection resolver
}
  • app: NestJS's INestApplicationContext, allowing access to the DI container.
  • logger: Unified logging interface, supporting debug, log, warn, error.
  • config: Final config object after zod validation and merging defaults.
  • resolve: Retrieve other providers from the NestJS container.

2.5 Plugin Configuration Specificationโ€‹

Each plugin can define a configuration specification to constrain and validate config parameters, usually implemented via a zod schema:

export interface PluginConfigSpec<T extends object = any> {
schema?: ZodSchema<T>; // Config validation schema
defaults?: Partial<T>; // Default config
}
  • Supports type safety (zod type inference)
  • Supports default values and secure input (e.g., API key secrets)
  • The host system automatically renders the config UI based on the schema

2.6 XpertServerPlugin Decoratorโ€‹

@XpertServerPlugin is an enhanced Nestjs Module class decorator, used to register plugins as NestJS modules and attach plugin metadata.

@XpertServerPlugin({
imports: [ /* submodules */ ],
providers: [ /* services, strategies */ ],
controllers: [ /* controllers */ ],
entities: [ /* database entities */ ],
})
export class FirecrawlPlugin { ... }
  • Essentially extends NestJS's @Module decorator
  • Supports registering submodules, services, controllers, entities, etc.
  • The plugin thus becomes a complete NestJS dynamic module

2.7 Enhancement Pointsโ€‹

Enhancement points are the key mechanism for plugins to extend the host system. The host system defines a series of strategy interfaces, and plugins can implement these interfaces and use decorators to be automatically discovered and registered.

IntegrationStrategyโ€‹

Used to connect external systems or API services, such as Firecrawl, OpenAI, etc.

export interface IntegrationStrategy<T = unknown> {
meta: TIntegrationProvider;
execute(integration: IIntegration<T>, payload: TIntegrationStrategyParams): Promise<any>;
}
  • meta: Metadata for the integration provider (name, description, icon, etc.)
  • execute: Executes the integration logic (e.g., calling external APIs)

Decorator:

@IntegrationStrategyKey('Firecrawl')
@Injectable()
export class FirecrawlIntegrationStrategy implements IntegrationStrategy<FirecrawlOptions> { ... }

DocumentSourceStrategyโ€‹

Used to connect new data sources, such as web crawlers, file parsers, databases. Plugins only need to implement the corresponding interface to make the data source available to agents/BI.


2.8 Strategy Registryโ€‹

All strategy classes (Integration, DocumentSource, etc.) are registered to the strategy registry via decorators + NestJS dependency injection.

For example, IntegrationStrategy:

@Injectable()
export class IntegrationStrategyRegistry
extends BaseStrategyRegistry<IntegrationStrategy> {
constructor(discoveryService: DiscoveryService, reflector: Reflector) {
super(INTEGRATION_STRATEGY, discoveryService, reflector);
}
}
  • IntegrationStrategyRegistry automatically discovers classes decorated with @IntegrationStrategyKey
  • Plugins do not need to manually register strategies; implementing the interface and using the decorator is enough for system recognition

๐Ÿ“Œ Summary:

  • XpertPlugin defines plugin metadata, configuration, and lifecycle
  • XpertServerPlugin registers plugins as NestJS modules
  • Enhancement points (Strategy) are the core for plugins to extend host system functionality
  • All plugins form extensible and maintainable modules via lifecycle + strategy interfaces + config schema