Product Decisions This Supports
- Build vs buy on background processing. This is an SDK, not a queue. The real decision is whether to buy into the RoadRunner runtime plus a broker (RabbitMQ, SQS, Kafka, Beanstalk, NATS) versus adopting Laravel Horizon, Symfony Messenger, or hand-rolled workers. The package itself is free and MIT-licensed; the total cost is operational — running RoadRunner, configuring the broker, supervising workers.
- Feature scoping for anything with a latency budget. Transactional email, PDF/invoice generation, image and media processing, webhook fan-out and retries, CSV imports/exports, third-party API sync, search indexing, notification fan-out, ML scoring. Any feature where the user should not wait on the work.
- Roadmap sequencing for the runtime. If RoadRunner is under consideration for performance reasons (persistent workers, no per-request bootstrap), queue consumption is the strongest justification for adopting it. Evaluate this package in the same phase, not after.
- Broker strategy as an architecture decision. Because broker choice lives in configuration rather than application code, this lets you standardize on an existing broker instead of adding Redis purely to satisfy a queue library.
- Product-visible async APIs. Enables an "accepted, here is a job id, poll for status" pattern as a first-class API primitive — a product capability, not just infrastructure.
- Make vs integrate for reliability features. The SDK does not ship retry policies, dead-letter queues, dashboards, or alerting. Those must be funded as separate roadmap items (observability, DLQ tooling, runbooks), or the team will quietly rebuild them.
When to Consider This Package
Consider it when:
- You already run, or are committed to running, RoadRunner as the PHP application server with the queues plugin enabled.
- You need persistent PHP workers consuming at throughput where per-job framework bootstrap is a measurable bottleneck.
- Broker portability matters, or you must interoperate with services written in other languages on an existing broker.
- You want a small, framework-agnostic surface with no Laravel or Symfony coupling.
- Your team can own worker supervision, scaling, deployment, health checks, and metrics.
Look elsewhere when:
- You are a Laravel shop. Horizon and the native queue API give retries, backoff, batching, failure tables, and a UI that this package does not provide.
- You want Symfony Messenger's transport and middleware ecosystem.
- Roughly 27 stars and zero dependents is a governance blocker — that is a genuine integration risk with thin documentation and a small community. Budget explicitly for reading source and RoadRunner docs.
- Your RoadRunner version has moved the
jobs plugin to its queues successor. Verify plugin/package alignment before committing; adopting a deprecated plugin converts a queue rollout into a migration project.
- You need managed queue infrastructure and do not want to operate a broker and a worker fleet.
Diligence gate: confirm PHP and RoadRunner version compatibility, confirm plugin support status, and prototype one real job end-to-end — dispatch, consume, retry/backoff, idempotency, dead-letter — before any build-vs-buy commitment.
How to Pitch It (Stakeholders)
Executives: We can move slow work off the request path without buying a queue product or adding Redis. This is a free, MIT-licensed SDK that lets our PHP services produce and consume jobs through RoadRunner, using whichever message broker we already operate. The value is user-visible latency and avoided infrastructure duplication. The trade-off is operational ownership — we run the workers — plus a small ecosystem and lean documentation. It is defensible only if we are already investing in RoadRunner; otherwise it is a runtime commitment disguised as a library. Recommend a time-boxed spike with a clear kill criterion, not a broad mandate.
Engineering: It is a thin client over the RoadRunner queues plugin, not a framework. You get a job abstraction, dispatch, and a consumer worker loop. You do not get retries, batching, a failure UI, or ORM integration — those become our responsibility through broker configuration and RoadRunner settings. It is framework-agnostic and uses PSR-7/PSR-17 payloads, so broker choice stays in config and swapping brokers does not touch application code. The cost is low adoption and sparse docs: assign one owner, plan for source reading, and prove dispatch, retry/backoff, idempotency, and dead-letter handling in a proof of concept before rollout. If the plugin is superseded by queues on our target version, decide that now rather than mid-rollout.