Jobs Laravel Package

Technical Evaluation

Architecture fit. This is not a Laravel package — it is a framework-agnostic, low-level SDK for the RoadRunner Jobs (queue) plugin. It exposes raw primitives (Jobs::init, create, dispatch, push, reserve, ack) that talk to the RoadRunner server over its goridge pipe. It does not implement Illuminate\Contracts\Queue\Queue, ships no Laravel connector, no worker command, and no failed_jobs/Horizon integration. Fit is therefore strong only inside a RoadRunner-native architecture (Octane on server: roadrunner, or standalone RR workers) where the team explicitly wants a polyglot queue; it is a poor fit as a general-purpose Laravel queue driver.

Integration feasibility. Viable as a producer SDK from PHP: requires spiral/roadrunner-worker, a PSR-7 implementation (nyholm/psr7), and the RR binary with the jobs plugin plus a broker (Redis, SQS, AMQP, NATS, in-memory, etc.). Making it feel like a Laravel queue is custom engineering — a connector plus a Job implementation plus a codec, none of which upstream provides.

Technical risk. 27 stars and 0 dependents signals thin adoption and little community hardening; the low opportunity score reinforces that upside is limited. The package tracks RoadRunner's major-version cadence, and RR v2→v3 has historically reshuffled packages and protocols, so upgrades carry real breakage risk. Payloads are protobuf-enveloped JSON, so Laravel job serialization needs bespoke mapping. Debugging crosses a process boundary, which is materially harder than in-process drivers. Vendor concentration: the SDK is only as healthy as RoadRunner's roadmap.

Key questions. (1) Which brokers must we support, and are they covered by the pinned RR version? (2) Does the broker honor delay/retry/backoff semantics we depend on today? (3) Is there an LTS/support policy for RR majors? (4) Who internally owns the adapter? (5) Would Horizon + Redis or SQS already meet our throughput target at lower total cost?

Integration Approach

Stack fit. Adopt only where RoadRunner already terminates HTTP or runs workers. For a standard php-fpm Laravel app, adding a Go binary + broker solely to use this SDK is a net negative versus native drivers. Strongest fit: high-throughput, cross-language queue requirements (PHP producer, Go/other consumers) or existing RR infrastructure.

Migration path. Not a driver swap. Build a RoadRunnerQueue implementing Illuminate\Contracts\Queue\Queue and Illuminate\Contracts\Queue\Job, a RoadRunnerConnector, and register via Queue::extend('roadrunner', …). Producer side maps Laravel payloads into SDK Payload objects. Consumer side is the hard part: either run RR job workers that call back into application services, or a long-running Laravel worker that reserve()s/ack()s — the latter effectively reimplements Laravel's worker loop. Keep the existing driver registered as a fallback and route per-queue via config flags.

Compatibility. PHP 8.1+, current RoadRunner major, PSR-7 factory required. Coexists cleanly with Laravel 10/11/12 and other queue drivers; no hard conflicts. Pin RR binary and SDK minor versions together — mismatches fail at dispatch time rather than install time.

Sequencing.

1. Spike the adapter against a single non-critical queue (notifications or metrics).
2. Build parity tests: dispatch, payload shape, retry, delay, ack/nack against the current Redis driver.
3. Add observability hooks (structured logs, job IDs, latency metrics) before production traffic.
4. Migrate one queue in production behind a flag; retain dual-path fallback.
5. Expand only if measured latency/throughput gains justify the ongoing adapter ownership.

Operational Impact

Maintenance. MIT-licensed, maintained by the RoadRunner team as a monorepo split; release cadence appears active (latest tag 2026-10-19 per registry data) but the surface area of users is small. Realistically the team owns a permanent internal adapter layer. Pin versions; review RR release notes each upgrade for protocol changes.

Support. GitHub issues and the RoadRunner Discord are the primary channels; third-party documentation is sparse. Budget for internal runbooks covering the RR binary, broker topology, and the adapter itself — none of this comes for free.

Scaling. Favorable: persistent workers avoid per-job PHP bootstrap, so throughput is bounded by broker capacity and worker pool sizing rather than this SDK. Scaling levers live in the broker and RR config, not here.

Failure modes. Worker crash or broken pipe mid-job → redelivery governed by broker visibility timeout, not Laravel's failed_jobs table; no Horizon/Telescope visibility by default; payload schema drift between producer and consumer deploys; orphaned jobs from incorrect ack/nack paths; silent dispatch failures on RR version mismatch; broker outage presents as opaque pipe errors.

Ramp-up. Roughly 1–2 engineer-weeks for a senior engineer to build and harden an adapter, plus team-wide onboarding on the RR worker model, goridge transport, and broker-specific retry semantics. Factor in on-call training — the failure modes are unfamiliar to engineers who only know Redis/SQS Laravel queues.