 |
VOOZH | about |
|
VOOZH | about |
This document explains how the Hypervel Redis library integrates with the Hyperf framework through its ConfigProvider class. It covers the dependency injection override mechanism, the bootstrap registration process, and how the custom RedisPool implementation replaces Hyperf's default pool to enable Laravel-style Redis API transformations.
For information about the Laravel-style transformations enabled by this integration, see Laravel-Style Redis Connection. For configuration of multiple Redis pools, see Multi-Pool Configuration.
The Hypervel Redis library integrates with Hyperf using a non-invasive approach that leverages Hyperf's built-in configuration provider system. The integration consists of two primary components:
| Component | File | Purpose |
|---|---|---|
ConfigProvider | src/ConfigProvider.php | Registers dependency overrides with Hyperf's DI container |
RedisPool | src/RedisPool.php | Custom pool implementation that creates RedisConnection instances |
The integration strategy centers on overriding Hyperf's default RedisPool class without requiring any modifications to the Hyperf framework itself. This ensures compatibility across Hyperf versions and allows the library to be added or removed cleanly.
Sources: src/ConfigProvider.php1-19 src/RedisPool.php1-16
The ConfigProvider class is the entry point for Hyperf framework integration. It follows Hyperf's configuration provider pattern by implementing the __invoke() method:
namespace: Hypervel\Redis
class: ConfigProvider
method: __invoke(): array
The class is automatically discovered by Hyperf during application bootstrap through Composer's PSR-4 autoloading mechanism and the extra.hyperf.config section in the library's composer.json.
Sources: src/ConfigProvider.php9-18
The __invoke() method returns a configuration array with a single key: dependencies. This array defines dependency injection bindings that override Hyperf's default implementations:
'dependencies' => [
HyperfRedisPool::class => RedisPool::class,
]
This configuration tells Hyperf's DI container: "Whenever any code requests an instance of Hyperf\Redis\Pool\RedisPool, provide an instance of Hypervel\Redis\RedisPool instead."
Key aspects of this override:
| Aspect | Description |
|---|---|
| Scope | Global - affects all Redis pool instantiations |
| Original Class | Hyperf\Redis\Pool\RedisPool |
| Replacement Class | Hypervel\Redis\RedisPool |
| Inheritance | Replacement extends original, maintaining interface compatibility |
| Impact | Changes connection creation behavior throughout the application |
Sources: src/ConfigProvider.php14-15 src/RedisPool.php10
The following diagram illustrates how Hyperf discovers and registers the ConfigProvider during application startup:
Sources: src/ConfigProvider.php11-18
The configuration provider pattern used by Hyperf allows libraries to self-register their services, middleware, listeners, and dependency overrides. The ConfigProvider returns a structured array that Hyperf processes during bootstrap.
Standard ConfigProvider array structure:
[
'dependencies' => [...], // DI bindings
'commands' => [...], // CLI commands
'annotations' => [...], // Annotation scanning
'listeners' => [...], // Event listeners
'publish' => [...], // Publishable assets
]
The Hypervel Redis library uses only the dependencies key to register its single override, keeping the integration minimal and focused.
Sources: src/ConfigProvider.php13-16
This diagram maps the dependency override mechanism to specific code entities:
Sources: src/ConfigProvider.php14-15 src/RedisPool.php12-15
The dependency override affects three primary instantiation paths:
When code explicitly resolves HyperfRedisPool::class from the container:
When classes type-hint HyperfRedisPool in their constructors:
The most important impact is on Hyperf's PoolFactory::make() method, which is used internally to create pool instances. When the factory creates a pool, the DI container resolves the binding and instantiates Hypervel\Redis\RedisPool instead of the default.
Sources: src/RedisPool.php10
The Hypervel\Redis\RedisPool class extends Hyperf\Redis\Pool\RedisPool, ensuring full compatibility with Hyperf's pooling infrastructure:
Inheritance chain:
Hypervel\Redis\RedisPool
extends Hyperf\Redis\Pool\RedisPool
extends Hyperf\Pool\SimplePool\Pool
implements Hyperf\Contract\PoolInterface
This inheritance strategy means:
Sources: src/RedisPool.php10
The sole customization in RedisPool is the createConnection() method:
This method override is the critical integration point that enables Laravel-style API transformations. Instead of creating Hyperf's default RedisConnection, it instantiates Hypervel\Redis\RedisConnection, which provides the transformation layer.
Method signature analysis:
| Element | Value | Notes |
|---|---|---|
| Visibility | protected | Called internally by parent pool |
| Return type | ConnectionInterface | Hyperf's connection interface |
| Parameters | None | Uses inherited properties |
| Dependencies | $this->container, $this, $this->config | Passed to connection constructor |
Sources: src/RedisPool.php12-15
The following diagram shows how connections are created and managed at runtime after the ConfigProvider has registered the override:
Sources: src/RedisPool.php12-15
The ConfigProvider enables Laravel-style Redis operations through a chain of integration points:
| Layer | Component | Role |
|---|---|---|
| Bootstrap | ConfigProvider::__invoke() | Registers dependency override |
| Container | DI Container | Resolves HyperfRedisPool → RedisPool |
| Pooling | RedisPool::createConnection() | Creates RedisConnection instances |
| Transformation | RedisConnection | Provides Laravel-style API (see Laravel-Style Redis Connection) |
| Execution | phpredis extension | Executes native Redis commands |
This layered approach ensures that:
Sources: src/ConfigProvider.php1-19 src/RedisPool.php1-16
The ConfigProvider class has minimal dependencies:
The import uses an alias (HyperfRedisPool) to distinguish Hyperf's pool class from Hypervel's RedisPool class within the same namespace. This aliasing is necessary because both classes share the same short name.
Sources: src/ConfigProvider.php5-7
The RedisPool class requires two imports:
ConnectionInterface: Return type for createConnection() methodHyperfRedisPool: Parent class referenceSources: src/RedisPool.php7-8
To verify that the ConfigProvider has successfully registered the override, you can inspect the DI container at runtime:
To verify that RedisConnection instances are being created:
Sources: src/RedisPool.php12-15
The library overrides RedisPool rather than RedisConnection directly because:
| Approach | Reason Not Used |
|---|---|
| Direct connection override | Hyperf doesn't resolve connections through DI container |
| Factory override | Would require more extensive changes to Hyperf's instantiation flow |
| Wrapper pattern | Would add unnecessary complexity and performance overhead |
| Event-based replacement | Would be less reliable and harder to debug |
The chosen approach—override at the pool level—provides the cleanest integration with minimal complexity.
Sources: src/ConfigProvider.php14-15 src/RedisPool.php10-15
The Hyperf integration is achieved through two simple but strategically placed classes:
RedisConnection instancesThis integration enables Laravel-style Redis API transformations (documented in Laravel-Style Redis Connection) throughout the application without requiring any modifications to the Hyperf framework itself. The approach is non-invasive, maintainable, and compatible across Hyperf versions.
Refresh this wiki