Burrow Laravel Package

Product Decisions This Supports

• Build vs. buy on messaging plumbing. Burrow answers a narrow question — "should we write our own AMQP transport layer?" For a team that needs the same publish/admin code path across php-amqplib and the ext-amqp C extension, it is a credible buy: a small, MIT-licensed driver factory plus exchange/queue helpers, publish/consume abstractions, and a handler stack. For everyone else the answer is no, and the decision this package actually drives is "adopt the Laravel queue system with a maintained RabbitMQ driver instead."
• Transport portability as a roadmap hedge. The one genuinely differentiating capability is driver unification. That is a roadmap decision about optionality: do we want the freedom to move from pure-PHP to the C extension (or back) for throughput or deployment reasons without rewriting integration code? If that option has real value, Burrow is cheap insurance behind an interface. If it doesn't, it's premature abstraction.
• Scope boundary for "async work" epics. Use this evaluation to explicitly split the backlog: (a) transport/adapter work, which Burrow can address, versus (b) queue semantics — retries, backoff, dead-lettering, failed-job storage, idempotency, publisher confirms, worker supervision, observability dashboards. Burrow gives us almost none of (b). Feature estimates must reflect that (b) is ours to build, not something we inherit.
• Observability as a first-class requirement. Burrow ships event hooks (daemon started/stopped, message received/consumed) and built-in StatsD/DogStatsD metric publishers, including processing-time timing. That's a concrete input to an SLO/alerting roadmap: message lag, consumption throughput, and per-message processing time can be instrumented without bespoke code — a real, if small, accelerator.
• Operational tooling scope. CLI commands for declaring/deleting exchanges and queues exist, which supports a decision on whether provisioning is done by app code, deploy scripts, or ops/IaC. Product stance: keep topology in infrastructure-as-code, use the library only for runtime publishing/consuming.
• Vendor-risk and exit-cost decisions. With 3 stars, 0 dependents, and no release since October 2021, this is a dependency ownership decision, not just a technical one. Choosing Burrow means choosing to own a fork. That belongs in the roadmap as a recurring maintenance line item with a named owner and a scheduled "replace or maintain" review — not as a one-off install.

When to Consider This Package

Consider it when:

• The requirement is explicitly transport abstraction: you must support both php-amqplib and ext-amqp (e.g. some environments can't install the PECL extension, others need its performance), and you want that swap to be a config change rather than a refactor.
• You are on a non-Laravel or Symfony-style PHP codebase already using raw AMQP, where Laravel's queue abstraction isn't available and you'd otherwise hand-roll the driver layer.
• The integration surface is small and low-risk — notifications, audit/event fan-out, non-critical async side effects — and you can tolerate building retry, DLQ, and idempotency yourselves.
• You are willing to vendor/fork it into a private repository with relaxed PHP and php-amqplib constraints, pin it exactly, and assign an owner. (A 1–2 day spike proving publish/consume on your target PHP version — with no --ignore-platform-reqs — is the gate.)
• You need lightweight metrics on consumers quickly and StatsD/DogStatsD is already your observability path.

Look elsewhere when:

• You are building a Laravel application and the real need is "we need async jobs." Use the Laravel queue system with a maintained RabbitMQ driver; you get retries, failed-job handling, worker management, and batching for free. Burrow gives you none of that and is not a Laravel package — no service provider, no publishable config, no queue driver, no Horizon integration.
• You need publisher confirms, dead-lettering, delayed retries, or exactly-once-ish/idempotent consumption out of the box. You will be building these on top, and the abstraction may hide the transport behaviours you need to control.
• Your platform is PHP 8.2/8.3 and current php-amqplib v3 — expect constraint surgery. If pinning old transitive dependencies or patching composer.json is unacceptable (it usually is in production), stop here.
• You require vendor support, a security-response process, a deprecation policy, or a community to validate behaviour. None exist here.
• The flow is on a critical path (payments, order state, anything where silent message loss is a customer-visible incident). Prove it on a low-risk flow first, or not at all.
• The team lacks AMQP depth and no one can debug channel/ack/heartbeat semantics. This package will not absorb that complexity for you.

How to Pitch It (Stakeholders)

For executives — one paragraph. Burrow is a small, free, MIT-licensed PHP library that lets our code talk to RabbitMQ the same way whether we use the standard PHP client or a faster native extension. It's most useful if we specifically need that flexibility and don't want to write the plumbing twice. It is not a queue framework: it doesn't give us job retries, failed-job handling, or dashboards, so those remain our work. It is also unmaintained — three stars, no dependents, no release since October 2021 — which means if we adopt it, we own it permanently. Recommendation: evaluate only if transport portability is a real requirement; otherwise standardize on the Laravel queue system with a maintained RabbitMQ driver. Either way, the cost is bounded and reversible if we keep the library behind our own interface.

For engineering — the honest summary. Small, legible, framework-agnostic abstraction over php-amqplib and ext-amqp: driver factory, exchange/queue declare-and-bind helpers, sync and async publishers, a daemon/worker with pluggable handler stacks, League\Event hooks, and built-in StatsD/DogStatsD metrics. Good news: the surface is shallow, so replacing it later is a one-class change if we enforce the boundary now. Bad news: 2021 dependency constraints will fight PHP 8.2+ and php-amqplib v3; the CI badges no longer mean anything; v4.0 was a near-total breaking change with no migration guide beyond release notes, so expect behavioural surprises between the two driver paths (acks, confirms, reconnects). And it solves publishing/consuming — not retries, dead-lettering, idempotency, or connection health.

The ask. Approve a 1–2 day spike: define a narrow internal MessagePublisher/MessageConsumer port, implement it with Burrow, publish and consume one message against a real RabbitMQ container on our target PHP version, and confirm zero constraint hacks. If it passes, pilot on one low-risk async flow (notifications, audit events) with a named owner, a vendored/pinned fork, Dependabot against the fork, and a scheduled replace-or-maintain review. If it fails, we've spent two days and we default to the Laravel queue route with a clean interface already in place — which is the outcome I'd bet on.