Thruway Bundle Laravel Package

Product Decisions This Supports

• Real-time feature scoping — whether to ship push-based experiences (live notifications, presence, activity feeds, ops dashboards) or continue with polling. This package represents the "PHP process as a first-class real-time publisher/subscriber" option in that debate, so evaluating it forces the team to define what "real-time" means for the product before committing budget.
• Transport/protocol standardization — WAMP2 gives topic-based pub/sub and RPC over a single persistent connection. This supports a roadmap decision to standardize on a broker-mediated event bus rather than ad-hoc per-feature sockets or webhook plumbing.
• Build vs. assemble for messaging — adopting a WAMP router plus client is "assemble" for transport, letting roadmap effort go into domain events instead of socket lifecycle, reconnect, and fan-out logic. Weigh this against the recurring cost of owning an unmaintained integration.
• Polyglot interoperability — WAMP has clients in JS, Python, PHP, and more. Relevant only if the roadmap includes non-PHP services or dashboards that must subscribe to the same event stream.
• Legacy estate sequencing — if an acquired or retained Symfony 2.x app has a committed real-time feature, this is a low-effort bridge that keeps that work off the critical path of a framework migration.
• Not supported: the Laravel roadmap. This is a Symfony 2 bundle, not a Laravel package. For a Laravel product it informs architecture thinking only — it is not a shippable dependency decision.

When to Consider This Package

Consider it when all of these hold:

• You maintain a Symfony 2.x application (or a fork of one) and real-time is a near-term, funded requirement.
• You need WAMP2 specifically — pub/sub and RPC over one connection — not merely a WebSocket.
• A WAMP router (Crossbar.io or equivalent) is already, or is about to be, production infrastructure with a named owner.
• PHP must be a first-class publisher/subscriber, not just a token-authenticating front end.
• You accept owning the code: the bundle is thin DI glue over the thruway client, so fork-and-pin is a realistic plan.

Look elsewhere when:

• The stack is Laravel. Use first-party broadcasting with Reverb, or Pusher/Soketi, plus Echo on the client. WAMP adds nothing the framework doesn't already model, and none of this bundle's Symfony wiring transfers.
• The stack is Symfony 4/5/6/7. This targets Symfony 2 conventions; prefer Symfony Mercure or a maintained purpose-built bundle.
• Dependency hygiene is a gate. Last release July 2019, 0 dependents, 98 stars. Treat it as unmaintained: no security patching, no PHP 8.x guarantees, no support path. If the org requires an SLA or an active maintainer, it fails.
• You only need one-way server→client updates. SSE is simpler and cheaper than operating a router.
• Nobody on the team has run a WAMP broker — the router becomes a new stateful production dependency with its own auth, scaling, and failover story.
• You need horizontal scale and observability on day one — a hosted pub/sub service is less total effort.

How to Pitch It (Stakeholders)

For executives (one paragraph): This is a small, unmaintained integration library that lets a PHP back end publish and subscribe to real-time events through a WAMP message router. It is not a Laravel package — it targets Symfony 2, which is end-of-life — so I do not recommend adopting it in our product. It is valuable to us as a reference design for how a topic-based event bus would be wired into PHP, and as a stopgap only if we acquire or continue to run a Symfony 2 application where a real-time feature is already committed. License cost is zero; total cost of ownership is not, because we would be forking and maintaining it ourselves.

For engineering (the ask): If we pursue real-time, the decision to make is protocol and transport, not this library. On Laravel that means broadcasting + Reverb (or a managed Pusher-compatible service) with Echo on the client — first-party, maintained, already documented. On modern Symfony it means Mercure. Choose WAMP only if a polyglot, router-mediated event bus is a genuine cross-service architectural requirement; in that case vendor and pin the thruway client and treat the bundle as a pattern to reimplement rather than a dependency to install.

Bottom line: adopt no for a Laravel product; mine it for architecture guidance; consider only as a legacy Symfony 2 bridge with an explicit owner and a dated plan to exit.