Stomp Php Laravel Package

Technical Evaluation

Architecture fit. fusesource/stomp-php is a low-level STOMP protocol client, not a Laravel package and not a queue driver. Laravel's queue abstraction is built around Redis, SQS, database, and Beanstalkd, with RabbitMQ normally reached via php-amqplib. STOMP is a text-oriented protocol typically fronting ActiveMQ/Artemis, HornetQ, or RabbitMQ's STOMP plugin. The fit is therefore narrow and conditional: this package is appropriate only when the organization already operates a STOMP-speaking broker and needs a PHP/Laravel process to publish or consume against it. For "async jobs in Laravel" as a generic requirement, it is the wrong tool — native queue drivers deliver the same outcome with far less operational cost.

Integration feasibility. There is no service provider, facade, config publishing, or queue connector. A TPM should budget explicitly for glue work: a container singleton for the connection, a config/stomp.php, a StompPublisher/StompConsumer wrapper, and manual lifecycle management (connect, subscribe, readFrame, ack, disconnect). The fork lineage matters: this repo (dejanb/stomp-php) is a fork of the original FuseSource package, and with 0 dependents there is effectively zero ecosystem validation. Composer install may also be gated by legacy PHP version declarations. All of this is estimable work — but it is additional work beyond "add a dependency."

Technical risk. High. The package is effectively dormant, predates modern PHP releases, and its compatibility with PHP 8.x, PSR-4 autoloading, and strict types is unverified. There is no visible CI, no security disclosure process, and negligible community surface (92 stars, 0 dependents). Protocol concerns that matter in production — heartbeats, reconnect/backoff, transactional acks, failover, DLQ interaction — are likely incomplete or untested. The dominant risk is not that it fails in a spike; it is that it becomes unmaintained code sitting on a critical messaging path with no upstream to escalate to.

Key questions.

• Which broker and protocol does the target environment actually run, and is STOMP mandated or merely incidental? (If incidental, exit this evaluation and use a native driver.)
• Has the maintained successor stomp-php/stomp-php been evaluated against this fork? It is a near drop-in API replacement and materially reduces risk.
• What delivery guarantees are required — at-least-once, transactional, ordered? Does the client support them, or must the adapter compensate?
• Is the workload request-scoped publishing or long-lived queue workers? This changes the entire operational model.
• Who owns patching and PHP-version bumps if upstream goes silent — and is that funded?

Integration Approach

Stack fit. Treat this as a narrow adapter behind an internal interface, never as a pervasive dependency. Define MessagePublisher and MessageConsumer contracts in the application and implement them with the STOMP client; controllers, jobs, and listeners depend only on the interface. This keeps the library a swappable detail and makes a future migration to stomp-php/stomp-php, AMQP, or a native driver an implementation change rather than a rewrite. If Laravel-native async is the actual requirement, do not adopt this at all.

Migration path. Preferred sequence is to evaluate the maintained fork first and only fall back to this repository under a hard constraint. Where this fork is used, vendor it: pin the version, commit the source into the repo, and document a patch policy with a named owner. For Laravel, register the connection as a singleton in a service provider, publish config, and wrap publish/subscribe in queued jobs or artisan commands — do not invoke it inside HTTP request cycles. If Octane or Swoole is in play, add an explicit connection reset hook; a dropped socket bound to request scope will poison subsequent requests.

Compatibility. Validate PHP version support before committing to an estimate — assume PHP 5.x/7.x-era code until proven otherwise. Check for ext-sockets/ext-pcntl requirements, blocking I/O behavior that could stall FPM workers, autoloading style, and namespace collisions with existing queue/event infrastructure. Test against the exact broker version and STOMP protocol level (1.0/1.1/1.2) in staging, not against the default in the README.

Sequencing.

1. Spike (days, not weeks): prove connect/publish/subscribe/ack round-trip against the real broker from a throwaway Laravel app. Gate all further investment on this.
2. Decide: adopt stomp-php/stomp-php unless a documented constraint forces this fork.
3. Abstract: land MessagePublisher/MessageConsumer interfaces and the adapter behind them, with config and service provider.
4. Harden: implement reconnect, heartbeat, read timeout, and dead-letter handling explicitly — assume the library provides none of it.
5. Roll out: one non-critical consumer with metrics and alerting, then expand scope. Publish-only paths are lower risk and can go first.

Operational Impact

Maintenance. The primary cost and the thing most likely to be under-estimated. Upstream is dormant, so the team owns bug fixes, PHP version bumps, and security patches indefinitely. Fund a recurring maintenance line item and a documented fork strategy; without a named owner this silently becomes technical debt on a critical path.

Support. Effectively none — no vendor, no active maintainer, negligible community. Internal runbooks, broker documentation, and a named on-call owner are mandatory rather than nice-to-have. Escalation paths must end internally, not upstream.

Scaling. The client is stateless, so throughput scales with worker count and broker capacity. Two constraints matter: each worker holds a persistent connection, so deploy events and broker restarts create connection storms; and long-lived consumers must run under a supervisor (Horizon-style or supervisord) with graceful shutdown and bounded reconnect backoff. Document connection ceiling per worker pool before scaling out.

Failure modes. Connection loss without automatic recovery; message loss where acks or transactions are not implemented correctly; blocking reads stalling request workers; heartbeat misconfiguration producing zombie connections; broker-side queue buildup invisible to application telemetry. Because the library will not surface these, each requires explicit detection and alerting built in the adapter — lag metrics, reconnect counters, DLQ depth, and ack-failure rates. Budget this observability work as part of the adoption, not as a follow-up.

Ramp-up. Moderate. STOMP itself is simple to learn, but engineers must absorb broker semantics (destinations, ack modes, transactions, DLQs) plus the custom lifecycle code the adapter introduces. Expect a short protocol learning curve and a significantly longer one around failure handling — that is where incidents concentrate and where documentation investment pays back fastest. A TPM should plan for one engineer to own the messaging integration end-to-end rather than distributing it as incidental work.