Amqp Bundle Laravel Package

Product Decisions This Supports

• Build vs. buy for messaging infrastructure: This bundle is thin glue between Symfony 2's service container and Swarrot (an AMQP abstraction over php-amqplib). Its existence is evidence that AMQP integration in PHP is a well-trodden, commoditized problem — a strong signal to buy/integrate (managed broker plus a maintained client library) rather than build a bespoke messaging layer.
• Roadmap hygiene and legacy triage: Because the package is archived, last released in January 2018, and targets Symfony 2, it functions as a migration input, not a new dependency. If it appears in a codebase inventory, it should trigger a modernization workstream (Symfony 2 → supported Symfony, Swarrot → Symfony Messenger or equivalent).
• Architecture reference, not runtime dependency: The bundle's design (consumer/producer registration, connection and exchange configuration as DI parameters) is useful as a pattern reference when specifying how messaging should be configured and wired into a service container.
• Feature scoping for async work: If the roadmap includes background jobs, event fan-out, or decoupling of slow tasks, this package clarifies the minimum viable feature set (queues, exchanges, retry/dead-letter handling, consumer lifecycle) that any replacement must cover — useful for writing acceptance criteria against a modern alternative.
• Dependency and risk scoring: Zero dependents, three stars, and archived status make it a useful calibration point for internal "approved dependency" policies — i.e., what a disqualified package looks like.

When to Consider This Package

Consider it only under narrow, constrained conditions:

• You are maintaining an existing Symfony 2 application that already depends on Swarrot, and this bundle is already installed. In that case, the decision is "keep or fork," not "adopt."
• You need a documented example of the producer/consumer wiring pattern for an AMQP topology and want to read, not install, the source.
• An internal fork is acceptable and you have an owner willing to absorb maintenance: Symfony 2 is end-of-life, PHP-version compatibility will be a recurring tax, and there is no upstream to patch security or protocol issues.

Look elsewhere when:

• Any new build or greenfield service. Use Symfony Messenger (with the AMQP transport), Enqueue, or php-amqplib directly. These have active maintenance, modern PHP support, and documented upgrade paths.
• You need vendor support, SLAs, or a security response process. A 2018 archived repository with a single-digit star count provides none of these.
• You require Symfony 4/5/6/7 compatibility, PHP 8.x, or compatibility with modern Symfony autowiring and attributes.
• Your team expects observable tooling — health checks, structured logging, metrics, and dead-letter/retry semantics out of the box.
• You are evaluating "should we adopt this open-source project" in any formal sense: the opportunity signal is weak, and the cost of ownership (fork, audit, upgrade) almost certainly exceeds the value of the small amount of glue it provides.

How to Pitch It (Stakeholders)

To executives: We evaluated wisembly/amqp-bundle as a candidate for our messaging layer and recommend against adoption. It is archived, its last release was in 2018, it targets a Symfony version that reached end-of-life years ago, and it has effectively no user base. Adopting it would mean taking on maintenance of an abandoned component with no security or upgrade path — an ongoing cost with no differentiating return. Instead, we should use it as evidence that message brokering is a solved, commodity capability: we standardize on a maintained client library and, where budget allows, a managed broker, and we spend our engineering effort on the business events flowing through it rather than the plumbing.

To engineering: Treat this repository as a reference design, not a dependency. Its value is the pattern — declarative connection/exchange/queue configuration plus producer and consumer wiring — which we should reproduce using Symfony Messenger's AMQP transport or a comparable maintained library. If it exists anywhere in our estate today, log it as technical debt with an owner and a target migration date; if it does not, do not introduce it. Any proposal to fork it needs an explicit named maintainer, a security patching plan, and a stated reason why the maintained alternatives are insufficient.