Phpamqplib Messenger Laravel Package

Product Decisions This Supports

• Async processing architecture: whether to adopt Symfony Messenger + AMQP for background jobs, webhook fan-out, notification delivery, or service decoupling — without making a PHP C extension a hard platform requirement.
• Deployment target selection: expands the set of viable environments (managed PaaS, locked-down base images, CI runners, Windows/dev machines) where PECL installs and build toolchains aren't available. This turns "we can't run queues here" into a solvable problem.
• Build vs. buy vs. default: this is a third option beside Symfony's first-party AMQP transport (ext-amqp) and writing a custom transport. It's a thin TransportFactory swap, so integration cost is low and the decision is reversible — a cheap experiment.
• Dev/prod parity: the same Composer-installed transport runs locally, in CI, and in production, removing "queue works here but not there" drift caused by extension availability.
• Roadmap sequencing: ship a queue-backed feature now on a Composer-only dependency and defer ext-amqp migration/perf work to a later milestone if volume justifies it.

When to Consider This Package

Adopt when:

• You want Symfony Messenger + RabbitMQ and ext-amqp is unavailable, blocked, or operationally undesirable (restricted CI images, Windows dev, managed hosting).
• Your team already uses php-amqplib or needs its connection/channel API surface.
• Volume is modest — job queues, notifications, ETL syncs, webhooks — rather than high-rate event streaming.
• You're comfortable pinning a single-maintainer dependency and owning the integration tests.

Look elsewhere when:

• You have high throughput or tight latency budgets; the C extension generally wins on speed and memory. Benchmark before committing.
• You need first-party vendor support, an SLA, or a large community for a long-lived platform bet. 92 stars and zero public dependents signals early-stage, not maturity.
• You need multiple transports (Redis, Doctrine, SQS) — start from Symfony's own transports and evaluate AMQP independently.
• Your broker vendor offers a native, maintained SDK/transport integration.

Mitigation if adopted: isolate the transport behind your own config/factory, pin a version, and add integration tests against a real broker so swapping to ext-amqp later is a configuration change.

How to Pitch It (Stakeholders)

Executives: A small MIT-licensed library that lets us run background job processing on RabbitMQ without modifying server images or installing PHP extensions. It reduces deployment friction, keeps us on the standard Symfony Messenger abstraction (no lock-in), and costs nothing to trial. Main risk is maintenance — one maintainer, low adoption — mitigated because it's a thin adapter we can replace with Symfony's native transport or our own implementation.

Engineering: A drop-in AMQP transport for Symfony Messenger built on php-amqplib instead of ext-amqp. Same Messenger interfaces, serializer, and middleware stack; essentially a config change. Trade-off: a pure-PHP client is slower than the C extension — fine for typical job-queue volumes, not for high-throughput streaming. Treat it as a pinned, isolated dependency with broker-backed tests, and migrate to ext-amqp later if throughput demands it.