Eventstore Client Bundle Laravel Package

Technical Evaluation

Architecture Fit

• Event Sourcing Alignment: The package enables Symfony 7.3+ integration with KurrentDB, a time-series database optimized for event storage. This aligns well with event-sourcing or CQRS architectures where events are core to domain logic.
• Symfony Ecosystem: Leverages Symfony’s Dependency Injection (DI) and Bundle system, ensuring seamless integration with existing Symfony applications.
• Laravel Considerations:
  • Limited Native Support: Laravel lacks Symfony’s bundle system, requiring workarounds (e.g., manual service registration, custom event listeners).
  • Event Store Abstraction: If Laravel already uses an event store (e.g., Laravel Events, Laravel Echo, or third-party packages like Spatie Event Sourcing), this package may introduce duplication unless refactored for Laravel’s architecture.
  • Time-Series Use Case: If the use case is time-series event logging (e.g., audit trails, user activity), KurrentDB’s strengths (compression, retention policies) could be valuable—but Laravel’s built-in database drivers (MySQL, PostgreSQL) may suffice for simpler needs.

Integration Feasibility

• Symfony → Laravel Translation:
  • Bundles → Service Providers: Replace Symfony bundles with Laravel’s Service Providers to register KurrentDB client services.
  • Event Dispatching: Map Symfony’s EventDispatcher to Laravel’s Event System or Queues (e.g., dispatch() → EventStore::append()).
  • Configuration: Replace Symfony’s config/packages with Laravel’s config/eventstore.php and use environment variables for KurrentDB credentials.
• Database Schema: KurrentDB expects event streams with metadata (e.g., stream_id, event_type, timestamp). Laravel’s Eloquent or Query Builder would need adaptation to emit events in KurrentDB’s format.
• Middleware/Listeners: Symfony’s Kernel Events can be replicated in Laravel via Middleware or Observers.

Technical Risk

Key Questions

1. Why KurrentDB?
   • Does the use case require time-series optimizations (e.g., high write throughput, compression) that Laravel’s default DBs lack?
   • Are there cost/performance tradeoffs vs. PostgreSQL TimescaleDB or InfluxDB?
2. Event Model Design
   • How will Laravel’s events (e.g., ModelCreated, PaymentProcessed) map to KurrentDB’s streams and event types?
   • Will snapshotting (for state reconstruction) be needed, and how will it integrate with Laravel’s caching (Redis)?
3. Fallback Strategy
   • What happens if KurrentDB is unavailable? Will events queue locally (Laravel Queues) or fail silently?
4. Team Expertise
   • Does the team have experience with event-sourcing or Symfony bundles? If not, ramp-up time may increase.
5. Alternatives
   • Could Laravel + PostgreSQL JSONB or EventSauce (PHP event store) achieve similar goals with lower integration risk?

Integration Approach

Stack Fit

• Laravel Compatibility:
  • Core: Works with Laravel 10+ (Symfony 7.3+ compatibility implies modern PHP/Laravel versions).
  • Dependencies:
    • Requires Guzzle HTTP Client (for KurrentDB API calls) → Laravel already includes Guzzle.
    • Symfony Contracts → Can be polyfilled via symfony/contracts package.
    • PSR-15 Middleware → Laravel’s HTTP middleware can wrap KurrentDB calls.
• Non-Laravel Dependencies:
  • If using Symfony Messenger (for async events), Laravel’s Queues can substitute.
  • Doctrine DBAL (used in Symfony bundle) → Replace with Laravel’s Database Manager or Query Builder.

Migration Path

1. Phase 1: Proof of Concept (PoC)

   • Goal: Validate KurrentDB’s fit for Laravel’s event model.
   • Steps:
     • Create a custom Laravel service provider to register the KurrentDB client.
     • Implement a trait/mixin for Eloquent models to append events to KurrentDB.
     • Test with a single event type (e.g., UserRegistered).
   • Tools: Use Laravel’s Artisan commands to simulate event writes.

2. Phase 2: Core Integration

   • Goal: Replace existing event storage with KurrentDB.
   • Steps:
     • Event Dispatcher Wrapper: Create a Laravel event listener that forwards events to KurrentDB.
     • Schema Migration: Add KurrentDB-specific metadata (e.g., stream_id as a model attribute).
     • Query Layer: Build a repository pattern to read events from KurrentDB (e.g., EventStore::getEventsForStream($streamId)).
   • Tools: Laravel’s Migrations for schema changes; Factories for test events.

3. Phase 3: Optimization & Fallbacks

   • Goal: Ensure reliability and performance.
   • Steps:
     • Implement retries (Laravel Queues) for failed KurrentDB writes.
     • Add local caching (Redis) for frequently accessed events.
     • Benchmark write/read latency vs. existing storage.
   • Tools: Laravel’s Queue Workers, Cache, and Horizon (if using queues).

Compatibility

Sequencing

1. Prerequisites:
   • Laravel 10+ with PHP 8.1+.
   • KurrentDB account and API credentials.
   • Existing event model (or design one for PoC).
2. Core Implementation:
   • Add dbellettini/eventstore-client-bundle to composer.json (or fork/adapt for Laravel).
   • Create EventStoreServiceProvider to bind KurrentDB client.
   • Implement EventStoreFacade for clean syntax (e.g., EventStore::append()).
3. Event Integration:
   • Modify event emitters to use EventStore instead of event().
   • Add stream_id to relevant models (e.g., user_id for user events).
4. Read Model:
   • Build a EventStoreRepository to query KurrentDB.
   • Sync with Laravel’s caching layer if needed.
5. Testing:
   • Unit tests for event writing/reading.
   • Load test with high event volumes.
6. Deployment:
   • Configure KurrentDB credentials in .env.
   • Set up monitoring for KurrentDB latency/errors.

Operational Impact

Maintenance

• Pros:
  • MIT License: No legal restrictions; easy to fork/modify.
  • Time-Series Optimized: Reduced storage costs for high-volume event logs.
  • Symfony Heritage: Battle-tested in production (assuming KurrentDB’s stability).
• Cons:
  • Custom Laravel Layer: Maintenance burden for non-Symfony-specific code.
  • Dependency on KurrentDB: Vendor-specific optimizations may require updates if KurrentDB changes its API.
  • Debugging: Limited Laravel-specific documentation; rely on Symfony bundle as reference.

Support

• Community:
  • Low Activity: 3 GitHub stars → expect limited community support.
  • Workarounds: May need to contribute fixes or fork the package.
• KurrentDB Support:
  • Rely on KurrentDB’s official docs/support for database-specific issues.