Messenger Laravel Package

Technical Evaluation

Architecture Fit

• Symfony Messenger Alignment: The package is a drop-in extension for Symfony’s Messenger component, which can be integrated into Laravel via spatie/laravel-messenger or direct symfony/messenger adoption. Its middleware architecture is highly compatible with Laravel’s event/queue systems, enabling:
  • Decoupled workflows: Replace synchronous logic (e.g., controllers) with async message handlers.
  • Cross-cutting concerns: Middlewares for locking, flushing, and error handling can be reused across domains (e.g., orders, notifications).
• Laravel-Specific Synergies:
  • Queue Workers: Aligns with Laravel’s queue:work for background processing (though custom transport adapters may be needed).
  • Eloquent Integration: While DoctrineFlushMiddleware targets Doctrine, a custom middleware could bridge to Eloquent’s flush() or save() methods.
  • HTTP Error Mapping: UnpackExceptionMiddleware enables clean HTTP status codes (e.g., 422 Unprocessable Entity) for failed jobs, improving API consistency.
• Anti-Patterns to Avoid:
  • Overhead for Simple Workflows: If your app uses fire-and-forget jobs without locking/flushing needs, the package adds unnecessary complexity.
  • Doctrine Dependency: Forces Symfony’s DoctrineBundle if using DoctrineFlushMiddleware (Laravel’s Eloquent would require custom work).

Technical Risk

Key Questions for the TPM

1. Symfony Adoption:

   • Is the team open to partial Symfony integration (e.g., only symfony/messenger) or does this require full Symfony adoption (e.g., for LockMiddleware)?
   • If using Laravel’s native queues, how will we bridge Symfony’s transports (e.g., AMQP) to Laravel’s drivers (e.g., Redis)?

2. Database Strategy:

   • For DoctrineFlushMiddleware, will we migrate to Doctrine or build a custom Eloquent adapter? What’s the effort/risk of the latter?
   • How will locks be implemented if not using Doctrine? Options: file-based (symfony/lock), database (e.g., optimistic_lock column), or Redis.

3. Error Handling:

   • Should UnpackExceptionMiddleware override Laravel’s default job failure behavior (e.g., failed_jobs table) or complement it?
   • What HTTP status codes should failed jobs return (e.g., 422, 500), and how will this integrate with Laravel’s App\Exceptions\Handler?

4. Concurrency Model:

   • What’s the expected concurrency level for locked resources? Will LockMiddleware’s TTLs need tuning (e.g., 5s vs. 30s)?
   • Are there hot paths (e.g., inventory updates) where locks could cause bottlenecks? If so, consider sharding locks by resource type.

5. Migration Path:

   • Will we incrementally adopt this (e.g., start with UnpackExceptionMiddleware for error handling) or big-bang migrate to full message-driven architecture?
   • How will existing cron jobs or immediate API calls transition to async messages?

6. Observability:

   • How will message processing be monitored (e.g., lock acquisition time, flush duration)? Options: Symfony’s Bus events, Laravel’s queue:failed logging, or custom metrics (e.g., Prometheus).
   • Should we add middleware for logging (e.g., message start/end timestamps) or use Laravel’s Queue::after() hooks?

7. Vendor Lock-In:

   • The package is Sulu-specific. Are there alternatives (e.g., symfony/messenger-bundle for idempotency, php-amqplib for advanced AMQP) that could reduce dependency risk?
   • How will future Sulu CMS changes (e.g., breaking updates) impact this package?

Integration Approach

Stack Fit

• Core Compatibility:
  • Laravel 10+: Requires PHP 8.2+ and Symfony Messenger (via spatie/laravel-messenger or direct symfony/messenger).
  • Symfony Messenger: Acts as the message bus backbone, with sulu/messenger adding domain-specific middlewares.
  • Doctrine ORM: Only needed for DoctrineFlushMiddleware (Laravel’s Eloquent would require a custom bridge).
  • Locking Backend: symfony/lock supports file, database, or Redis. For Laravel, Redis or database locks (e.g., optimistic_lock column) are recommended.
• Queue Systems:
  • Laravel Queues: Can integrate via spatie/laravel-messenger’s Symfony transport adapters or custom bridges (e.g., map Laravel’s queue:work to Symfony’s BusInterface).
  • Symfony Transports: If using AMQP, Doctrine, or other transports, ensure spatie/laravel-messenger supports them or build adapters.
• Alternatives Considered:
  • symfony/messenger-bundle: More feature-rich (e.g., idempotency, retry) but heavier.
  • league/amqp: For pure AMQP use cases without Symfony.
  • Laravel’s Native Queues: Sufficient for simple jobs but lacks middleware extensibility.

Migration Path

1. UnpackExceptionMiddleware for error handling (low risk).
2. `