Pubsub Router Bundle Laravel Package

Technical Evaluation

Architecture Fit

• Event-Driven Alignment: The bundle excels in Symfony-based Laravel-like architectures where event-driven workflows (e.g., queues, real-time updates) are critical. It bridges Pub/Sub channels (e.g., RabbitMQ, AWS SNS/SQS, Google Pub/Sub) with business logic handlers, mirroring Laravel’s event/listener pattern but with explicit routing.
• Decoupling: Enables clean separation between message producers/consumers and handlers, reducing tight coupling in microservices or modular monoliths. Aligns with Laravel’s service container and dependency injection.
• Routing Flexibility: Supports dynamic routing (e.g., topic-based, attribute-based) via annotations/YAML/XML, which can be adapted to Laravel’s configuration files (e.g., config/pubsub.php) or service providers.
• Laravel Gaps: Laravel lacks a native Pub/Sub router; this bundle fills that gap by providing structured message dispatching akin to Laravel’s Bus or Events, but for external brokers.

Integration Feasibility

• Symfony Dependency: High risk for Laravel due to:
  • Symfony’s DependencyInjection (DI) container vs. Laravel’s Container/Service Provider.
  • Symfony’s EventDispatcher vs. Laravel’s Events/Listeners.
  • Mitigation: Use Symfony’s Bridge components (e.g., symfony/dependency-injection, symfony/event-dispatcher) or wrap the bundle in a Laravel-compatible facade.
• Broker Agnosticism: Supports any Pub/Sub system (RabbitMQ, Kafka, AWS, etc.), but Laravel’s native queue drivers (e.g., redis, database) may require adapter layers.
• Configuration Overhead: Requires route definitions (YAML/XML), which can be replaced with Laravel’s service container bindings or tagged services.

Technical Risk

Key Questions

1. Broker Compatibility:
   • Does the target Pub/Sub system (e.g., RabbitMQ, AWS SQS) align with Laravel’s queue drivers? If not, what’s the adapter effort?
2. Routing Strategy:
   • Should routes be static (config files) or dynamic (database-driven)? How does this interact with Laravel’s service container?
3. Error Handling:
   • How will failed message processing (e.g., dead-letter queues) be handled? Does this require custom middleware?
4. Performance:
   • What’s the overhead of routing vs. direct queue listeners? Is batching supported?
5. Testing:
   • How will the bundle’s Symfony-centric tests translate to Laravel’s testing tools (e.g., Pest, PHPUnit)?
6. Long-Term Viability:
   • Is the bundle’s 2.x maintenance sustainable? Should a Laravel fork be considered?

Integration Approach

Stack Fit

• Core Fit: Ideal for Laravel apps using:
  • External Pub/Sub systems (not just Laravel queues).
  • Complex event routing (e.g., multi-tenant, feature flags).
  • Symfony-like DI (e.g., apps using spatie/laravel-symfony-components).
• Poor Fit: Avoid if:
  • Using only Laravel’s native queues (no external brokers).
  • Team lacks Symfony DI experience.
  • Need real-time reactivity (consider Laravel WebSockets + Echo instead).

Migration Path

1. Phase 1: Proof of Concept

   • Install via Composer in a sandbox project:

     composer require gos/pubsub-router-bundle
     

   • Test with a single route (e.g., topic.user.created → UserCreatedHandler).
   • Replace Symfony’s services.yaml with Laravel’s AppServiceProvider bindings.

2. Phase 2: Adapter Layer

   • Create a Laravel facade to abstract Symfony’s Router:

     // app/Providers/PubSubServiceProvider.php
     use Gos\PubSubRouterBundle\Router\RouterInterface;
     
     public function register()
     {
         $this->app->singleton(RouterInterface::class, function ($app) {
             return new LaravelRouterAdapter($app['config']['pubsub.routes']);
         });
     }
     

   • Implement broker adapters (e.g., AwsSqsAdapter, RabbitMqAdapter).

3. Phase 3: Route Integration

   • Replace YAML/XML routes with Laravel config:

     // config/pubsub.php
     'routes' => [
         'user.created' => [
             'handler' => \App\Handlers\UserCreatedHandler::class,
             'priority' => 10,
         ],
     ],
     

   • Use service tags for dynamic discovery:

     $this->app->tag([UserCreatedHandler::class], ['pubsub.handler']);
     

4. Phase 4: Testing & Optimization

   • Mock Pub/Sub messages in Laravel’s TestCase.
   • Benchmark routing overhead vs. direct queue listeners.

Compatibility

Sequencing

1. Start Small: Implement one critical route (e.g., order processing).
2. Gradual Replacement: Migrate from raw queue listeners to routed handlers.
3. Monitor: Track latency and error rates during transition.
4. Document: Create a Laravel-specific guide for onboarding.

Operational Impact

Maintenance

• Pros:
  • Centralized routing logic reduces duplicate handler code.
  • Symfony’s maturity ensures stability (if DI is abstracted well).
• Cons:
  • Symfony dependency adds maintenance burden (e.g., updates, debugging).
  • Route management may require new CLI tools or database migrations.
• Mitigation:
  • Use Laravel Artisan commands to manage routes.
  • Document Symfony-specific quirks in the codebase.

Support

• Learning Curve:
  • Team must understand Pub/Sub routing patterns and Symfony DI.
  • Training: Pair developers with Symfony experience or provide workshops.
• Debugging:
  • Complex stack traces may arise from Symfony-Laravel interactions.
  • Solution: Implement structured logging (e.g., Monolog) for route matching.
• Community:
  • Limited Laravel-specific support; rely on Symfony docs or fork the bundle.

Scaling

• Performance:
  • Routing overhead: Minimal if routes are cached (Symfony’s Router supports caching).
  • Broker bottlenecks: Depends on external Pub/Sub system (e.g., AWS SQS throughput).
• Horizontal Scaling:
  • Stateless design: Routes can scale with Laravel’s queue workers.
  • Database-backed routes: Enable dynamic scaling (e.g., feature flags).
• Load Testing:
  • Simulate high-throughput topics (e.g., 10K messages/sec) to validate routing latency.

Failure Modes

Ramp-Up

• **Onboarding