Stomp Bundle Laravel Package

Technical Evaluation

Architecture fit: structurally incompatible — this is a Symfony2 bundle, not a Laravel package. Despite being routed through a Laravel/PHP package evaluation, happyr/stomp-bundle registers through Symfony's Bundle class and a DependencyInjection\Extension with a semantic configuration tree. Laravel's kernel never invokes those mechanisms. Laravel consumes Symfony components (HttpFoundation, Console, Finder), not the Symfony framework, so bundle registration, compiler passes, and services.xml wiring have no runtime equivalent in our stack. There is no service provider, no config/ publish step, no facade, and no container binding — the four things that would make it installable. Nothing here drops in.

Integration feasibility: the wrapper is thin enough that reimplementation beats porting. Stripping the Symfony plumbing reveals what the bundle actually does: normalize broker credentials from config, construct a stomp-php client, register it as a container service, and expose it for publishing. In Laravel that is roughly a 150-line service provider plus a config/stomp.php plus an env-driven connection block. We would not port the bundle; we would rebuild the 5% of it that has value against the underlying client — or skip the client entirely and use a maintained transport. Porting effort and building effort converge at roughly one to two engineering days, which is the honest cost floor.

Technical risk: high, and concentrated in abandonment rather than code quality.

• Symfony 2.8 reached end-of-life in November 2018. Composer constraints will very likely block installation on PHP 8.2+ and any modern Laravel release — verify composer.json before spending further time.
• 1 star, 0 dependents, no release cadence means zero community surface: no issue triage, no security response, no PHP-version compatibility patches. This is a dead artifact, not a low-activity one.
• Transitive risk sits with stomp-php itself. That library has changed stewardship and moved on; this wrapper has not followed it, so the pairing is unverified against current broker versions.
• License and PHP floor are unconfirmed until composer.json is read — check both before any design commitment.

Key questions a TPM should get answered before resourcing anything:

1. Is the target broker genuinely STOMP-only (ActiveMQ Classic, Artemis, HornetQ), or is AMQP available? If RabbitMQ with the AMQP adapter is on the table, this entire package and the surrounding discussion are irrelevant.
2. Do we need STOMP-specific semantics — receipts, transactions, client/client-individual ack modes, heartbeats — or just publish and consume? The former justifies a custom adapter; the latter justifies a maintained library.
3. What is the current maintenance state of stomp-php itself, independent of this bundle? That, not this bundle, becomes our real dependency.
4. Does a maintained Laravel queue driver already cover the broker (AMQP driver, laravel-queue-rabbitmq)? If yes, custom code drops to zero.
5. Who owns the adapter internally if upstream is gone — and is that headcount actually allocated to this quarter's roadmap, or aspirational?

Integration Approach

Stack fit: near zero as-is; valuable only as a pattern reference. Assume Laravel 10/11 on PHP 8.2+. The first gate is mechanical: read the bundle's composer.json. If it pins symfony/symfony ~2.x or a PHP floor of 5.x, installation is a non-starter and the decision closes without further analysis. Everything below assumes that gate fails, which is the expected outcome.

Migration path — three options in preference order:

1. Drop the package; adopt a maintained transport. If the broker speaks AMQP, use an established Laravel queue driver and inherit retries, failed-job persistence, and Horizon-style visibility for free. Highest operational leverage, smallest custom surface, shortest time to production. This is the default recommendation unless the broker is hard-locked to STOMP.
2. Drop the bundle; use the STOMP client directly. Add the current stomp-php release, write a Laravel service provider that binds a configured client from config/stomp.php, and expose publish/consume through one thin application-facing service. We inherit the client's maintenance posture instead of the bundle's abandonment.
3. Port the bundle's wiring only. Lift its connection-factory and config-normalization logic into a service provider with attribution and license compliance. Only justified if the bundle encodes non-obvious broker quirks — unlikely for a wrapper this thin, but worth a 30-minute read of DependencyInjection/Configuration.php before dismissing.

Compatibility work if we pursue STOMP: the configuration idiom differs fundamentally (Symfony semantic config with defaults and validation vs Laravel config/*.php merged with env vars). Any bundle-provided console commands must be re-expressed as Artisan commands; any event subscribers as Laravel listeners. Assume zero reuse of service definitions — the YAML/XML wiring is not translatable.

Sequencing:

1. Two-day spike: connect an Artisan command to a real broker instance using raw stomp-php. This validates broker address, TLS, auth, and topology before any design work — and kills the initiative cheaply if the broker is unreachable or the client is incompatible.
2. Transport decision checkpoint: STOMP client vs maintained AMQP driver. Document the tradeoff explicitly and get it signed off, because reversing it later is a rewrite of the consumer path, not a config change.
3. If STOMP: build the service provider, config file, and a health-check Artisan command that proves broker connectivity on demand.
4. Consumer integration: wire into queue:work semantics with explicit ack, bounded retry, and a failure/quarantine path.
5. Observability before cutover: connect/disconnect/message counters, queue-depth alerts, and a publish canary. Do not ship into production without the canary.

Operational Impact

Maintenance: fork-and-own, and it must be budgeted as a line item. Upstream is dormant, so any fork assumes the full burden — PHP version bumps, client library upgrades, broker compatibility verification against Artemis/ActiveMQ releases. Steady state is a few days per year; a PHP major upgrade is unbounded until someone does the work. If that budget cannot be named, the correct answer is the maintained AMQP path.

Support: there is no external escalation path. Bugs become our bugs by default, with no upstream to file against and no dependent community to have already hit the same issue. This creates knowledge-concentration risk: at least two engineers must understand the messaging path, or a single on-call incident becomes a bus-factor event. Broker topology, ack semantics, and reconnect behavior belong in the runbook, not in one person's head.

Scaling: the STOMP client is synchronous and connection-oriented, so scale by adding worker processes and connections — there is no library-level tuning to reach for. Long-lived queue:work processes are the pressure point. Stale connections after a broker restart or network partition are the classic failure, and reconnect behavior depends entirely on the underlying client, not on this bundle. Prefer supervised workers with bounded --max-time so processes recycle, plus a readiness check that actually validates broker connectivity rather than just process liveness.

Failure modes to design for explicitly:

• Silent consumer death — worker process alive, connection dead, queue backing up invisibly. Needs a heartbeat or periodic publish test plus alerting on queue depth, not just process health.
• Message loss on ack — without client-individual ack and explicit failure handling, a crashed worker drops in-flight messages. There is no dead-letter concept in this stack; we build one or accept loss as a documented risk.
• Poison messages looping indefinitely — requires a retry counter and quarantine path we own. The bundle contributes nothing here.
• Memory growth in long-running consumers — mitigate with worker recycling and a memory ceiling.
• TLS/credential rotation — no dynamic reload; rotation means coordinated worker restarts. Put it in the change calendar, not the incident process.

Ramp-up: STOMP is a small protocol and an engineer will be productive in days, not weeks. The real ramp is broker operations (topology, persistence, flow control, ack tradeoffs) and Laravel queue-worker lifecycle — neither of which this package helps with. Net: low learning cost for the code, meaningful cost for the operational surface we are choosing to take on.

Recommendation: do not adopt. The bundle is a thin, unmaintained wrapper built for a framework and a framework version we do not run. Use a maintained transport if the broker allows it; if STOMP connectivity to an existing enterprise broker is a hard business requirement, take stomp-php directly and own a small, well-understood Laravel service provider behind our own interface — which keeps the transport swappable and confines the dependency footprint to one actively maintained library.