Stomp Laravel Package

Product Decisions This Supports

• Feature viability for event-driven / real-time capabilities. This package is the enabling plumbing for anything that needs PHP to push or consume messages asynchronously — live order-status updates, notification fan-out, telemetry ingestion, cache-invalidation broadcasts, or a consumer that feeds a WebSocket layer. Before committing roadmap space to "real-time," a PM can use this as the cheap technical proof that the async consumer side is buildable in PHP without adding a Node/Go service.
• Broker and vendor-lock-in strategy. STOMP is a text-frame, broker-agnostic protocol spoken by ActiveMQ, Artemis, RabbitMQ (via plugin), and most enterprise ESBs. Choosing a STOMP-based integration path deliberately keeps the broker swappable — a roadmap-level decision about how much we tie our architecture to one vendor's SDK.
• Build vs. buy vs. adopt. The alternative to this package is either (a) hand-rolling STOMP frame parsing, heartbeats, receipts, and ack/nack semantics — weeks of protocol work with subtle failure modes — or (b) licensing a commercial messaging gateway. A mature-enough MIT binding collapses that to an integration task. Frame the decision as "buy the protocol, own the adapter."
• Interop with legacy / polyglot estates. If the company already runs a STOMP-speaking bus for Java/.NET services, this lets a PHP product join that bus as a first-class participant instead of being the team that insists on a new queue just for PHP. That is often a political and architectural win, not just a technical one.
• Scope decisions on queue infrastructure. It supports the "do we need a separate worker tier / sidecar" conversation: a long-running PHP consumer process (artisan command, Octane worker) can replace a whole extra deployable, which changes hosting cost and on-call surface.
• Explicit decision not to invest. With ~114 stars and zero dependents, this is not a mainstream ecosystem bet. That absence is itself a product signal worth putting in the decision record — it belongs in "tactical component," not "platform foundation."

When to Consider This Package

Consider it when:

• The target broker already speaks STOMP, or a STOMP plugin/adapter is a one-line broker config change (common with ActiveMQ/Artemis, possible with RabbitMQ).
• The consumer/producer lives in an already-long-running PHP process — an artisan daemon, a queue worker, or an Octane-served app with an event loop — where non-blocking I/O actually pays off.
• You want a thin, small dependency you could plausibly vendor, fork, or reimplement if upstream goes quiet; the surface area is small enough that maintenance risk is bounded.
• You need interoperability with systems you don't control, and matching their protocol is cheaper than asking them to change.
• The workload is moderate-throughput integration messaging, not high-volume streaming.

Look elsewhere when:

• The need is the ordinary Laravel case: fire-and-forget jobs, retries, backoff, failed-job tables. The framework's database/Redis/SQS queue drivers, Horizon, or Symfony Messenger give you far more operational tooling out of the box. Async HTTP to a broker is the wrong shape for a request-per-process FPM app — you gain no concurrency and add a connection lifecycle problem.
• The broker is RabbitMQ-first and you want the vendor-blessed AMQP semantics and community: php-amqplib, or Symfony Messenger's AMQP transport, are better-supported defaults.
• You require delivery guarantees, transactions, or error semantics you can trust and get support for. A low-adoption binding means you are the QA department for those edge cases.
• Throughput, ordering, or replay are core to the value proposition — Kafka or Redis Streams are the right comparison, not this.
• Procurement or compliance demands a maintained dependency with an SLA, a security response process, and a track record. Zero dependents and low star count mean you cannot infer production hardening from adoption.
• Your team has no ReactPHP/event-loop familiarity and no appetite to acquire it; the async model will be the source of bugs, not the package.

Mitigation if adopted: wrap it in your own MessageBus/Consumer interface so the broker and the binding are both replaceable; pin the version; run integration tests against a containerized broker in CI; accept that you may become the maintainer.

How to Pitch It (Stakeholders)

For executives (one paragraph): We can add real-time and event-driven behavior to our PHP product — live status updates, background message processing, integration with the company's existing messaging infrastructure — using a free, MIT-licensed open-source component rather than building a messaging client ourselves or standing up a new service in another language. It also avoids betting the roadmap on a single broker vendor, since the protocol it speaks is supported by most enterprise message brokers. The honest caveat is adoption: the package is small and niche, so we should treat it as a tactical building block behind our own abstraction layer, not a platform cornerstone. Cost is engineering time, not licensing; the main ongoing cost is that we may need to maintain the integration ourselves.

For engineering leads: It's a thin, typed binding over the STOMP protocol for ReactPHP's event loop — non-blocking connect, subscribe, ack/nack, heartbeats, receipts. It fits long-running processes (worker daemons, Octane) and is a poor fit for classic per-request FPM flows. Recommended posture: adopt behind a first-party adapter interface, pin the version, cover it with integration tests against a real broker in Docker, and budget a small maintenance allowance — the upstream is quiet, but the codebase is small enough that forking is a realistic fallback rather than a crisis. If the actual requirement is ordinary background jobs, we should use the framework's queue drivers and revisit this only when we genuinely need broker-level interoperability or push semantics.