Resque Laravel Package

Product Decisions This Supports

• Queue architecture selection for PHP services. This package encodes the Resque model — named queues, job classes with a perform() entry point, standalone worker processes, payloads serialized into Redis lists — and is a concrete reference point when deciding between Laravel's native queue, Horizon, and a Redis-native third-party worker.
• Build vs. buy vs. fork for background work. With MIT licensing, a 14-star/0-dependent footprint, and archived status, the realistic option is "fork and own" or "use as a design template." This package is the artifact that forces that conversation to happen explicitly rather than by default.
• Polyglot interop roadmap. If any part of the organization already runs Ruby Resque, this is the only credible PHP-side bridge (shared Redis keyspace and job payload conventions). That supports decisions about whether PHP services should enqueue into an existing Resque fleet or stand up a parallel queue.
• Reliability investment prioritization. The high capability-level opportunity score (0.77) against a low package score (0.095) is the key reading: demand for reliable Redis-backed job processing is real, but this asset does not satisfy it. That is an argument for investing in retries, dead-letter handling, and failure visibility in whatever queue stack we do choose.
• Deprecation and exit-cost planning. "Archived, 0 dependents" is a clean worked example of dependency risk. It supports our policy on maximum acceptable maintenance status for infrastructure libraries and informs exit-cost estimates for any similarly orphaned component.
• Use cases that fit the shape: outbound email and webhook fan-out, thumbnail/media processing, report and export generation, third-party API sync, and any work that must survive a request lifecycle without blocking the response.

When to Consider This Package

Consider it when:

• You operate a Ruby Resque deployment and need PHP producers/consumers that speak the same queue format; nothing in the Laravel ecosystem does this out of the box.
• You need a minimal, readable reference implementation of Redis-backed queueing to benchmark your own worker design, failure backend, or job payload schema against.
• The workload is internal, low-stakes tooling where an unmaintained worker is acceptable and a fork-and-patch commitment is genuinely on the table.
• You are teaching or evaluating queue semantics and want a small, MIT-licensed codebase to read rather than a framework-integrated one.

Look elsewhere when:

• The application is Laravel or Symfony — use the native queue component and Horizon/Messenger. You get retries, backoff, batching, rate limiting, scheduling, and first-class observability for free, with an actively maintained dependency.
• You require maintained security patching or modern PHP compatibility. Archived means no fixes for PHP 8.x edge cases, no CVEs triaged, and no upstream support.
• You need queue priorities, delayed/scheduled jobs, unique jobs, chaining, or a UI — Resque's model predates these and you would build them yourself.
• Your risk policy treats zero dependents and single-digit contributor activity as disqualifying for anything on the critical path. It should.
• You need managed hosting or vendor accountability — there is none here.

How to Pitch It (Stakeholders)

To executives: We evaluated this package and are not adopting it as a dependency. It is a PHP port of Ruby Resque, MIT-licensed, archived, with 14 stars and no downstream dependents — meaning no one is fixing bugs or security issues. The underlying need it addresses is legitimate and valuable, so the recommendation is to satisfy that need with Laravel's maintained queue system plus Horizon, and to keep this repository as an architectural reference only. Net effect: no new dependency risk, no maintenance burden, and we still get the design insight.

To engineering: Resque's semantics are well understood and worth borrowing — discrete job classes, per-queue Redis lists, a failure backend that preserves the original payload, and re-enqueue as the retry primitive. We can use this codebase as a reference for those conventions and for a shared-Redis interop plan if we ever need PHP services to talk to an existing Ruby Resque fleet. We will not add it to composer.json on any service we care about; if interop becomes a genuine requirement, we scope it as an intentional fork with a named owner and a support commitment, not as an ordinary package install.