psyllium/amqp
psyllium/amqp brings AMQP/RabbitMQ messaging to Laravel and PHP applications, offering a simple API for publishing and consuming messages, declaring exchanges and queues, and integrating asynchronous workflows into your app.
Architecture fit. The package presents itself as a Laravel-friendly, configuration-driven AMQP wrapper, but the available technical evidence points to a Symfony bundle built on psyllium/psyllium and ext-amqp, with service definitions wired through Symfony's DI container. That distinction matters for a TPM: the description promises Laravel container and configuration conventions, while the implementation detail suggests config/bundles.php registration, YAML config under config/packages/, and Symfony-style service IDs. Before any roadmap commitment, treat the "Laravel package" framing as unverified. Architecturally, the value proposition is legitimate — centralize connections/exchanges/queues in config, publish with minimal boilerplate, consume via workers, keep routing keys flexible. That is the right shape for an async messaging layer. The risk is that the abstraction is a thin shim over ext-amqp, not a first-class Laravel queue driver, so it will not slot into Queue, Event, Broadcast, or the standard worker lifecycle without glue we own.
Integration feasibility. Low to moderate, gated on a short verification spike. Three binary checks determine whether this is even worth a ticket:
ext-amqp already available in our build and runtime images? It requires a PECL extension and librabbitmq-dev; there is no pure-PHP fallback. If our platform images are managed, this is a platform-team request with lead time.Given zero stars, zero dependents, and a composite score of 0, there is no external signal of quality. Due diligence — license, security posture, test coverage, release cadence — must happen before a spike, not after.
Technical risk. High, and concentrated in places a TPM should care about: connection lifecycle, channel recovery, retry and dead-letter behavior, and message serialization compatibility. These are exactly the areas where an unmaintained adapter with no community testing produces subtle, expensive failures — duplicated messages on reconnect, poison messages blocking consumers, payloads that don't round-trip with existing Laravel jobs. The second-order risk is organizational: adopting this makes us the maintainer of record for a package we did not write, on a platform (Bitbucket, single vendor ebrandpl) we do not control. The third risk is strategic drift — introducing a Symfony-flavored messaging abstraction alongside Laravel's native queue system creates two mental models and two operational runbooks for the same problem.
Key questions.
ext-amqp, or does it wrap a userland client like php-amqplib?Queue/Event contracts, or is integration entirely our responsibility?Stack fit. Poor as a default for our Laravel applications, acceptable as a narrow transport adapter if — and only if — Psyllium is already an approved internal standard. Laravel ships a first-class queue system with a mature worker lifecycle, failed-job storage, and Horizon for observability on Redis. The realistic alternatives should be evaluated on the same ticket: a maintained Laravel RabbitMQ queue driver if we need AMQP specifically, php-amqplib directly if we need raw topology control, or Redis/SQS via Horizon if we simply need async work done. The TPM framing for the team: this package is a decision about whether to own a small piece of messaging glue, not a decision about whether to do async messaging.
Migration path. Do not migrate critical queues. Sequence should be: non-critical, low-volume workload → pre-production proof → limited production pilot → phased expansion by workload class (async notifications first, background jobs second, business-critical workflows last). The non-negotiable constraint is that all call sites sit behind an internal publisher/consumer interface we own, so application code never imports Psyllium-specific classes. That single discipline converts an eventual migration from a rewrite into a configuration change, and it is the highest-leverage thing a TPM can insist on here regardless of vendor outcome. Keep the existing Laravel queue driver wired and available as a documented rollback for the duration of the pilot.
Compatibility. Validate in this order: Composer resolution from Bitbucket inside CI, PHP constraint alignment with our runtime images, Laravel/Symfony component conflicts (this is where a Symfony bundle inside a Laravel app typically breaks), ext-amqp availability across dev/staging/prod, and broker compatibility — confirm whether it assumes RabbitMQ-specific features or generic AMQP 0-9-1. Separately confirm it can coexist with Laravel's worker signals, timeouts, and failed-job persistence; if it cannot, we are running two worker paradigms, which is an operational cost, not a technical one.
Sequencing.
Maintenance. Assume we own it. With no stars, no dependents, and no community signal, the practical outcome is an internal fork under our vendor namespace, pinned to a reviewed commit, with a named engineer responsible for PHP/Laravel compatibility bumps and security patches. That is a recurring line item, not a one-time integration cost. Budget it explicitly, or the package quietly rots until it becomes an incident.
Support. Effectively none externally. There is no Stack Overflow corpus, no issue tracker to read, no release notes to diff. Incident resolution speed is entirely a function of whether we have AMQP/RabbitMQ operators and PHP engineers who can open the adapter and patch it at 2am. If we do not have that bench, this package is not supportable at any price.
Scaling. AMQP and RabbitMQ scale well; the adapter is the unknown. Connection and channel management, prefetch configuration, and reconnect behavior determine whether we scale safely or melt the broker under load. None of these characteristics are documented or evidenced by adoption, so load testing is a prerequisite, not a nice-to-have, before any high-throughput workload is placed on this path.
Failure modes. Plan for: message loss or duplication during reconnect; consumers blocked by bad prefetch; poison messages with no clear DLQ path; serialization mismatch with existing Laravel job payloads; worker shutdown issues under Laravel's signal handling; broker outages surfacing as application-level errors rather than clean backpressure. Instrumentation must cover publish failures, consumer lag, redelivery counts, DLQ depth, and reconnect frequency from day one of the pilot — if the adapter does not expose health signals, we build them around it.
Ramp-up. Medium to high. Engineers need AMQP fundamentals, RabbitMQ operations, Psyllium adapter internals, and enough Laravel queue knowledge to reason about the seam between the two. Sparse documentation raises onboarding cost further. The pilot team should include at least one engineer comfortable forking and patching Composer packages and one operator accountable for broker reliability; without both, the pilot is a demo, not a de-risking exercise.
TPM recommendation. Do not adopt psyllium/amqp as the default AMQP path for our Laravel applications, and do not allocate roadmap capacity to it. Log it as prior art supporting a durable architectural principle — keep messaging transport behind our own thin interface so the broker remains a configuration decision. Revisit only if a concrete, already-owned Psyllium integration surfaces, at which point scope it as a fork-and-maintain effort with a named owner, not as a dependency adoption.
How can I help you explore Laravel packages today?