Amqp Laravel Package

Product Decisions This Supports

• Build vs. buy for messaging glue. A zero-star, zero-dependent adapter published on Bitbucket is effectively an internal artifact with a public URL. The real decision is whether your team wants to own broker glue (small, patchable surface, no outside signal) or standardize on a maintained ecosystem package. This package is the "own it" end of that spectrum, and the low score means the "buy" case is genuinely competitive.
• Queue transport selection and portability. The adapter pattern it represents — keeping AMQP behind a thin abstraction rather than calling php-amqplib directly — is the architectural question worth answering early. Retrofitting transport portability after job, event, and fan-out codebases exist is materially more expensive than starting with a seam.
• Framework alignment. Despite the package description framing it as Laravel-friendly, the surrounding evidence (Psyllium core, Symfony DI bundle, config/packages/*.yaml) points to a Symfony-oriented stack. That makes this a decision point on which framework's queue semantics we standardize on — Laravel's native Queue/Event contracts plus Horizon, or a Symfony-style messaging abstraction — and whether running both is acceptable debt.
• Roadmap sequencing for async work. If background jobs, event fan-out, or cross-service messaging are on the roadmap, this is a signal to lock transport strategy before feature teams start publishing. The package itself is unlikely to be the answer; the timing pressure it surfaces is real.
• Migration blast-radius planning. If any owned service already depends on a psyllium abstraction, this package defines the scope of an eventual move to Laravel-native queues or Symfony Messenger. That's a scoping input, not an adoption decision.
• Dependency policy. Whether zero-signal, single-vendor, Bitbucket-hosted packages are admissible at all in production is a standing product/engineering policy question. This package is a useful test case for that rubric.

When to Consider This Package

Consider it only when all of the following hold:

• Your codebase already depends on the upstream psyllium messaging abstraction and needs an AMQP transport for it. Without that dependency, this package has no independent value — it is a shim, not a queue system.
• You have reconciled the documentation gap: the package description advertises Laravel-style config, publishing, and consumers, while the implementation and configuration surface appear Symfony/Psyllium-centric. Someone must confirm which one you are actually integrating against before scoping anything.
• A named engineer will own it — reading, patching, and forking as ext-amqp, PHP, and the Psyllium API move. Treat the package as internal code with an external homepage.
• The adapter proves thin in practice (message contract → exchange/queue). If it turns out to contain retry, dead-letter, prefetch, or topology logic, the ongoing ownership cost changes and warrants re-evaluation.
• Vendor access is verified: Packagist resolvability or a pinned Bitbucket VCS reference that CI and production builds can actually reach, plus a license review.

Look elsewhere when:

• You are building a standard Laravel application. Laravel ships first-class queues and workers; vladimir-yuldashev/laravel-queue-rabbitmq or Horizon on Redis is the native, documented, supported path.
• You only need raw AMQP. php-amqplib/php-amqplib gives you the protocol and topology control without an abstraction you did not ask for — and without a second framework's conventions.
• You want a maintained abstraction layer. Symfony Messenger is the community-backed equivalent, and adopting it removes this adapter from the picture entirely.
• You need audit, SLA, or CVE-tracking guarantees. Zero stars, zero dependents, and a score of 0 mean no external quality signal, no compatibility guarantees, and no troubleshooting corpus.
• Your team has no existing Psyllium investment. There is no cost/benefit case for introducing this abstraction solely to gain AMQP.

How to Pitch It (Stakeholders)

One-line summary: A small, single-vendor adapter connecting one niche PHP messaging abstraction to AMQP/RabbitMQ. It is not a queue system, not a Laravel-native transport, and not a strategic dependency.

For executives: Treat this as prior art and a design reference, not a platform commitment. The risk is concentrated: one vendor, one repository, no community, no adoption evidence, and a description that overpromises Laravel support relative to what the package actually appears to be. We should not place roadmap-critical messaging on it. The strategic takeaway is directional and worth acting on now — our async design should keep the transport swappable, and we should standardize on a maintained, hireable stack (Laravel-native queues, or Symfony Messenger if we are in Symfony) rather than inherit an abstraction we cannot staff for. No roadmap capacity recommended; the deliverable is a one-paragraph transport-selection principle and a dependency-admission rubric.

For engineering: If we are already inside Psyllium, this adapter is cheap to evaluate and cheap to fork — budget a spike, not a sprint, and confirm ext-amqp availability and Bitbucket access from CI first. If we are not inside Psyllium, the correct move is to route around it: Laravel-native queues (Horizon/Redis, or SQS) for application jobs, php-amqplib or Symfony Messenger where explicit AMQP topology matters. Either way, put an internal publisher/consumer interface in front of whatever we choose, so transport remains a configuration decision. Log the documentation mismatch as an example of why we verify package claims against composer.json, Configuration.php, and service definitions before scoping work off a README.

Recommendation: Do not adopt as a dependency. Record it as prior art for the "keep messaging transport-agnostic" principle, assign no roadmap capacity, and revisit only if a concrete Psyllium-based integration surfaces in a codebase we already own — at which point the question becomes fork-and-own, not adopt.