- Is kunalvarma05/laravel-rabbitmq a drop-in Laravel queue driver for RabbitMQ?
- No. It is a thin convenience layer over php-amqplib with a service provider, facade, and publish-oriented config; it does not implement Laravel's Queue or Connector contracts. That means no dispatch(), queue:work, job retries, failed_jobs table, or Horizon-style visibility. If you need RabbitMQ as the Laravel queue backend, use a maintained queue-driver package instead. Treat this package as an AMQP publishing client with Laravel ergonomics.
- How do I install and configure kunalvarma05/laravel-rabbitmq in a Laravel app?
- Install it with Composer, publish the package config, and register the service provider if your Laravel version predates package auto-discovery. Optionally alias the RabbitMQ facade for convenience. Then set your broker host, port, credentials, queue, and exchange values in the published config file. The public API is intentionally small, so a working spike is usually achievable in under a day.
- Does this package support Laravel 10 and Laravel 11 on PHP 8.1 or newer?
- Support is era-constrained, and the package may require a fork or a Composer constraint bump for current Laravel and PHP releases. Validate compatibility with composer why-not and composer update --dry-run before committing. Check whether a Laravel 10 or 11 compatible release actually exists. Do not assume upstream fixes will arrive.
- Can laravel-rabbitmq consume messages, or is it publish-only?
- The package is publish-oriented: it focuses on emitting messages through configurable connections, queues, and exchanges, with artisan commands and a simple facade. Before relying on it for consumption, verify whether basic_consume or a consumer abstraction is actually exposed in the code and README. If consumption is not first-class, use php-amqplib directly or a dedicated consumer package for workers. Do not assume it replaces a full queue worker implementation.
- Does the package support publisher confirms, and can messages be lost?
- By default AMQP basic_publish is fire-and-forget, and there are no publisher confirms enabled out of the box. Without confirm_select, a successful publish only means the message was written to a socket, so messages can vanish on broker restart or channel error. If delivery guarantees matter, wrap publishing with publisher confirms, mandatory flags, and basic_return handling yourself. Plan for explicit error handling rather than trusting a silent publish.
- Is the RabbitMQ connection a singleton, and what happens in long-running workers?
- The service provider binds a connection and channel manager into the container, typically as a per-process singleton. Long-running consumers can therefore inherit a connection that silently dies on heartbeat timeout unless reconnect-on-failure is implemented. If the connection is not shared, every request opens a new TCP connection and channel, which can exhaust broker file descriptors under load. Resolve the lifecycle explicitly for your deployment model.
- Is it safe to publish RabbitMQ messages from a Laravel web request?
- php-amqplib is synchronous and blocking, which is fine for CLI workers but awkward inside an FPM request path. Publishing inline adds broker round-trip latency to user-facing requests and ties request success to broker availability. Prefer dispatching a Laravel job that publishes from a worker, or use the package as a sidecar publisher. Keep the web request path decoupled from AMQP connection management.
- What dependencies and PHP extensions does laravel-rabbitmq require?
- It depends on php-amqplib, which pulls in ext-bcmath, ext-sockets, and ext-json. The transport is synchronous and blocking, which suits CLI consumers but not high-throughput request paths. Confirm those extensions are present in your production and CI images before rollout. Also review the transitive dependency surface with Composer before approving.
- Is kunalvarma05/laravel-rabbitmq actively maintained and production-safe?
- Treat abandonment risk as the headline concern: low stars and a weak composite score are strong non-adoption signals. Assume no upstream fixes and budget to own the code, including security patches and Laravel compatibility bumps. Vendor the package into your application or a private Composer VCS repository before depending on it. Check the last commit date, open issues, and whether a test suite runs against a real broker.
- How should I adopt this package, and what are the alternatives?
- Use it as a publisher-only adapter behind an internal EventPublisher interface so the transport is swappable; the interface, not the package, is the integration contract. It fits cleanly when you need to emit domain events into an existing RabbitMQ estate that other services consume, not as the ingestion path for Laravel jobs. For genuine Laravel queue backed by RabbitMQ requirements, choose a maintained queue driver. Given the small surface area, vetting and internalizing a fork is often cheaper than a heavy evaluation cycle.