- What is elandlord/nats-php-bundle used for?
- It is a Symfony bundle that connects NATS messaging to Symfony Messenger through a NatsConnection, so you can send and handle messages over NATS transports. It fits event-driven Symfony apps that need pub/sub, request-reply, background jobs, or decoupled services without a heavy broker. It assumes you already run and manage a NATS server.
- How do I install it and which Symfony/PHP versions are supported?
- Install it with Composer using composer require elandlord/nats-php-bundle, then register the bundle using normal Symfony bundle registration. The release profile targets Symfony 6.4+ and Symfony Messenger's baseline suggests PHP 8.1+, but you should verify exact constraints in the package composer.json. v1.4.3 is a patch release with no new dependencies.
- Does elandlord/nats-php-bundle work with Laravel?
- No. It is a Symfony bundle built around Symfony Messenger and Symfony's bundle/DI configuration, so Laravel's queue system will not use it automatically. Laravel teams can evaluate the underlying elandlord/nats-php client or build a custom Laravel queue connector instead.
- How do I configure a NATS transport in Symfony Messenger?
- Define a Symfony Messenger transport that uses the bundle's NATS transport/DSN and point it at your configured NatsConnection. Set the NATS server URL and use a JetStream-enabled server if you need persistence or durable consumers. Check the README for the exact DSN format and option names, because they are package-specific.
- Do I need JetStream for durable consumers and persistence?
- Core NATS is sufficient for simple pub/sub and request-reply without persistence. You need JetStream for persistence, replay, and durable consumers, and the v1.4.3 mutable consumer configuration only matters on JetStream-backed streams. Confirm your server supports updates for the consumer fields you plan to change.
- What changed in v1.4.3 for existing durable consumers?
- v1.4.3 makes consumer configuration mutable: changes such as filter subjects and delivery settings are now applied to existing durable consumers instead of being silently ignored. It is a behavioural change with no API break, and it takes effect on the next consumer attach or worker start. Review consumer-config diffs carefully because unintended changes can now reach production.
- How do retries and failed messages work with NATS?
- Use Symfony Messenger's retry strategy and failure transport configuration; the bundle lets NATS act as the transport while Messenger middleware handles retries and logging. For durable or replayable behaviour, use JetStream and confirm acknowledgement and consumer settings match your retry expectations. Test failure paths against a real NATS server.
- Is this bundle suitable for production event-driven systems?
- It can be suitable for production Symfony event-driven systems when you already operate NATS and understand Messenger retries and JetStream semantics. The main risks are the external NATS dependency, misconfiguration causing silent failures, and live durable-consumer reconfiguration reaching production on worker restart. Add health checks, validate in staging, and version consumer settings in Git.
- How should I test NATS Messenger transports in CI?
- Unit-test handlers with Symfony Messenger's test transport or direct message bus calls, and mock NatsConnection where possible. For integration tests, run an ephemeral NATS server with JetStream in CI and exercise send/receive plus consumer updates. Capture nats consumer info before and after tests or deploys for durable consumers.
- What are alternatives to this bundle for NATS in PHP?
- You can use elandlord/nats-php directly, choose other Symfony Messenger transports such as AMQP, Redis, or Doctrine, or use broker-native NATS clients. For Laravel projects, look for Laravel-specific queue connectors rather than this Symfony bundle. Choose based on persistence needs, operational burden, and how much Symfony Messenger integration you want.