Plugin
GL Plugin is a flexible plugin-based architecture that allows you to build modular and extensible applications. It provides a robust framework for managing plugins, handling dependencies, and injecting services.
Core Components
Plugin Manager
The central orchestrator for plugins. It manages:
Registration, instantiation, and retrieval of plugins.
Ensures that each plugin is paired with its handler and that all dependencies are injected before use.
Handles service registration
Service Registry
A container for all services
Handles registration and retrieval of service instances
Handles dependency injection
Maps service types to their implementations
Note: You don't need to create your own Service Registry - it's automatically created and assigned into the Manager!
Plugin Handler
The Handler is your customization point for how plugins behave. It serves two purposes:
Service Injection: Define what services your plugins receive via
create_injections(). This is where the Service Registry's power flows into your plugins.Lifecycle Control: The
initialize_plugin()method lets you run setup logic when a plugin is instantiated.
In the diagram, notice how Plugin Handler Impl sits in the middle—it extends the base, receives service injections, and handles multiple plugins.
Interface for providing services to plugins
Creates service injections through create_injections
Initializes plugin-specific resources
Can be extended for different types of plugins (e.g., HTTP handlers, Pipelines)
Plugin
Plugins are where your actual functionality lives. The @Plugin.for_handler() decorator binds a plugin to its handler, establishing the relationship shown in the diagram (Handler → "Handles" → Plugins).
This is pure polymorphism in action—extend the base, define your metadata, and add whatever methods your use case requires.
All plugins must inherit from the Plugin base class.
Has basic metadata (name, description, version)
Receives injected services automatically
Can be extended with specific functionality
Last updated