Stomp Laravel Package

Product Decisions This Supports

• Broker integration strategy: Informs whether the product should support STOMP 1.2 brokers (ActiveMQ, RabbitMQ via plugin, Apollo, HornetQ) as a first-class messaging backend. This package is a protocol client, not a framework integration, so the decision is really "do we commit to STOMP as a transport?"
• Build vs. buy vs. fork: A 5-star, zero-dependent, 2015-era package makes the real decision fork-and-own rather than adopt. Useful as a reference implementation or spike to estimate the cost of writing a thin STOMP client in-house.
• Async/event architecture roadmap: Supports decisions about queue-based job dispatch, pub/sub event fan-out, and cross-language interoperability (PHP producers, Java/.NET consumers) where STOMP is the common denominator.
• Enterprise/legacy integration features: Relevant if customers or internal systems already expose STOMP endpoints and you need a low-ceremony PHP client for heartbeats, receipts, transactions, and ack modes.
• Laravel queue driver exploration: A data point for whether to build a custom Laravel queue connector for STOMP versus standardizing on Redis/SQS/database drivers.
• De-risking vendor lock-in: Choosing a protocol-level client over a broker-specific SDK keeps optionality across brokers that speak STOMP 1.2.

When to Consider This Package

Consider it when:

• You have an existing STOMP 1.2 broker and need a minimal PHP client for an internal tool, prototype, or migration bridge.
• You are running legacy PHP (5.x/7.x) code where modern alternatives are unavailable, and the integration surface is small and non-critical.
• You need specific STOMP semantics (heartbeats, receipts, transactions, client/individual ack) and want a compact, auditable codebase to vendor or fork.
• You are evaluating feasibility — a spike to validate connectivity and message flow before committing to a maintained library or in-house implementation.
• Your team accepts ownership: pinning, patching, and writing tests around an unmaintained dependency.

Look elsewhere when:

• You need PHP 8.x / Laravel 10–11 compatibility with active maintenance and security patches.
• The integration is business-critical, high-throughput, or customer-facing — you need observability, reconnect logic, TLS/auth hardening, and community support.
• Your broker speaks AMQP, MQTT, or has a first-party client; use the native protocol rather than STOMP-over-plugin.
• You want a drop-in Laravel queue or broadcasting driver — this is a low-level client, not a framework integration.
• Compliance, supply-chain, or dependency-review policies block packages with no releases since 2015 and no dependents.

How to Pitch It (Stakeholders)

To executives: This is a small, free, protocol-level client that would let us talk to STOMP-based message brokers with minimal code. It is not a strategic bet — it has had no release since 2015, negligible community adoption, and no dependents, so treating it as a maintained dependency would be a mistake. The sensible play is a short, time-boxed technical spike: use it to validate broker connectivity and estimate the effort to own a fork or build a thin client. Expected cost is low; the decision it unlocks is whether STOMP support belongs on the roadmap at all. If we proceed, budget for us to own the code — pin it, wrap it behind an internal interface, and add tests — rather than relying on upstream.

To engineering: It is a compact STOMP 1.2 client covering the core frame types and connection semantics, which makes it easy to audit and fork. Assume no upstream support: vendor it, isolate it behind our own messaging abstraction, add integration tests against the target broker, and verify PHP runtime compatibility before anything ships. If the broker offers AMQP or MQTT, prefer those clients; adopt this only where STOMP is a hard requirement or as a reference for an in-house implementation.