- Can I use broadway/broadway-saga in Laravel without event sourcing?
- No, this package requires Broadway’s event-sourcing foundation. If your Laravel app doesn’t already use event sourcing (e.g., spatie/laravel-event-sourcing), you’ll need to adopt Broadway first, which adds complexity. Consider alternatives like spatie/laravel-transactional-messages if event sourcing isn’t a priority.
- How do I handle Laravel’s Eloquent ORM with Broadway’s Doctrine DBAL?
- Broadway relies on Doctrine DBAL, so Eloquent won’t work directly. Use the laravel-doctrine/orm bridge or refactor to Doctrine’s EntityManager. Alternatively, implement a repository pattern to abstract persistence. This is a common hurdle when integrating Broadway with Laravel.
- Will this work with Laravel’s native queue system (e.g., Redis, database)?
- Yes, but with caveats. Broadway Saga dispatches commands via its own command bus, which can coexist with Laravel’s queue system. For hybrid setups, create a command bus adapter to route Saga commands through Laravel’s queues while keeping Broadway’s event sourcing intact. Test performance under load.
- How do I test sagas in Laravel’s PHPUnit?
- Testing sagas requires mocking Broadway’s command bus and event store. Use PHPUnit’s mock builder to simulate event emissions and command dispatches. For complex workflows, consider a testing library like Broadway’s built-in test utilities or custom fixtures. Idempotency and compensating actions should be unit-tested in isolation.
- What Laravel versions does broadway/broadway-saga support?
- The package itself is PHP-based and Laravel-agnostic, but compatibility depends on Broadway (broadway/broadway) and Doctrine DBAL. Ensure your Laravel version supports PHP 8.0+ (Broadway’s minimum) and has no conflicts with Doctrine’s Laravel bridge. Check the Broadway package’s docs for exact PHP/Laravel constraints.
- How do rollbacks (compensating transactions) work in Laravel?
- Broadway Saga handles rollbacks via compensating commands triggered by failed steps. In Laravel, ensure these commands integrate with your transaction manager—either by wrapping them in Laravel’s `DB::transaction()` or using Broadway’s event-sourced rollback logic. Race conditions may occur if Laravel’s transactions don’t align with Broadway’s event persistence.
- Is there a simpler alternative for Laravel workflows?
- Yes, if sagas are overkill, consider spatie/laravel-transactional-messages for simpler workflows or Laravel’s native queues with custom compensating logic. For distributed transactions, packages like laravel-ignition’s process managers or even database-level transactions (with retries) might suffice for less complex scenarios.
- How do I monitor sagas in Laravel Horizon or Sentry?
- Broadway Saga doesn’t integrate natively with Horizon or Sentry, so you’ll need custom logging. Extend Broadway’s event store to log saga lifecycle events, then forward them to Sentry or Horizon via Laravel’s logging channels. For Horizon, create a custom job processor to track saga progress in the dashboard.
- What’s the performance impact of using Broadway Saga in production?
- Performance depends on your event store and transport (e.g., Doctrine DBAL vs. Redis). Broadway Saga adds overhead for state persistence and command dispatching. Benchmark with your expected workload—long-running sagas may benefit from optimized event storage (e.g., a dedicated database) or async processing via Laravel’s queues.
- Do I need to rewrite existing Laravel workflows to use sagas?
- Not necessarily. Start with a proof of concept for one critical workflow, then gradually migrate others. Use Laravel’s queue system for non-saga jobs and route saga-specific commands through Broadway. This hybrid approach minimizes disruption while validating the integration before full adoption.