Plugin Architecture & Manager
Relevant source files
The following files were used as context for generating this wiki page:
The FLEXT API uses a modular plugin architecture to extend the functionality of its core services, particularly the HTTP client and API service class. This system allows for the dynamic addition of capabilities such as specialized protocols (WebSockets, SSE, GraphQL), custom authentication schemes, schema validation, and specialized network transports. Sources: src/README.md, src/flext_api/client.py
The architecture is governed by a centralized Manager that handles the discovery, lifecycle, and resolution of plugins based on strict protocols. Sources: src/flext_api/_protocols/plugin_manager.py:22-24
Core Plugin Types
FLEXT API defines several specialized plugin categories, each inheriting from a common base to ensure a consistent interface for initialization and shutdown. Sources: src/flext_api/_protocols/plugin_types.py:14-38
Hierarchy and Specializations
The following class diagram illustrates the relationship between the base plugin and its specialized implementations:
| Plugin Type | Responsibility | Key Methods |
|---|---|---|
| Protocol | Handles non-standard HTTP methods like WS, SSE, and GraphQL. | send_request, supports_protocol |
| Schema | Manages schema loading and validation for requests and responses. | validate_request, validate_response |
| Transport | Manages low-level network connections and data transmission. | connect, send, receive |
| Authentication | Injects credentials and manages auth-scheme validation. | authenticate, refresh_credentials |
Sources: src/flext_api/_protocols/plugin_types.py:40-150
Plugin Manager Logic
The FlextApiProtocolPluginManager.Manager is responsible for the operational lifecycle of plugins. It maintains an internal registry of loaded plugins and provides methods for type-safe resolution. Sources: src/flext_api/_protocols/plugin_manager.py:19-25
Lifecycle Management
The manager ensures that plugins are correctly initialized before being added to the registry and provides a clean shutdown mechanism. Sources: src/flext_api/_protocols/plugin_manager.py:59-75
Key Functions
resolve_plugin(plugin_name): Retrieves a specific plugin instance. Returns a failureResultif the plugin is not found. Sources: src/flext_api/_protocols/plugin_manager.py:32-41resolve_plugins_by_type(plugin_type): Filters all loaded plugins and returns a sequence of those matching the specified subclass. Sources: src/flext_api/_protocols/plugin_manager.py:43-52unload_plugin(plugin_name): Triggers the plugin'sshutdownmethod and removes it from the internal registry. Sources: src/flext_api/_protocols/plugin_manager.py:87-95
Integration with HTTP Client
The client.py module utilizes the plugin architecture to enhance the standard httpx client. Plugins allow the client to handle diverse protocols and security requirements without hard-coding logic into the core HTTP flow. Sources: src/README.md, src/flext_api/client.py
The following sequence diagram shows how the Manager interacts with plugins during a typical lifecycle:
Implementation Standards
Plugin implementations must adhere to the following constraints defined in plugin_types.py:
- Strict Typing: All plugin methods use the
p.Resultcontainer for error handling and thet(FlextApiTypes) namespace for data structures. Sources: src/flext_api/_protocols/plugin_types.py:9-12 - Logging: Every plugin is equipped with a standard logger via
u.fetch_logger. Sources: src/flext_api/_protocols/plugin_types.py:31 - No Dead Code: The
Managerincludes a_log_shutdown_warningutility to ensure that even failing shutdowns are recorded without breaking thetap_errorcontract. Sources: src/flext_api/_protocols/plugin_manager.py:97-103
The plugin architecture facilitates the project's goal of providing a high-performance REST API by offloading specialized concerns to interchangeable modules, maintaining a clean core service in api.py. Sources: src/README.md