Thruway Laravel Package

Product Decisions This Supports

• Build vs. buy for real-time infrastructure. Thruway is a self-hosted, MIT-licensed implementation of WAMP (Web Application Messaging Protocol), giving you both a broker (pub/sub) and a dealer (RPC) in one protocol. The decision it informs: do we pay Pusher/Ably per-message, adopt Laravel Reverb, or run our own router? Thruway is the only one of those that keeps the router in PHP and adds RPC semantics alongside broadcast.
• Feature scope for live/multi-user surfaces. Useful when scoping live dashboards, presence, collaborative editing cursors, in-app notifications, live ops/telemetry views, or device/IoT status feeds — anywhere the product needs server→client push plus client→server calls over one persistent connection.
• Architecture roadmap: single-runtime vs. polyglot. If the org is PHP-only and you don't want to stand up a Node/Go/Elixir service just for sockets, Thruway keeps the real-time tier inside the Laravel/PHP operational envelope. Conversely, if you already run Crossbar.io or Autobahn clients, this is the PHP bridge that avoids adding a second protocol.
• Protocol/vendor lock-in strategy. WAMP is an open spec with implementations across Python, JS, C++, Java. Choosing it is a deliberate hedge against managed-vendor lock-in — worth weighing against the managed-service convenience you give up.
• Cost modeling at scale. Self-hosted routing converts a variable per-connection cost into a fixed infra + on-call cost. The PM decision is the crossover point: at what concurrent-connection or message volume does owning the router beat the managed bill, including the engineering time to maintain it?
• Buy-in for a maintenance budget. The package's last release was Feb 2022 and it sits on Ratchet/ReactPHP version constraints. Any decision to adopt should be paired with a decision to own it — a fork, a pinned dependency policy, and a named maintainer. That's a resourcing decision, not just a technical one.
• Deployment model decision. It requires a long-running process (Supervisor/systemd), which is a real departure from PHP-FPM request/response. It informs whether the team is willing to take on process supervision, health checks, graceful reload, and horizontal-scaling/sticky-session work.
• Explicit non-decisions. It should not be used to decide your standard real-time stack for a mainstream Laravel product — that decision is better served by Laravel Reverb or a managed provider. Framing it as an option, not a default, is itself the PM output.

When to Consider This Package

Consider it when:

• You have an existing WAMP footprint — Crossbar.io router, Autobahn|Python/JS clients, or a partner integration speaking WAMP — and need a PHP participant or an in-process PHP router.
• You specifically need RPC/dealer semantics with argument validation, routing, and result callbacks over the same channel as pub/sub — not just one-way broadcast.
• You're building internal tooling, prototypes, or low-volume ops dashboards where a single PHP daemon is acceptable and the blast radius of maintenance debt is small.
• You have infrastructure constraints (air-gapped, on-prem, no managed-service procurement) and must self-host everything.
• Your team is PHP-only and staying that way, and the alternative is introducing a new language runtime into production.

Look elsewhere when:

• You need a maintained, supported baseline on modern PHP (8.2+) and current Laravel. Thruway's 2022 release cadence and Ratchet/ReactPHP pinning make this a fork-and-own commitment, not a composer require and forget.
• Your need is simply "push updates to the browser." Laravel Reverb (or Soketi/Pusher/Ably) is the first-party path with broadcast auth, Echo integration, and a hiring pool that already knows it. WAMP adds a protocol your team will have to learn as a second vocabulary.
• You need managed scale — hundreds of thousands of concurrent connections, global edge, 99.99% SLAs. That's Ably/Pusher territory; self-hosted PHP will not get you there cheaply.
• You need durable messaging, replay, or exactly-once delivery. WAMP is a real-time transport; use Kafka, RabbitMQ, or Redis Streams for guarantees and treat the socket layer as ephemeral.
• You need first-class Laravel integration — a broadcast driver, queue/event bridging, guard-based authorization. Thruway has none of this out of the box; you'd write and own the glue.
• Your organization lacks appetite for an unsupported dependency or a long-running-daemon ops model.

Risk factors to log alongside adoption: low opportunity signal in the package scoring, single-maintainer risk, thin documentation relative to the Laravel ecosystem, and a small hiring pool for WAMP-specific debugging.

How to Pitch It (Stakeholders)

To executives: An open-source, MIT-licensed messaging layer that lets us run our own real-time infrastructure in PHP instead of paying per-message to a managed vendor — with a built-in RPC channel alongside pub/sub, which most managed broadcast services don't offer. The trade-off is ownership: the library hasn't shipped a release since early 2022, so adopting it means funding maintenance, not just integration. Recommendation: fund a short spike against a real use case, and only commit if the WAMP interop or self-hosting savings are concrete and measurable. Do not make it our default real-time stack.

To engineering: It's a PHP client and router for WAMP, built on Ratchet/ReactPHP — pub/sub and RPC over one WebSocket connection, no extra runtime. Costs you a long-running daemon (Supervisor, health checks, graceful reload) and a dependency we'd likely need to fork for PHP 8.2+/current Ratchet. No Laravel broadcast driver or auth integration ships with it; that glue is ours to write. Recommendation: scope it as a bounded service behind an interface, so swapping to Reverb, Soketi, or a managed provider later is a config change rather than a rewrite.

To the product team: It makes live, multi-user, and device-facing features feasible without adding a new backend language or a managed-service line item — but it also makes our release cadence partly dependent on code we maintain ourselves. Treat it as an enabler for a specific roadmap bet, not as platform plumbing.