Crossbar Http Publisher Bundle Laravel Package

Technical Evaluation

Architecture fit — primary finding unchanged: this is not a Laravel package. facile-it/crossbar-http-publisher-bundle is a Symfony bundle. It ships a Bundle class, a DependencyInjection/*Extension with a Configuration tree, and service wiring consumed by Symfony's container compiler passes. None of that executes under Laravel's container lifecycle. There is no service provider, no facade, no publishable config, and no Laravel-tagged release. Treat this as a reference implementation, not a dependency.

What release 2.1.0 changes — and what it does not. The 2.1.0 notes are narrow: added support for Guzzle 7, deprecated support for Guzzle 5 and 6. There is no Laravel service provider, no facade, no config stub, no framework-agnostic core extraction, and no change to the Symfony DI surface. The framework-mismatch finding is untouched, and the adoption verdict therefore stands. Two secondary observations are worth recording:

1. Maintenance signal (positive, minor). A release inside the window since the 2025-03-12 publication is weak but real evidence of a live maintainer. It nudges the abandonment risk down slightly; it does not convert a single-maintainer, ~10-star, zero-dependent package into a supported dependency.
2. Transport assumption corrected (positive for our path). Version constraints expressed directly against Guzzle indicate the bundle's HTTP transport is Guzzle/HTTPlug-backed rather than a clean symfony/http-client implementation — the earlier assessment's "Symfony HttpClient → Http facade" mapping was directionally right but imprecise. This is materially good news for us: Laravel's Illuminate\Support\Facades\Http is Guzzle 7 under the hood, so a reimplementation runs on the same transport generation the bundle now targets. Request signing, header handling, timeout, and retry semantics can be reasoned about with near-parity, and the Guzzle 7 requirement aligns exactly with Laravel 10/11/12's own dependency floor.

The Guzzle 5/6 deprecation is irrelevant to our decision, because we are not installing the package. It would only matter to an existing Symfony consumer pinned to an older Guzzle — a population we are not in. It is a forward-looking hygiene change, not a breaking change for anyone on a modern stack.

What the package actually does remains narrow and replicable: it takes a topic plus args/kwargs, serializes them, and issues an HTTP POST to a Crossbar router's HTTP Publisher endpoint using the publisher's public key and secret (HMAC-signed request, per Crossbar's HTTP Publisher auth contract). That is an Http::withHeaders()->post() call plus a signing helper — roughly 80–150 lines to reproduce idiomatically in Laravel.

Integration feasibility: high, and marginally better than at first assessment. The protocol surface is small and stable; the transport is now confirmed as Guzzle 7, matching our own. Reimplementation risk stays low and bounded. The real cost is not code, it is protocol literacy — WAMP topic naming, args vs kwargs semantics, and the router-side publisher registration that must exist before your first publish succeeds.

Technical risk profile (revised)

Key questions to resolve before commitment (unchanged — 2.1.0 answers none of them)

1. Does a Crossbar router with the HTTP Publisher transport enabled already exist in our estate, and who owns it? (If no router, this package is moot.)
2. Do we need guaranteed delivery, or is best-effort fan-out acceptable? Best-effort is a much cheaper design.
3. Is the publisher credential rotation story defined on the Crossbar side (pubkey/secret lifecycle, clock skew tolerance)?
4. What is the subscriber population — internal Laravel services, or external/third-party?
5. Why WAMP at all versus Redis Pub/Sub, SNS, or Laravel's own broadcasting (Reverb/Pusher)? The answer determines whether this is a 2-day adapter or an architecture decision.

Integration Approach

Stack fit. Laravel is a stronger host for this than Symfony would be: Illuminate\Support\Facades\Http (Guzzle 7-backed) covers transport, config/ covers configuration, the container covers binding, and the queue covers durability. Everything the bundle provides maps to a first-class Laravel primitive — and 2.1.0's Guzzle 7 floor now matches our runtime exactly, so there is no version negotiation to perform.

Recommended shape (do not port the bundle):

• config/crossbar.php — base_url, realm, publisher_key, publisher_secret, timeout, retry, queue.
• CrossbarPublisher interface with a single publish(string $topic, array $args = [], array $kwargs = []): void method — this is the seam that keeps us vendor-neutral.
• HttpCrossbarPublisher implementation using the HTTP client, with signing isolated in a small RequestSigner class so it is unit-testable in isolation.
• CrossbarServiceProvider binding the interface as a singleton; optional Crossbar facade for ergonomics.
• PublishEventJob (queued, tries/backoff configured) so publishes never block a request cycle.

Migration path from the bundle's concepts. The mapping is mechanical and can be done in a single sitting:

Compatibility notes. Target PHP 8.2+ and Laravel 10/11/12; the bundle's own constraint set is irrelevant since we are not installing it — though it is now reassuringly convergent with ours on Guzzle. Confirm the Crossbar HTTP Publisher endpoint version on the router (v1 vs v2 routers differ in auth header handling). If we ever add a Symfony service to the estate, the adapter interface ports unchanged — this remains the main benefit of owning the seam.

Sequencing (suggested, ~2 sprints — unchanged by 2.1.0)

1. Spike (2–3 days): stand up or borrow a Crossbar router, register a publisher, publish manually via curl to confirm signing, headers, and payload shape. This de-risks 80% of the unknowns.
2. Adapter (3–5 days): interface + HTTP implementation + signer + config + service provider, with contract tests against the spike router.
3. Durability (2–4 days): wrap in queued job; decide retry/backoff and dead-letter handling.
4. Observability (1–2 days): structured logs on publish, a metric for publish latency and failure rate, a health check.
5. Rollout: shadow-mode publishes behind a flag before any subscriber depends on them.

Operational Impact

Maintenance. Low and ours. We own ~150 lines instead of inheriting a low-traffic third-party bundle — a net positive. 2.1.0 slightly softens the counter-argument: the upstream is demonstrably alive and tracking Guzzle majors, so if we had adopted it we would not be stranded. But "not stranded" is not the same as "supported," and we still would not get upstream protocol changes as composer updates; we must watch Crossbar release notes ourselves. Pin the router version in infrastructure-as-code so protocol drift is a deliberate decision rather than a surprise.

Support. Community support is effectively absent: a Symfony-focused maintainer, ~10 stars, no dependents, no Stack Overflow corpus. 2.1.0 does not change this — a changelog entry is not a support channel. Internal documentation is mandatory, not optional: a short runbook covering topic naming conventions, credential rotation, and "what to do when publishes fail" is the difference between a 15-minute and a 4-hour incident.

Scaling. The HTTP Publisher path is synchronous per request and offers no broker-side buffering — Crossbar accepts the publish and fans out; it does not queue for offline subscribers. Throughput is bounded by HTTP round-trip latency against the router. Mitigations:

• Always publish from the queue, never inline in a web request; scale workers independently.
• Batch or coalesce high-frequency topics where subscriber semantics allow.
• Set aggressive-but-sane timeouts (2–5s) and a bounded retry (2–3 attempts with jittered backoff) to avoid retry storms during router restarts.
• Use connection reuse (persistent Guzzle 7 client) to avoid TLS handshake cost per publish — the same transport generation the bundle now standardises on, so tuning guidance transfers.

Failure modes to design for explicitly

• Router unavailable → publish throws; without an outbox, events are silently lost on worker retry exhaustion. For anything business-critical, adopt a transactional outbox table drained by a publisher worker. Decide this before rollout, not after the first data-loss incident.
• Auth failure (bad signature / expired key / clock skew) → surfaces as 401/403; distinguish this from network errors in logging so it is not misdiagnosed as an outage.
• Partial delivery → success means "router accepted," not "subscribers received." Do not build correctness guarantees on top of it.
• Poison messages → an oversized or malformed payload will retry until exhaustion; validate payload shape client-side.
• Silent fan-out gaps → no subscriber-side ack; add periodic synthetic publishes with a known subscriber for end-to-end monitoring.

Ramp-up. A PHP developer unfamiliar with WAMP needs roughly half a day on concepts (realm, topic, pub/sub vs RPC, publisher registration) and one day pairing on the adapter to be productive. The bundle itself teaches little — it is thin — so onboarding effort is concentrated on Crossbar, not on this package. Guzzle 7 familiarity, which any Laravel developer already has, now covers the transport layer outright. Budget accordingly: the router is the system to learn, and the router is where the operational risk actually lives.

Verdict — unchanged, with one note. Do not adopt the dependency; adopt the pattern. Release 2.1.0 is a routine dependency-hygiene release: it improves the package's maintenance optics and confirms Guzzle 7, which happens to be the exact transport Laravel's HTTP client uses — but it introduces no Laravel affordance, no framework-agnostic core, and no change to the Symfony coupling that blocks installation. The package still scores low on ecosystem signals (0 dependents, single maintainer, framework mismatch) and high on opportunity, because the problem remains under-served: nobody has built the Laravel equivalent. A small owned adapter behind a stable interface is cheaper, safer, and more debuggable than any attempt to shoehorn a Symfony bundle into a Laravel application. Re-evaluate only if a future release ships a framework-agnostic core or an official Laravel service provider.