Resque Laravel Package

Technical Evaluation

Architecture fit. php-resque/resque is the core PHP port of Ruby's Resque: a Redis-backed job queue where producers push a JSON payload (class + args) onto a Redis list (resque:queue:<name>) and standalone worker processes LPOP/BRPOP that list and instantiate the named class to run perform(). This is a library, not a Laravel package — there is no ServiceProvider, no facade, no publishable config, no artisan command surface, and no contract with Laravel's Illuminate\Queue abstractions. It is architecturally parallel to, not complementary with, Laravel's queue system. Fit is therefore only credible in a narrow scenario: an organization already running Ruby Resque workers that needs PHP producers/consumers speaking the identical Redis wire format, or a deliberate decision to run a Resque-compatible queue across polyglot services.

Integration feasibility. Composer-installable and MIT-licensed, so legal/procurement friction is nil. Real integration work is non-trivial: workers are launched via the bundled bin/resque CLI, not php artisan queue:work, and job classes must implement Resque's perform() convention with optional setUp()/tearDown() — meaning existing Laravel ShouldQueue jobs cannot be reused and every job needs a parallel implementation. Historically the Laravel bridge lived in third-party packages (e.g., Bogardo/Laravel-Resque), not in this repo; we would own that glue. Autoloading and language level reflect the library's age, so a PHP 8.x compatibility audit (removed functions, dynamic property deprecations, return-type strictness) is a prerequisite, not a formality.

Technical risk. High, and concentrated in unmaintained code. The repository is archived: no security triage, no PHP-version upkeep, no bug fixes, and effectively no community (14 stars, 0 dependents) to absorb discoveries. Risks to price explicitly:

• Security: job payloads are plain JSON in Redis; no encryption, signing, or authz on queue contents. Redis becomes a trusted, sensitive datastore.
• Runtime compatibility: unknown PHP 8.x fitness; the pcntl/fork-based worker model interacts poorly with some extensions and with long-lived containers.
• Abandonment: any CVE or PHP 9 break lands on us. Adopting means forking and vendoring, with an internal maintainer named.
• Duplication: running two queue systems means two retry semantics, two monitoring stories, two failure taxonomies — a durable operational tax for a 14-star dependency.

Key questions.

1. Is there a concrete, non-negotiable requirement for Resque wire compatibility (e.g., existing Ruby workers, shared resque:failed tooling)? If not, the value proposition collapses against Laravel's Redis queue + Horizon.
2. What PHP and Laravel versions must be supported, and has anyone verified the library runs clean on the oldest and newest of that range?
3. Who is the named internal owner and what is the fork-and-patch budget per year?
4. What is the current volume/latency/retry profile of the workloads that would move — does anything actually exceed native queue capability?
5. Can we isolate on a dedicated Redis database/instance to avoid key-space and memory-policy collisions with the existing cache and queue usage?

Integration Approach

Stack fit. For a conventional Laravel application, the honest answer is poor. Laravel already ships a Redis queue driver with delayed jobs, retries with backoff, failed_jobs persistence, job middleware, batching, and Horizon for autoscaling and observability. php-resque/resque supplies a subset of that with none of the framework ergonomics. The one defensible fit is interoperability: if Ruby Resque producers or consumers exist and PHP must join the same queue, this library is close to the only practical PHP-side option, and its value is the shared Redis schema rather than the library itself.

Migration path. Treat this as a greenfield sidecar, never an in-place replacement of Illuminate\Queue:

1. Gateway layer first. Introduce a thin internal interface (dispatch(JobClass, array $args)) with two adapters: Laravel's native dispatcher and a Resque adapter wrapping this library. Application code depends on the interface, so the choice remains reversible.
2. Wrap the library. Add a ResqueServiceProvider that configures Redis connection parameters, registers a job-class map/namespace, and exposes an artisan resque:work command wrapping bin/resque so process management matches team habits.
3. Fork and vendor. Pin the fork to a private VCS path or Packagist mirror; apply PHP 8 fixes, add structured logging, and gate the fork behind CI that runs the compatibility matrix.
4. Isolate infrastructure. Dedicated Redis logical database (or separate instance), explicit maxmemory-policy noeviction to avoid silent job eviction, and no co-tenancy with cache.

Compatibility. Two compatibility axes must be closed before any code is written: PHP/Laravel version support (audit + patch) and Redis version/command support (BRPOPLPUSH semantics, maxmemory behavior). Also verify the payload contract against whatever Ruby Resque version is on the other side — the schema is stable but not versioned, and resque:failed entry shape differs subtly across Resque eras.

Sequencing. (1) Confirm the interoperability requirement with evidence, not assumption. (2) Two-day spike: one job class end-to-end on target PHP, including a forced failure and a retry. (3) Go/no-go on fork ownership. (4) Pilot exactly one low-risk, non-customer-facing queue behind the gateway abstraction for 30 days. (5) Expand only if the pilot shows no operational regression versus native queues. If step 1 fails, stop and spend the effort on Horizon capacity instead.

Operational Impact

Maintenance. We inherit 100% of it. The archive flag is a permanent condition, not a temporary state, so plan for a maintained fork with a versioning scheme and a documented patch cadence tied to PHP releases and security advisories. Realistically this is 5–15 engineer-days per year of baseline stewardship plus unplanned incident-driven work — small in absolute terms but disproportionate for a component whose alternative is already maintained by the framework.

Support. No upstream. No issue triage, no release notes, no CVE feed. Escalation path is internal only, which means bus factor is the constraint: at least two engineers must be able to diagnose a stalled worker at 2 a.m. Vendor-style support contracts do not exist for this package.

Scaling. The model scales the way Resque always has: add worker processes. Each worker is a forking parent, so memory is parent + N children, and concurrency tuning is a matter of process count rather than a managed pool — no autoscaling signal, no queue-time-based scaling unless we build it. Redis is a hard single point of failure and the throughput ceiling; large payloads inflate memory and eviction risk. Expect to build or buy the dashboards that Horizon would have given for free.

Failure modes. The ones that bite in production:

• Redis unavailability → producers fail or block; no built-in backpressure or circuit breaking.
• Silent job loss under maxmemory eviction or an allkeys-lru policy — catastrophic and easy to misconfigure.
• Poison jobs / retry storms — retry semantics are minimal; without a dead-letter review workflow, failures accumulate in resque:failed unread.
• Stuck or zombie workers — forked children hanging on I/O with no heartbeat or timeout enforcement; requires process supervision (systemd/Supervisor) plus our own reaper.
• Memory growth in long-lived forks — classic Resque guidance is periodic worker recycling; that becomes our cron.
• Schema drift with the Ruby side, and deserialization surprises if payload shapes change.
• No idempotency primitives — at-least-once delivery with no dedupe helper means every job must be written defensively by hand.

Ramp-up. Moderate but non-obvious. Engineers fluent in Laravel queues will find Resque's mental model similar enough to be dangerous: different retry/backoff defaults, different failure storage, different monitoring, and a separate CLI lifecycle to learn for deploys and local development. Budget a half-day onboarding doc plus a runbook covering worker restart, failed-queue inspection, and Redis failover. The compounding cost is cognitive: two queue systems in one codebase, permanently, for a capability the framework already provides.

Recommendation. Do not adopt absent a hard, documented Resque interoperability requirement. If that requirement exists, adopt deliberately as a forked, internally owned component behind a dispatch abstraction, scoped to the specific cross-language queues, with a sunset review at 12 months.