- Is simple-bus/rabbitmq-bundle-bridge compatible with Laravel?
- No. The package is a Symfony Bundle subclass with DependencyInjection extensions and compiler passes, so there is no path to loading it in a Laravel service container. It targets Symfony applications running SimpleBus and OldSoundRabbitMQBundle. For Laravel you need a different solution, such as vladimir-yuldashev/laravel-queue-rabbitmq or simply staying on Redis or SQS with Horizon.
- What does simple-bus/rabbitmq-bundle-bridge actually do?
- It is thin glue between SimpleBus/AsynchronousBundle and the Symfony RabbitMQBundle. A producer hands serialized Message objects to the AMQP producer, a consumer pumps deliveries back into the message bus, and the rest is DI and config wiring for exchanges and queues. The durable value lives in the dependencies (php-amqplib, SimpleBus/AsynchronousBundle, OldSoundRabbitMQBundle), not in this repository, and the equivalent is only a few hundred lines of application code.
- How do I install and configure it in a Symfony application?
- You run composer require simple-bus/rabbitmq-bundle-bridge, register the bundle in your kernel or bundles.php, tag the bus services, and configure the exchange and queue. For legacy Symfony apps already on SimpleBus and RabbitMQBundle, adoption is genuinely low effort. It is not a viable greenfield choice.
- Is this package still maintained?
- No. The last release was 2021-08-18, with around 39 stars and zero dependents. The upstreams are also dormant: SimpleBus has seen essentially no activity since roughly 2020-2021, and OldSoundRabbitMQBundle was renamed to php-amqplib/rabbitmq-bundle and is itself in maintenance mode. There is no upstream from which to receive a patch.
- Will it work on PHP 8.3 or Symfony 6 and 7?
- Realistically no. A 2021 release declares no support for PHP 8.2, 8.3 or 8.4, Symfony 6 or 7, or php-amqplib v3. Composer will likely force version pins or ignore-platform-req style workarounds in a modern app. Pinning php-amqplib back to an end-of-life line also drags an unpatched AMQP client into your dependency graph, which is a real security and stability liability.
- What is the Laravel equivalent for publishing jobs to RabbitMQ?
- The Laravel equivalent is an AMQP-backed queue connection, most commonly vladimir-yuldashev/laravel-queue-rabbitmq, or simply staying on Redis or SQS with Horizon. There is no way to reuse this bridge in Laravel; you would reimplement it against Illuminate\Queue, at which point you are not using this package at all.
- What should I use instead in a Symfony application?
- Use Symfony Messenger with the AMQP transport. It provides the same publish and consume semantics plus native retry, a failure transport and middleware. It is first-party, actively maintained, and already the default in Symfony Flex recipes, so any new Symfony work should start there.
- Does it handle retries, dead-letter queues, or idempotency?
- No. The bridge gives you publish and consume only; it does not provide dead-letter topology, retry or backoff, or idempotency. SimpleBus async delivery is at-least-once, so handlers must be idempotent by construction and that constraint has to be enforced by code review rather than by the library. A practical consequence is that you should add tests that run each handler twice to prove idempotency.
- Will renaming or moving a command class break messages already in flight?
- Yes. Message serialization uses SimpleBus's own format keyed on the fully qualified class name, so renaming or moving a command class breaks in-flight messages. Deploy ordering between producers and consumers becomes a correctness concern. Plan class moves carefully or version your payloads before rolling out the change.
- Should we fork this bridge or migrate away from it?
- For a legacy Symfony application with in-flight SimpleBus traffic, forking is workable but you then own a security-patch cadence on php-amqplib and any Symfony compatibility fixes yourself. For anything greenfield or upgradeable, migrating to Symfony Messenger is the lower long-term cost. Compare the real migration effort against the ongoing cost of owning the fork before deciding.