Rabbitmq Bundle Bridge Laravel Package

Product Decisions This Supports

• De-risking an async migration on an existing Symfony estate. If your platform already runs SimpleBus (command/event bus) and OldSoundRabbitMQBundle, this bridge is the piece that lets you move command and event handling off the request cycle and onto RabbitMQ workers — without rewriting handlers or swapping the bus abstraction. That is a concrete, short-horizon reliability and latency win, not a platform bet.
• Build vs. buy (build vs. integrate). The honest read is unchanged: this is thin glue, not infrastructure. It wires a message consumer/producer between two libraries you have already chosen. The buy case rests entirely on avoiding a day or two of bespoke wiring and inheriting the author's conventions for exchange/queue/routing configuration — not on depth of capability.
• Roadmap sequencing: defer the platform rewrite. Adopting this lets you ship async processing now and schedule the SimpleBus → Symfony Messenger migration as a separate, later initiative. The decision it supports is "buy time," and you should record that explicitly so it doesn't silently become "keep forever."
• New: a version-pinning decision, not just an adopt/skip decision. v6.2.0 drops Symfony ^5.2 support. If any service in scope is still on Symfony 5.2 or earlier, you cannot take the current release line — you either pin to the previous major/minor and own that fork, or you treat the framework bump as a prerequisite. That is a scope and sequencing question to answer before the async work is scheduled, not after.
• Use cases it fits: order/payment workflows offloaded to workers, slow third-party integrations moved to background consumers, fan-out of domain events to multiple handlers, retry/backpressure via RabbitMQ queues.
• Use cases it does not fit: anything greenfield, anything needing first-party AMQP support, anything requiring a supported vendor relationship or security-patch commitment.

When to Consider This Package

Consider it when all of the following hold:

1. You are already committed to SimpleBus + AsynchronousBundle and OldSoundRabbitMQBundle in production. The value is purely in the seam between them.
2. You are on Symfony 5.3+ (or 6.x), and on a PHP version compatible with that line. This is a correction to earlier guidance: v6.2.0 dropping Symfony ^5.2 confirms the package tracks the modern Symfony 5/6 line, not the 3/4 era. Verify your actual version matrix against the package's composer.json before committing — the constraint is the gate, not the release note.
3. You need async command/event handling soon, and a bespoke bridge would compete with higher-value roadmap work.
4. You have the engineering capacity to vendor or fork the package — treat it as source you own, not a dependency you rely on upstream for. This remains true even after a fresh release.
5. Your team can accept MIT-licensed glue with no maintainer SLA.

Look elsewhere when:

• Greenfield or mid-migration: use Symfony Messenger with its AMQP transport. It is first-party, maintained, and covers the same ground with better tooling and documentation. Building on this bridge today is building on the exit ramp.
• You are on Symfony 5.2 or earlier and cannot upgrade. v6.2.0 is closed to you; the prior line is. That changes the calculus from "cheap glue" to "cheap glue plus a framework upgrade," and the framework upgrade is the larger commitment.
• You need support or patch guarantees. A fresh release is a mildly positive signal — it is not an SLA, and one compatibility commit does not establish a cadence. With 0 dependents and ~39 stars, you are effectively the maintainer.
• Your stack has already moved off SimpleBus, or you can move off it cheaply. The bridge's entire reason to exist evaporates.
• You need advanced messaging semantics (delayed retry policies, dead-letter orchestration, priority queues, observability hooks). You'll be implementing those yourself on top of a thin adapter.

How to Pitch It (Stakeholders)

To executives: This is a small, free (MIT), narrowly scoped connector that lets our existing message-handling code run asynchronously through RabbitMQ. It buys us background processing — faster page responses, safer retries on flaky third-party calls — without a platform rewrite. Cost is low and the blast radius is contained: it's glue between two libraries we already run. The recent v6.2.0 release dropped Symfony 5.2 support, which tells us two things worth stating plainly: the package is tracking the modern Symfony line, and it now imposes a minimum framework version on us. If we're already past that line, nothing changes and the release is a small positive signal that someone is still watching compatibility. If we're not, the async work carries a framework upgrade in front of it — a cost we should see now rather than discover mid-sprint. The standing caveat holds: no maintainer SLA, so we treat it as code we own and flag consolidation onto Symfony Messenger as a future line item rather than an unstated assumption.

To engineering: It's a thin adapter, not a framework. v6.2.0 is a compatibility release — it drops Symfony ^5.2 — so the actionable item is a composer.json version-matrix check against every service in scope, not a code review of new features (there are none). If you're on 5.3+, upgrade and move on; if you're on 5.2 or below, pin to the previous line and treat that pin as technical debt with an owner. Either way: vendor or fork it, review the handful of service definitions, and write tests around the exchange/queue wiring since upstream won't. Note that the earlier assumption that this package lived in the Symfony 3/4 era was wrong — plan against the 5.3+/6.x constraint. If the version check shows friction, the fallback is either in-house glue (small) or accelerating the Messenger migration (larger, but strategically correct).