Swarrot Bundle Laravel Package

Product Decisions This Supports

• Build vs. buy for async processing plumbing. The bundle is a thin DI/config layer over swarrot/swarrot (the consumer/publisher library). Adopting it means we buy the worker lifecycle and middleware plumbing (MIT, zero cost) and only build our own ProcessorInterface classes — one class per message type, registered as a Symfony service.
• Consumer reliability as a configured, reviewable decision. Retry (retry_attempts, retry_exchange, routing-key pattern), ack/requeue policy, exception catching, max-messages, max-execution-time and memory-limit cutoffs are declared per consumer in YAML/PHP config. That turns "how do we handle poison messages and restarts?" from tribal knowledge into code review, which is exactly the kind of decision a PM can point at in a postmortem.
• Operational safety for long-running workers. Signal handling, services_resetter, and Doctrine connection/object-manager re-ping address the classic "worker died at 3am" and "stale DB connection after idle" failure modes — decide whether we need these controls before committing to an architecture.
• Per-domain message topology. messages_types (connection + exchange + routing key, overridable at publish time) and one generated swarrot:consume:<consumer> command per consumer let us scope ownership per team/domain and give each consumer a human-friendly command alias instead of raw AMQP wiring.
• Scope boundary as a product decision. The README explicitly refuses to manage broker configuration (exchanges, queues, bindings) and points to odolbeau/rabbit-mq-admin-toolkit. That is a clean separation to adopt: application owns consuming, infrastructure owns topology.
• Testability as a shipped feature. BlackholePublisher swaps out publishing in the test environment — no broker needed for CI, which directly affects developer velocity and CI cost.
• Escape hatches that de-risk the bet. Custom providers via the swarrot.provider_factory tag (e.g. Redis) and custom processor configurators mean the abstraction is not AMQP-locked, so a broker migration is a config change rather than a rewrite.

When to Consider This Package

Consider it when:

• We are a Symfony shop (this is a Symfony bundle — it does not apply to Laravel; Laravel's equivalents are native queue workers + Horizon/Supervisor). On Laravel, the honest comparison is php-amqplib + a custom worker command, or SQS/Redis via the framework's queue component.
• We are on PHP ≥ 8.2 and Symfony ≥ 6.4 (v2.7.0 dropped older versions; Symfony 8.0 supported) — the release cadence in the changelog shows a maintainer tracking framework upgrades, which is the main longevity signal here.
• We already run, or plan to run, RabbitMQ with a small number of consumers (< ~10) where a hand-rolled worker is genuinely more work than this config.
• We want declarative middleware ordering per consumer rather than duplicating try/catch/retry logic in every handler.
• We are comfortable owning the integration: there is no support contract, only a README and CHANGELOG.

Look elsewhere when:

• Greenfield Symfony and no legacy Swarrot estate. Symfony Messenger is first-party, has an AMQP transport, retry/failure transport, middleware, and a far larger community. Choosing Swarrot here is choosing an ecosystem of 90 stars and (per the dependency data) no notable downstream dependents.
• Laravel or a mixed-framework organisation. Do not introduce this; standardise on framework-native queues to avoid two async paradigms in one company.
• We need managed topology, monitoring, or an ops UI. This bundle deliberately does not configure brokers and ships no dashboard; pair with RabbitMQ management/failure-queue tooling or you will build it.
• We need typed/serialized messages, scheduling, or batching. Those are Messenger/queue-component features; here they are our code.
• Bus-factor tolerance is low. One primary maintainer, near-zero dependents, and no security-response process is a real risk for a system on the critical path — mitigate with a pinned version and a documented exit path, or avoid.

How to Pitch It (Stakeholders)

To executives: This is a zero-cost, MIT-licensed integration layer for an existing, functioning PHP library — not a platform bet. It lets us add background message processing to our Symfony application with roughly one service class and a config block per message type, including retry, error handling, graceful shutdown and memory limits that we would otherwise write and maintain ourselves. There is no vendor lock-in: the underlying library and broker are both replaceable, and the bundle supports non-AMQP providers. The cost is low and reversible; the main caveat is that it is a small, single-maintainer open-source project, so we should pin the version and budget a modest amount of internal ownership rather than assume external support.

To engineering: It buys us DI wiring, auto-generated swarrot:consume:<name> commands, and a per-consumer middleware stack (signal handling, max-messages/execution-time, memory limit, Doctrine reconnect, exception catcher, ack, retry) that is configured rather than coded. We write ProcessorInterface implementations and register them as services; ordering in the stack is meaningful and explicit. Tests avoid the broker entirely via BlackholePublisher. Prerequisites: PHP 8.2+, Symfony 6.4+, and a decision on pecl amqp vs php-amqplib (the latter removes an extension from our build image). Known gaps we must own: broker topology provisioning, failure-queue inspection, and throughput/serialization concerns. If we are starting fresh with no existing Swarrot code, we should benchmark this against Symfony Messenger before committing — the exit path is clean, but the community support is not comparable.