Weave Code
Queue Bundle Laravel Package
quitoque/queue-bundle
Quitoque QueueBundle is a Symfony bundle for queue-based background processing in PHP applications. It helps offload time-consuming tasks to workers, keeping request handling fast, with configurable queue and worker integration for asynchronous jobs.
Symfony2/3/4 Queue Bundle (for background jobs) supporting Mongo (Doctrine ODM), Mysql (and any Doctrine ORM), RabbitMQ, Beanstalkd, Redis, and ... {write your own}
Frequently asked questions about Queue Bundle
- Can I install quitoque/queue-bundle in a Laravel app with Composer?
- No, not as a working dependency. It is a Symfony 2/3/4 bundle built on Symfony's DependencyInjection container, compiler passes, service tagging and bundle configuration, none of which Laravel loads. Laravel has no AppKernel or bundles.php equivalent, and the package does not implement Illuminate\Queue\Connectors\ConnectorInterface or the Queue contract. Composer may resolve the package, but there is no service provider to register it and no way to dispatch a Laravel job through it.
- What Laravel and PHP versions does quitoque/queue-bundle support?
- None for Laravel: it targets Symfony 2, 3 and 4, all of which are end-of-life or legacy, so its composer.json constraints will likely conflict with a modern Laravel 10 or 11 runtime on PHP 8.1+. The MongoDB adapter pulls in Doctrine ODM, a heavy separately versioned dependency chain that further narrows compatibility. Read composer.json before assuming anything, and assume the code reflects pre-7.4 PHP idioms.
- Which queue backends and transports does this bundle support?
- Its core design is a swappable transport abstraction covering MongoDB via Doctrine ODM, Doctrine ORM with MySQL, RabbitMQ, Beanstalkd and Redis. Transport and connection settings are supplied through the bundle's Symfony configuration rather than hard-coded in application code. Multi-backend breadth is convenient, but it multiplies the operational and testing surface, so only adopt it if you genuinely need more than one backend.
- How do I register and configure the bundle in a Symfony application?
- Register it in AppKernel for Symfony 2/3 or config/bundles.php for Symfony 4, then define your transport and connection settings under the bundle's configuration key. Producers publish messages through a simple service-based API, and workers run as separate long-lived processes consuming from the configured transport. The published README material is thin, so verify exact service ids and config keys against the source before wiring it up.
- Is quitoque/queue-bundle maintained and safe for production?
- Treat it as unmaintained until proven otherwise. It has zero stars, zero dependents, no visible CI, no test suite and no release cadence signal, and the license and maintainer responsiveness are not confirmed anywhere in the metadata. Symfony 2 and 3 are EOL and Symfony 4 is legacy, so security patching is unlikely. There is no evidence of production usage, so it is a maintain-only or migration candidate rather than a strategic dependency.
- What is the Laravel-native alternative to using this Symfony bundle?
- Use Laravel's first-party queue with the Redis, database or SQS drivers, with Horizon if you want Redis monitoring and metrics. Community connectors cover Beanstalkd and RabbitMQ, and you only need to write a thin custom connector for a backend Laravel does not already ship. That path is first-party, tested and framework-integrated, and it is almost certainly cheaper than porting a legacy Symfony bundle.
- Can I port the bundle's transport adapters into a Laravel queue connector?
- Yes in principle, but feasibility is medium-to-low. The per-backend adapter classes are small, however they are coupled to Symfony service definitions and likely written in pre-7.4 PHP, so you would copy each transport class, strip the DI wiring, and implement Illuminate\Queue\Connectors\ConnectorInterface and the Queue contract yourself. Someone must then own the fork and the ongoing security-patch obligation.
- How does this bundle's producer and consumer model compare to Laravel jobs and workers?
- The concept is the same: producers publish messages, consumers run in the background, and heavy or long-running work leaves the request cycle. Laravel delivers that with dispatchable jobs, queue workers and built-in retry and backoff semantics on the Queue contract. The bundle is worth reading as a design reference for adapter structure, but the framework capability itself already exists in Laravel.
- What retry, failure and delivery guarantees does the bundle provide?
- The metadata and available README excerpt document none of it. RabbitMQ and Beanstalkd have native ack and retry semantics, while Redis and MySQL-backed queues must emulate them and MongoDB adds a third behaviour, so guarantees differ per transport. Read the source and confirm at-least-once versus at-most-once behaviour, dead-letter handling and backoff before relying on any of it in production.
- Is there a test suite or CI I can run to validate quitoque/queue-bundle before adopting it?
- No CI configuration, test suite or release cadence is visible in the repository metadata. If you intend to reuse anything, write characterization tests against each transport adapter you depend on first, so you have a behavioural baseline. For a Laravel target, run the equivalent tests against your own connector using the database or Redis driver as a working reference.
Weaver
How can I help you explore Laravel packages today?