glit/resque-bundle
glit/resque-bundle is a Symfony bundle for integrating Resque, the Redis-backed PHP job queue. It helps wire Resque queues and workers into Symfony so applications can dispatch and process background jobs asynchronously.
Architecture fit. This is not a Laravel package — it is a Symfony2 bundle (Glit\ResqueBundle) that wires the php-resque worker library into the Symfony 2 dependency injection container and console. Dropping it into a Laravel application is a category error: there is no bundle registration, no Kernel, no Symfony DI container to hook into. Any adoption path in a Laravel codebase means either (a) bypassing the bundle entirely and using php-resque as a standalone Composer dependency with custom Laravel service-provider wiring, or (b) standing up a parallel Symfony2 process alongside the Laravel app — which is almost certainly not a defensible architecture.
Integration feasibility. Low. The package targets a framework generation that reached end-of-life with Symfony 2.8 in November 2018, and its PHP constraint almost certainly excludes PHP 8.x (typical of that era: PHP 5.3–5.6, possibly 7.0). Modern Laravel (10/11/12) requires PHP 8.1+, so Composer resolution will fail or require --ignore-platform-reqs hacks that are untenable in production. There is also no PSR-4 autoloading guarantee, no Laravel facade, no queue driver contract, and no interoperability with Laravel's Queue/Job/ShouldQueue abstractions — meaning job dispatch, retries, and failure handling would all need bespoke glue code.
Technical risk. High and concentrated in three areas:
resque:worker:* keys, resque-web dashboard) predates and diverges from Laravel's queue semantics — no native backoff strategies, no job batching/chaining, no rate limiting, no encrypted payloads, weaker failed-job inspection.proc-constrained environments.Key questions. (1) What specific capability is being sought — deferred execution, fan-out, long-running jobs? (2) Is there existing php-resque infrastructure in the estate (Redis with Resque keys, resque-web dashboards, operational runbooks) that this bundle was meant to integrate with? (3) Are there legacy Symfony2 services that must remain reachable from workers? (4) What is the actual job volume and latency SLO — is a queue even warranted versus a scheduled command? (5) Is the intended outcome porting Resque-style jobs onto Laravel's queue, or coexisting with a Symfony2 service?
Stack fit. Poor as shipped, adequate as raw material. The bundle itself should not be installed. The only defensible pattern is to treat it as reference implementation: extract the job class definitions, the queue-name conventions, and the worker bootstrap logic, then re-implement them against Laravel's native queue system with the Redis driver. Laravel's Redis queue plus Horizon delivers the same operational shape (Redis-backed, multi-worker, named queues, priority ordering) with first-class Laravel semantics — ShouldQueue, tries, backoff, failed() hooks, and a monitoring UI.
Migration path. Three viable routes, in order of preference:
Job class; replace Resque::enqueue() calls with dispatch(); replace worker invocations with php artisan queue:work --queue=<name>. Preserve queue names to keep any external enqueuers working during cutover.php-resque directly, and write a Laravel service provider plus a queue:work-style artisan command.Compatibility. Verify PHP constraint against the target runtime before anything else — this likely disqualifies the package outright. Confirm Redis version compatibility against the pinned php-resque release. If any Symfony2-era transitive dependency is required (old symfony/console, symfony/process, Monolog 1.x), expect version conflicts with Laravel's own constraints and do not attempt to resolve them in the same Composer graph.
Sequencing. (1) Inventory current job types, enqueue sites, and payload schemas. (2) Decide re-platform vs. bridge. (3) Build a spike proving one job end-to-end on Laravel queues with parity in payload shape and failure behavior. (4) Dual-run in staging with queue-name parity and shadow enqueues. (5) Cut over producers, then drain the Resque queues, then decommission workers. (6) Retain the old worker image for one release cycle as a rollback path.
Maintenance. The package offers no maintenance contract — no releases, no CVE response, no PHP/Redis compatibility work. Every future runtime upgrade (PHP minor, Redis major, base image) becomes your team's burden. Budget for a fork-and-own decision, or more sensibly, avoid taking the dependency. The reference-implementation route (extract, don't depend) eliminates this cost entirely.
Support. No upstream support channel. Debugging lands on whoever owns the queue subsystem, and Resque's failure modes are Redis-internals-heavy — diagnosing a stuck worker means reading Redis keys directly. Laravel's queue + Horizon materially reduces this: failed jobs are inspectable via queue:failed and the Horizon UI, with retry as a first-class operation.
Scaling. Resque's fork-per-job model scales horizontally with worker count but has poor density in containers (memory overhead per forked child, cold-start cost per job) and no built-in autoscaling signal. Horizon's balanced/auto strategies and metrics give you throughput and wait-time visibility that php-resque does not. Redis itself is the shared bottleneck in both cases — plan for persistence (appendonly), memory limits, and eviction policy set to noeviction for queue keys, since an evicted queue is silent job loss.
Failure modes. Watch for: workers dying mid-job with no atomic re-enqueue (jobs lost unless resque:retry-style plugins are wired); no exponential backoff, so failing jobs hot-loop; unbounded queue growth with no alerting; resque-web-only observability, which is inadequate for on-call; payload schema drift between producers and consumers with no versioning; and Redis failover without replica awareness dropping in-flight jobs. Under Laravel queues, most of these have first-party mitigations (backoff, maxExceptions, retryUntil, Horizon alerts) — another argument for re-platforming rather than integrating.
Ramp-up. Resque knowledge is a niche skill in 2020s PHP teams; engineers fluent in Laravel queues are plentiful. Choosing this package narrows the hiring and onboarding pool and creates bus-factor risk around a single steward of the fork. Conversely, porting to native Laravel queues means an engineer productive on day one. Estimate the re-platform at low single-digit engineering weeks for a typical job inventory, versus an open-ended and compounding cost of ownership for keeping a Symfony2-era bundle alive in a Laravel codebase.
Recommendation. Do not integrate glit/resque-bundle. Use it only as a read-only reference for job semantics if there is an existing Resque deployment to interop with, and re-platform onto Laravel's Redis queue with Horizon. If hard interop with an existing Ruby Resque cluster is mandatory, depend on php-resque directly behind a Laravel service provider — never through the bundle.
How can I help you explore Laravel packages today?