- Is react/zmq a Laravel package?
- No. react/zmq is a ZeroMQ transport binding for the ReactPHP event loop, not a Laravel package. It has no service provider, facade, or Laravel-specific integration. You would use it in a standalone long-lived process and bridge results into Laravel through Redis, a queue, or an internal HTTP call.
- How do I install react/zmq in a Laravel project?
- You install it with Composer using composer require react/zmq, but that is only part of the work. You also need the php-zmq PECL extension, which requires libzmq and a native build toolchain on every host. Plan on a custom Docker base image rather than a stock php-fpm container, and confirm the extension loads under your exact PHP version before writing application code.
- Can I use react/zmq inside a Laravel controller or queued job?
- Not through any supported path. Laravel's normal request lifecycle is short-lived and synchronous under PHP-FPM, while react/zmq expects a persistent ReactPHP event loop. The only viable pattern is a dedicated artisan command or worker that boots the loop and owns the ZeroMQ sockets, with the Laravel app communicating through Redis, a queue, or an internal endpoint.
- What are the requirements for react/zmq?
- You need the php-zmq PECL extension, libzmq 4.x, and a build toolchain capable of compiling the extension. The package targets ReactPHP v1 components. The hard constraint is the php-zmq extension ABI compatibility with modern PHP, so validate PHP 8.1, 8.2, or 8.3 on your real target runtime before doing any design work.
- Does react/zmq work with Laravel Octane, Swoole, or RoadRunner?
- No, not directly. Laravel Octane runs on Swoole or RoadRunner, neither of which shares ReactPHP's event loop. You cannot drop react/zmq into an Octane worker and expect it to integrate. Run it as a separate supervised daemon and connect it to Octane-backed services through Redis or an internal API.
- What Laravel use cases justify react/zmq over Redis or SQS?
- The narrow but real use case is brokerless, sub-millisecond, high-throughput inter-process messaging such as PUSH/PULL work distribution or PUB/SUB fan-out. It makes sense only when a concrete workload needs latency or throughput that Redis, SQS, RabbitMQ, or Kafka cannot hit. If you cannot name that number, the operational cost of owning a raw ZeroMQ topology is hard to justify.
- How does react/zmq compare to Laravel queues and broadcasting?
- Laravel queues already provide persistence, retries, and dead-letter handling through Redis, SQS, or the database, and Reverb or Pusher cover broadcasting. react/zmq is at-most-once by default with no persistence, acknowledgements, or dead-letter queue. It can beat those tools on latency, but you must engineer reliability and delivery guarantees on top yourself.
- Is react/zmq still maintained and production-ready?
- Treat it as high risk. The last release was in May 2018, the package is a fork of an abandoned upstream, and it has zero dependents and roughly 247 stars. PHP 8.x compatibility is unverified in practice, so the ecosystem has little stress-testing to learn from. If you adopt it, plan to own a fork and assign someone to patch it.
- How should I deploy and supervise react/zmq with Laravel?
- Run the ZeroMQ worker as a dedicated supervised process, either on the same host, as a sidecar, or on a separate fleet. The Laravel application should never use a ZMQ class directly; it should talk to the worker through an interface it already understands, such as a Redis list, queue job, or internal HTTP endpoint. Define a MessageBus abstraction with a Redis Streams implementation first so the ZeroMQ version remains swappable.
- How can I test react/zmq in a Laravel application or fall back from it?
- Start with a bounded runtime validation spike: build a Docker image with libzmq and php-zmq against your production PHP version and confirm react/zmq boots. Test the daemon with integration tests around the socket topology, and contract-test the adapter boundary so the application does not depend on ZeroMQ specifics. Keep a Redis Streams implementation behind the same interface as the fallback, and make the go/no-go decision before expanding the design.