Stomp Laravel Package

Technical Evaluation

Architecture fit. react/stomp is not a Laravel package in the conventional sense — it is a STOMP 1.0/1.1/1.2 client built on the ReactPHP event loop and socket layer, published under the friends-of-reactphp org. That distinction drives the entire evaluation. Laravel's default execution model is synchronous, one-request-per-process under PHP-FPM; react/stomp is asynchronous and assumes a persistent event loop. It fits Laravel only at the edges where the process is already long-lived: queue workers (queue:work/Horizon), Laravel Octane workers, artisan daemon commands, or a dedicated sidecar microservice. Any attempt to use it inside a normal HTTP request handler is a category error — the promise-based API will either block on wait() (defeating the purpose) or return before the message is flushed.

Integration feasibility. Composer-installable with no framework coupling, which is both the strength and the gap. There is no service provider, no config publishing, no facade, no Laravel-native connection abstraction. A team must write and own a thin adapter: a container binding for the Client/Connection, a config block for broker URI and credentials, and lifecycle management (connect on boot, disconnect on shutdown, survive SIGTERM). Broker compatibility is broad — ActiveMQ, RabbitMQ with the STOMP plugin, Artemis, and several SaaS brokers — so the package solves real interoperability problems, particularly bridging into an existing JMS/Java estate where STOMP is the lingua franca.

Technical risk. The dominant risk is project health, not code quality. At 114 stars and zero tracked dependents, the bus factor is effectively one to two maintainers, and the release cadence will not track Laravel or PHP minor versions. Second risk is that async correctness is easy to get subtly wrong: unhandled promise rejections, missing done() callbacks, heartbeat configuration mismatches, and connection loss during a subscribe all fail quietly rather than loudly. Third, the package handles protocol framing but not the operational concerns a TPM cares about — reconnection, backoff, prefetch tuning, dead-letter routing, and observability are all left to the integrator.

Key questions. Which broker and STOMP version, and does the operations team already run it? Is the requirement consuming from a broker (daemon shape) or publishing to one (request-adjacent shape, much harder)? What are the delivery guarantees required — at-most-once fire-and-forget versus ack/nack with redelivery? Does the workload tolerate a process that must be supervised and restarted on connection loss? Is there an existing JMS integration that justifies STOMP over Redis/SQS/database queues? Who owns the adapter code when the upstream repo goes quiet?

Integration Approach

Stack fit. Position react/stomp as a bridge, not a queue driver replacement. Laravel's native queue drivers (Redis, SQS, database) are battle-tested, Horizon-instrumented, and have retry/backoff semantics the team already understands; do not displace them. Use STOMP where messages must cross an organizational boundary — publishing domain events into an existing ActiveMQ/Artemis bus, or consuming from a JMS topic owned by another team. The natural home is a dedicated artisan consumer command running under Supervisor or a Kubernetes Deployment, with the rest of the application unchanged.

Migration path. Start with a throwaway spike: a single artisan stomp:consume command in a scratch branch, connected to a non-production broker, proving connect → subscribe → ack → graceful shutdown. If that spike is clean, promote it into a small internal package (app/Stomp or a private Composer package) that owns the adapter, config, and supervisor template. Existing Redis-queue workflows stay untouched; the STOMP path handles only the new cross-boundary traffic. This keeps blast radius to one process type and one new dependency.

Compatibility. Verify PHP constraint against your runtime (the package targets modern PHP but its ReactPHP dependency pins react/event-loop and react/socket major versions — confirm those resolve cleanly against anything else in your tree, especially if Octane/Swoole is installed, which brings its own loop). Octane and this package can coexist but should not share a process. Confirm TLS support on the socket layer for any broker crossing a network boundary, and confirm the broker's STOMP plugin is enabled and its version negotiated (1.1 vs 1.2 changes heartbeat and ack semantics).

Sequencing. (1) Broker access and a sandbox topic. (2) Spike consumer, no framework wrapping. (3) Adapter package: config, container binding, structured logging on connect/disconnect/error. (4) Reconnection and backoff implemented by you, with heartbeat and idle timeouts. (5) Supervisor/systemd unit with restart=always, or a K8s Deployment with liveness probe. (6) Metrics and alerting before any production traffic. (7) Canary on a low-volume topic, then widen. Do not invert steps 4–6 — shipping a consumer without reconnect and metrics is the most common way this class of integration fails.

Operational Impact

Maintenance. You are adopting a dependency with a small maintainer pool and no commercial backing. Budget for the possibility that your team becomes the de facto maintainer — the package is small enough (protocol framing over ReactPHP streams) that forking is realistic if it stalls, but that is a cost to acknowledge up front, not discover at a PHP upgrade. Pin the version, watch the repo, and keep the adapter layer thin enough that swapping to enqueue/stomp or a native JMS client is a contained change.

Support. Community-only, GitHub issues, no SLA. Internal support burden shifts to whoever writes the adapter; that person becomes the go-to for broker connectivity questions. Document the supervisor unit, the reconnect behavior, and the ack semantics, because debugging "why did the consumer stop" without that runbook will consume disproportionate on-call time.

Scaling. One connection per process, so horizontal scale means more consumer processes — cheap and straightforward under Supervisor/K8s, but each process holds a broker connection and a heartbeat, which the broker team should be told about. Throughput ceiling is per-process and single-threaded by the event loop; heavy message handling (DB writes, HTTP calls) inside the callback will stall the loop and back up the broker. Bound concurrency deliberately and prefer dispatching slow work to Laravel's queue rather than doing it inside the STOMP callback.

Failure modes. The dangerous ones are quiet: socket dropped without a clean close (consumer sits idle, appears healthy), a rejected promise with no handler (message silently lost), ack never sent so the broker redelivers after timeout (duplicate processing downstream — make handlers idempotent), and memory growth in a long-running process that only surfaces after days. Blocking calls inside the loop are the most common self-inflicted failure and the hardest to spot in review. Every one of these needs a metric or a log line, not just a best-effort handler.

Ramp-up. Assume two to three weeks before a mid-level Laravel developer is productive here. The unfamiliar concepts are promises, the event loop, and non-blocking I/O — none of which are common in typical Laravel codebases, and all of which change how you debug (stack traces do not span ticks). Pair the first implementation with someone who has done async PHP before, or accept a slower first delivery. The opportunity: 12.37 signal is the honest read here: the package is under-adopted, and the gap is a well-maintained Laravel-side adapter with lifecycle management and observability baked in. That is a buildable internal asset — but build it deliberately, with the operational scaffolding treated as part of the deliverable rather than an afterthought.