Resque Laravel Package

Product Decisions This Supports

• Queue infrastructure: build vs. framework-native vs. third-party. This package forces the real trade-off into the open: do we own a queue abstraction, use the framework's native queue, or buy a managed service? glit/resque is the "third-party community port of a foreign-ecosystem queue" branch of that tree — and on a Laravel codebase it is a dead branch. The decision it supports is the negative one: documenting why the native queue (Redis driver + Horizon) is the default, not a compromise.

• Moving latency out of the request/response cycle. The concrete feature it enables — emails, webhooks, exports, media processing, third-party syncs, notification fan-out — is the roadmap item that matters. The package shows what the Resque flavor of that looks like (one Redis list per queue, JSON {"class":..., "args":[...]} envelopes, a perform() contract, resque-web-style dashboards). Useful as a mental model for scoping the async work; not as the implementation.

• Job handlers as container-resolved services — a standard, not a feature. The fork's sole differentiator is a pluggable job-instantiation delegate so jobs are resolved from a DI container instead of new'd with static/global state. That is the durable product decision: jobs are ordinary, injectable, unit-testable classes. Laravel already makes this the default. Carry the principle forward; leave the code behind.

• Legacy modernization and retirement calls. If a Symfony2/Silex-era service already runs php-resque, this fork is a candidate for the "keep the lights on" path — and choosing it should immediately trigger a maintain-vs-retire decision, because an unmaintained, forking, Redis-backed daemon is a slow tax on PHP upgrades and security posture.

• Reliability posture as a product commitment. Resque semantics are at-least-once with a visibility gap (a job popped and killed mid-flight is silently lost; a crash strands the in-progress entry with no auto-requeue). Adopting it means every job must be idempotent by design, durability is bounded by Redis persistence config, and retries, backoff, dead-lettering and deduplication become our code. That is a product-level promise to operations, not an implementation detail.

When to Consider This Package

Consider it only when all of these hold:

• You run a legacy Symfony2/3-era PHP application (PHP 5.6–7.x) that already speaks the php-resque protocol, already has Redis, and needs services injected into jobs without rewriting the worker layer.
• You need Resque wire compatibility — the same Redis keyspace read by Ruby workers, or an existing resque-web dashboard your ops team depends on.
• Volume is low, a single Redis is acceptable, and you don't need delayed/scheduled jobs, batching, chaining, uniqueness, rate limiting, or fine-grained metrics.
• You accept essentially zero upstream maintenance: no dependents, no CVE triage, no compatibility patches, and you will vendor/pin the fork behind a private mirror rather than float it from Packagist.

Look elsewhere when:

• You are on Laravel. Illuminate\Queue with the Redis driver plus Horizon is a strict superset — container-resolved jobs, retries with backoff, failure storage and replay, rate limiting, batching/chaining, metrics and dashboards. Adopting this package means running two queue paradigms and owning an unmaintained dependency.
• You need PHP 8 / PSR-11 compatibility or modern typing. The lineage predates those; budget for porting as a fork, not a dependency.
• You need stronger guarantees — transactional outbox, deduplication, exactly-once-ish delivery, dead-letter queues.
• You need throughput, autoscaling, or real operational visibility — Horizon, SQS + workers, RabbitMQ, or Symfony Messenger with Redis/AMQP are the correct answers.
• You need a maintained library at all. Prefer the actively maintained php-resque lineage or the framework-native option; do not pin a revenue path to a package with no users.

How to Pitch It (Stakeholders)

Executive framing: This is not a strategic dependency and does not belong on a build/buy shortlist. Zero stars, zero dependents, no release cadence, no security response — putting it in a revenue path is an uninsured liability with a bus factor of one, and an abandoned low-traffic Packagist name is a supply-chain candidate for takeover. What is valuable is the idea inside it: background work should be ordinary, dependency-injected classes, so it is testable and reusable. We adopt the pattern, not the package — and we get the pattern for free from the framework we already run. Recommendation: do not adopt; log the standard (container-resolved, idempotent jobs) and, if a legacy php-resque service exists, open a retirement ticket with a framework-native target.

Engineering framing: Treat glit/resque as reference architecture. Read it for the job-factory/DI delegation approach — resolve job classes from the container instead of instantiating them statically — then implement that with Laravel's queue, which does it natively and adds retries, backoff, timeouts, failure handling and Horizon observability. Note the operational tax the package implies: pcntl/posix fork workers requiring supervisord/systemd units rather than an artisan command, JSON-serializable arguments only, no retry or requeue tooling, and a Redis single point of failure. If Resque protocol interop is ever genuinely required, use a maintained implementation, wrap it behind our own thin job contract and factory seam so the types never leak into job classes, pin it by commit hash from a private mirror, and run a CI job that boots a worker and drains a queue so PHP-version bumps fail loudly instead of silently. Exit target is Laravel queues or Symfony Messenger — both preserve container-resolved handlers, so the fork's one advantage evaporates on migration.

Net: the package's value to us is one paragraph of design guidance, not a dependency.