Resque Bundle Laravel Package

Technical Evaluation

Architecture fit — poor as stated. The premise of a "Laravel/PHP package" does not hold here: mcfedr/resque-bundle is a Symfony bundle, packaged for Symfony's kernel/DI/config-tree conventions (service definitions, Extension/Configuration classes, console commands registered through the container). Laravel's service-provider + facade + config/*.php model has no bridge for it, and Symfony bundles are not autoloaded into Laravel's container. There is no Laravel integration surface to adopt — only something to rewrite.

The underlying dependency is also a mismatch. Resque is a Ruby job system backed by Redis. Adopting it means either (a) running Ruby worker processes alongside a PHP app, or (b) using a PHP reimplementation (e.g., php-resque) and accepting its divergences from the Ruby reference implementation. The bundle is a thin producer/worker-bootstrap layer over one of those runtimes; it is not the queue itself. Value is therefore concentrated in a few hundred lines of glue that are straightforward to reproduce.

Integration feasibility — low. In a Symfony shop, composer require plus a config/packages/resque.yaml block is a day's work. In a Laravel shop, the realistic paths are:

1. Ignore the bundle, use php-resque (or a maintained fork) directly behind a Laravel service provider — same destination, less dead code.
2. Use Laravel's native Redis queue / Horizon, which covers the same Redis-backed-worker use case with first-class observability.
3. If Ruby Resque interop is genuinely required (existing Ruby consumers, resque-web dashboards), integrate at the payload contract level (Resque's JSON job envelope) rather than through this bundle.

Technical risk — high.

The dominant technical risk is payload coupling: Resque jobs are JSON envelopes carrying a class name string plus positional arguments. Renaming a class, changing a constructor signature, or altering argument order silently breaks in-flight jobs — and because producers and workers are separate processes on separate release cadences, this is a deploy-ordering problem, not a code-review problem. A second risk is that the bundle's runtime assumptions (which Resque implementation, which Redis client, whether ext-redis or Predis) are undocumented at the level needed for a go/no-go.

Key questions to put to the maintainer or resolve in a spike:

1. Which Resque runtime does this wrap — Ruby resque, php-resque, or a bespoke implementation — and is the JSON payload wire-compatible with the Ruby reference?
2. Supported Symfony and PHP version matrix; does it install cleanly on PHP 8.2/8.3 with current ext-redis?
3. Does it cover resque-scheduler, retry plugins, and the failure backend, or only enqueue + work?
4. What is the intended production topology — how are workers supervised, and is there any heartbeat/health signal?
5. Is the project accepting issues/PRs, and what is the last commit date relative to the PHP versions we run?
6. Serialization of arguments: does it support nested objects, or only scalars/arrays?

Integration Approach

Stack fit. Do not integrate this bundle into a Laravel application. If the stack is Symfony, it is a candidate but must clear the PHP-version gate first. If the stack is Laravel, the correct framing is "we need a Redis-backed background job system" — for which Horizon is the native answer and php-resque is the interop answer. Neither requires this bundle.

Recommended architecture decision. Treat the bundle as non-adoptable, low-effort-to-replace. The defensible move is to define a narrow internal JobDispatcher interface (dispatch(string $jobClass, array $args): void, register(string $jobClass, callable $handler): void) and implement it once. That interface is ~150 lines of Redis RPUSH/BLPOP plus a supervised worker command. Owning that code costs less than owning a dependency with zero dependents.

Migration path. Whether arriving from or leaving Resque, migrate on the contract, not the library:

1. Inventory every job class name and argument shape currently in Redis — these strings are the real API.
2. Introduce the interface and route existing producers through it while still writing Resque-format envelopes (dual-write if Ruby consumers exist).
3. Freeze the old namespace — keep legacy class names as thin adapters so in-flight jobs drain rather than dead-letter.
4. Drain the Resque queues to zero, verify the failure backend is empty, then cut producers to the new backend.
5. Decommission the Ruby/bundle workers after a soak period covering the longest job runtime.

Compatibility gates (must pass before any code is written):

• composer require resolves on the target PHP without --ignore-platform-reqs.
• A worker boots, consumes a job, and exits cleanly on the target OS/container image.
• Redis version and eviction policy confirmed (see failure modes below).
• CI can run the worker in a container — if it can't, it will never be tested.

Sequencing. Two-week timebox: week 1 spike (compatibility gates + payload contract documented); week 2 decision memo with build-vs-adopt costing. Do not sequence this behind a feature release — the deploy-ordering hazard around payload changes argues for an isolated cutover window.

Operational Impact

Maintenance. Assume unmaintained. The practical posture is vendor-and-fork: pin the exact commit in composer.json, mirror to internal Git, and budget ~2–4 engineer-days per year for PHP/Redis compatibility patches. MIT license makes forking legally trivial; the cost is entirely in ongoing ownership, not in permission.

Support. No community, no SLA, no upstream triage. Any incident is an internal-oncall incident with no external escalation path. Contrast with Laravel Horizon, where the observability surface (throughput, wait times, failed-job inspection, retries) ships in the box. Here, the standard dashboard is resque-web — a Ruby/Sinatra app — meaning operators need Ruby-ecosystem fluency to see queue health. That is a real, recurring staffing constraint, not a one-off setup cost.

Scaling. The bundle is not the bottleneck; Resque's process model is. Workers fork per job, so memory is a function of worker count × peak job footprint, and scaling is horizontal process count — no autoscaling signal unless one is built. Redis becomes a hard dependency for both throughput and durability, so Redis sizing, connection limits, and maxmemory-policy are production-critical. Policy must be noeviction for the queue database; allkeys-lru silently discards jobs under memory pressure, which presents as "jobs vanish" with no error anywhere.

Failure modes to instrument before launch:

• Silent payload deserialization failure — job class renamed or args reshaped; worker raises, job lands in the failure backend, producers never learn. Requires a failed-job alert, not just a dashboard.
• Worker process death — a PHP fatal in the job loop takes down the worker; remaining jobs stall. Requires supervisor (systemd/supervisord) with restart policy and an absence-of-heartbeat alert, since a dead worker produces no error, only a growing queue depth.
• Queue depth SLO — alert on age of oldest job, not depth; depth is meaningless without knowing drain rate.
• Redis persistence — queue durability equals Redis durability. Confirm AOF/RDB settings match the acceptable job-loss window.
• Deploy skew — producers on new code, workers on old. Requires drain-before-deploy or backward-compatible job signatures for at least one release.

Ramp-up. High, and the cost is breadth rather than depth: engineers need Symfony DI conventions, Resque's fork-per-job semantics and failure backend, and Ruby tooling for operational visibility. Estimate 3–5 days for a mid-level engineer to be productive on the worker side, plus a standing Ruby literacy requirement for whoever is on call. That is a disproportionate tax for what is, functionally, "Redis plus a worker loop."

Net assessment. Score 0.105 is consistent with what the repository shows. The recommendation is do not adopt: the bundle is a thin, unmaintained wrapper around a legacy runtime, fits the wrong framework, and imports a cross-language operational burden. If the requirement is Redis-backed background jobs on Laravel, Horizon is the lower-risk default; if the requirement is Ruby Resque interop, integrate against the JSON contract directly and own the ~150 lines rather than inheriting an abandoned dependency.