Crossbar Http Publisher Bundle Laravel Package

Product Decisions This Supports

• Real-time delivery architecture for PHP backends. This package is the adapter that lets a server-side PHP app publish PubSub events to a Crossbar.io router over a single HTTP POST, instead of holding a long-lived WebSocket connection open. That unblocks the decision "how do browser/mobile clients get live updates?" without putting a persistent socket daemon inside the PHP request lifecycle — PHP-FPM handles the request, fires the event, and returns.
• Build vs. buy on the publishing layer. Be clear-eyed: the underlying client is a thin HTTP wrapper (POST to the router's /publish endpoint with topic, args, kwargs, and optionally a signed auth key/secret). The bundle adds only Symfony DI wiring — a service definition and configuration. For a Symfony shop already committed to Crossbar, that's a small but real convenience (config-driven topic defaults, auth secrets, injectable service). For anyone else, this is a ~50-line Guzzle/PSR-18 client you could own outright. Do not treat this as a strategic dependency.
• Vendor and infrastructure lock-in scoping. Adopting it means adopting Crossbar.io as a piece of runtime infrastructure — a WAMP router you deploy, monitor, and upgrade. That's the actual decision under review, not the package. The package is the cheap, replaceable part; the router is the commitment.
• Roadmap enablers it makes cheap to prototype: live dashboards and ops consoles, in-app notification fan-out, collaborative editing presence signals, auction/bid or scoreboard updates, cache-invalidation broadcasts, and "someone else changed this record" UX. All fire-and-forget, all one-way.
• Feature-scoping signal for what it does not buy you. HTTP publishing is one-directional and typically unacknowledged. It does not give you delivery guarantees, per-user authorization, message history/replay, presence tracking, or RPC. If a roadmap item needs any of those, the decision is a different one (a hosted service or a router you operate with subscriptions managed client-side).
• ⚠️ Naming correction to carry into any decision record: despite the framing as a "Laravel/PHP package," this is a Symfony bundle (facile-it/crossbar-http-publisher-bundle). It will not install or auto-wire into Laravel. On Laravel, the decision reduces to "use the underlying PSR-18 client, or just call the endpoint directly," and the bundle itself is out of scope entirely.

When to Consider This Package

Adopt it if all of these hold:

• You are on Symfony (with autowiring/attribute config), not Laravel or plain PHP.
• You already run — or have firmly decided to run — a Crossbar.io router; this package is worthless without one.
• Your need is one-way, fire-and-forget event publishing from PHP.
• You value having the publisher as an injectable, configurable service rather than a hand-rolled client.
• Your HTTP client stack is Guzzle 7 (or PSR-18-compatible). Release 2.1.0 adds Guzzle 7 support and deprecates Guzzle 5 and 6 — a forward-looking but real constraint. If you are on an older Symfony (3.x/4.x era) stack still pinned to Guzzle 5/6, you are now on a deprecated path and should either pin the last supported bundle version or plan the Guzzle upgrade; conversely, if you are on a modern Symfony/Guzzle 7 stack, the dependency ceiling that previously made this awkward is gone.
• You accept the maintenance profile: small, single-vendor utility from an agency (Facile-IT), Apache-2.0, low star count and effectively no dependents, with 2.1.0 as the most recent release. The 2.1.0 bump is a modest positive signal — the maintainer is still tracking the ecosystem rather than abandoning the package — but it is still a single-maintainer dependency. Treat it as source you may need to vendor or fork; the license permits it, and the surface area is tiny enough that forking is genuinely cheap.

Look elsewhere if:

• You're on Laravel. Use Laravel Reverb/Echo, Soketi, Pusher, Ably, or Mercure — the bundle does not apply.
• You don't already have a Crossbar router. Standing one up solely to use this package inverts the cost/benefit; a hosted pub/sub or Mercure (Symfony-native, SSE-based, no WAMP) is a far shorter path.
• You need delivery guarantees, acks, replay, per-subscriber authorization, or request/response RPC. WAMP-over-HTTP publish gives you none of that; you need the full WAMP client or a managed service.
• You need zero-ops. Crossbar is infrastructure you operate.
• You are stuck on Guzzle 5/6 and cannot move. The publishing path still works on older releases, but you are adopting a dependency whose maintainer has explicitly signaled the end of that support line — a bad place to start a new integration.
• Your organization has a supply-chain policy that penalizes low-adoption, single-maintainer dependencies. Mitigate by forking — but make that an explicit, owned decision rather than an accident.

How to Pitch It (Stakeholders)

One-liner for executives: A small Symfony integration that lets our PHP backend push live updates to connected users over an HTTP call to a real-time message router — cheap to adopt, cheap to abandon, but it commits us to operating that router.

For engineering leadership: This is a ~50-line HTTP client with Symfony service wiring, not a platform. The real architectural bet is Crossbar.io as our WAMP router. The 2.1.0 release is routine maintenance, not a capability change: it adds Guzzle 7 support and deprecates Guzzle 5/6, which is good news for anyone on a current Symfony stack and a warning sign for anyone still on an older one — check the Guzzle major version before committing. The package is Apache-2.0, has a single maintainer and effectively zero downstream usage, so we should budget for forking it into our own namespace rather than depending on upstream releases — the code is small enough that this is a day of work, not a project. It solves outbound, one-way publishing only; anything requiring delivery guarantees, per-user authorization, message replay, or RPC must be scoped separately, and the "we'll just do it later" answer is usually a different vendor decision. If this assessment is for a Laravel codebase, stop here: the bundle is Symfony-only and the correct comparison set is Reverb/Soketi/Pusher/Ably/Mercure.

Recommendation: Approve as a low-cost, reversible spike if we are a Symfony shop already running Crossbar and on Guzzle 7; otherwise defer, and let the underlying transport decision (router vs. hosted vs. Mercure) drive the choice. Assign an owner to fork-and-pin before it touches production, and record the Guzzle 7 floor in the decision log so a future downgrade doesn't silently strand us on a deprecated client.