- How do I install and configure sobirjonovs/laravel-rabbit in a Laravel app?
- Install it with Composer using composer require sobirjonovs/laravel-rabbit, then publish the package config file so the connection settings land in config/. You set your broker host, port, credentials, vhost, and exchange/queue names there or via environment variables. The service provider is expected to be auto-discovered, so no manual registration should be needed on modern Laravel versions. After that you publish and consume through the package's facade and console commands.
- Is laravel-rabbit a drop-in Laravel queue driver for RabbitMQ?
- No, it is best understood as a thin AMQP client wrapper rather than a Laravel queue driver. Laravel ships drivers for database, Redis, SQS, and Beanstalkd but not RabbitMQ, and this package adds a service provider plus facade for publishing and consuming messages directly. That means your jobs do not automatically flow through Laravel's queue abstraction, dispatch helpers, and failed-job handling. If you specifically want a queue driver, look at vladimir-yuldashev/laravel-queue-rabbitmq instead, since these two solve different problems.
- Which Laravel and PHP versions does laravel-rabbit support?
- The package has a single dated release from August 2024, so its declared support matrix may predate newer Laravel majors. Check the require and require-dev blocks in composer.json before installing, and confirm the PHP constraint matches your runtime. If your application is on a newer Laravel or PHP minor, run the suite in a branch first rather than assuming compatibility. A quick Composer dry run against your lockfile will surface conflicts immediately.
- Which RabbitMQ client library does laravel-rabbit wrap?
- The package is a wrapper around an underlying PHP AMQP client, most likely php-amqplib, but the exact dependency and pinned version should be confirmed in composer.json. This matters because the client determines which features are even reachable, such as publisher confirms, consumer prefetch, and heartbeat handling. It also determines your exposure to upstream security advisories and PHP version bumps. Read composer.lock after install to see exactly what gets pulled in.
- Does laravel-rabbit support publisher confirms, mandatory flags, and manual ack/nack?
- These reliability features are the key thing to verify in the source before committing, because the repository does not clearly document them. If publishing is fire-and-forget without confirms or mandatory/return handling, messages can be silently dropped when no queue is bound to a routing key. Likewise, without manual ack and nack on the consumer side, a worker crash mid-handling can lose a message. Open the publish and consume classes and check which client methods are actually called.
- How do I run a long-lived RabbitMQ consumer in Laravel with this package?
- The package provides console commands for consuming messages, which you run as a supervised worker process, typically under Supervisor or a container orchestrator. Check whether the consumer loop handles prefetch/QoS, manual acknowledgement, and graceful shutdown on SIGTERM, since all three affect throughput and message safety under load. PHP's request-per-process model means the AMQP connection lives for the worker's lifetime, so reconnection behavior matters on long runs. Do not run consumers without process supervision, or a crashed worker silently stops draining the queue.
- Is sobirjonovs/laravel-rabbit safe to use in production?
- Treat it as a starting point rather than a supported platform component. It has roughly 11 stars and a single release, with no visible roadmap, security policy, or sustained maintenance history, so assume a single maintainer and plan for the possibility of vendoring or forking. That is fine for a prototype, an internal tool, or a team that is comfortable owning RabbitMQ operationally. Before production commitment, read the code, confirm license terms, and check maintainer responsiveness to issues.
- What is the difference between laravel-rabbit and laravel-queue-rabbitmq?
- laravel-queue-rabbitmq registers itself as a Laravel queue driver, so existing dispatch, queue:work, retry, and failed-job tooling keeps working unchanged. laravel-rabbit instead exposes RabbitMQ directly through a facade and config, which gives you real AMQP semantics like exchanges, routing keys, and topic or fanout patterns that the Laravel queue abstraction does not surface. Choose the driver if you just want background jobs on RabbitMQ, and choose the wrapper if your architecture genuinely depends on AMQP routing.
- Does laravel-rabbit offer testing helpers or fakes so tests do not need a broker?
- There is no documented fake or mock layer, so assume your test suite will need either a live RabbitMQ instance or your own abstraction for stubbing publishing and consumption. A common approach is to wrap the package's facade behind a small interface of your own and swap in an in-memory implementation in tests. That also decouples application code from the package's API, which limits the damage if you later migrate or fork. Without such a seam, every test touching messaging depends on broker availability.
- How does laravel-rabbit handle retries, dead-letter queues, and reconnection after a broker restart?
- Retry, backoff, and dead-letter exchange topology are often left to the user in thin AMQP wrappers, and this package does not clearly document providing them, so plan to declare your own DLX and retry queues. Reconnection is the other operational gap to check: without reconnect logic and backoff in the consumer loop, a broker restart or network partition will kill your worker until Supervisor restarts it. Connection reuse also matters, since opening a fresh AMQP connection per request is a throughput and stability problem under load. Verify both behaviors by restarting RabbitMQ while a consumer is running.