Weave Code
Thruway Common Laravel Package
voryx/thruway-common
Shared common components for Thruway, the PHP WAMP (Web Application Messaging Protocol) client and router built on ReactPHP. Provides core protocol utilities and message handling used across Thruway packages for real-time pub/sub and RPC over WebSockets.
voryx/thruway-common provides shared building blocks for Thruway, the PHP implementation of the Web Application Messaging Protocol (WAMP). It contains reusable protocol and support code used by Thruway clients and routers, helping WAMP-based PHP applications stay consistent without duplicating core logic.
- Common WAMP message and protocol support classes
- Reusable utilities shared by Thruway clients and routers
- Interfaces and exceptions for consistent integration
- Composer-installable foundation for WAMP PHP projects
Frequently asked questions about Thruway Common
- What is voryx/thruway-common and what does it actually do?
- It is the shared kernel of the Thruway WAMP2 stack: core interfaces, message type classes, URI validation, error hierarchies, and payload handling for the WAMP2 wire protocol. It does not open sockets or run a loop itself — it provides the protocol value objects consumed by the voryx/thruway router and the Thruway client. In practice you only get meaning out of it when something else is speaking WAMP2.
- Should I require voryx/thruway-common directly in my Laravel composer.json?
- Almost certainly not. Requiring it directly is technically trivial (pure PHP, PSR-4, no extensions) but functionally pointless, because you acquire protocol value objects without the router or client that give them purpose. Genuine integration means pulling voryx/thruway or thruway/client, which drags this package in transitively. Only add it explicitly if you are writing your own WAMP2 implementation or custom message handling.
- Does voryx/thruway-common ship a Laravel service provider, config, or facade?
- No. There is no service provider, no configuration file, no facade, and no Laravel contracts — it is a framework-agnostic protocol library. That is neutral rather than negative: you get zero framework ergonomics and must write all wiring yourself. If you adopt the full Thruway stack, expect to build your own thin client wrapper and manage it as a supervised standalone process.
- Which PHP and Laravel versions does this package support?
- The package is not coupled to any Laravel version because it has no framework dependency at all; check composer.json for the exact PHP constraint, which is likely ^7.4 || ^8.0 on the last release. The more important compatibility question is the ReactPHP event-loop major pinned by whichever Thruway release you pull in. Last tagged release was February 2022, so verify PHP drift against your current runtime before committing.
- How does voryx/thruway-common relate to ReactPHP, and why do Composer conflicts happen?
- The Thruway router and client run on ReactPHP's event loop as long-lived PHP processes outside the PHP-FPM lifecycle. Older Thruway releases pin older event-loop majors, which routinely conflict with other packages already requiring ReactPHP v1, and lockfile resolution failure is the most likely first blocker. Resolve the event-loop major before writing any code, not after.
- Can I use ThruwayCommon to add real-time broadcasting to a Laravel app instead of Reverb, Soketi, or Pusher?
- You can, but WAMP2 is a different model: unified RPC and PubSub over one connection with broker and dealer roles, rather than Laravel's broadcasting abstraction. If your requirement is merely pushing updates to the browser, Laravel broadcasting via Reverb or Soketi, or Mercure over HTTP/SSE, is a far better fit. WAMP2 only justifies itself when you genuinely need both RPC-shaped and PubSub-shaped messaging with cross-language clients.
- Is voryx/thruway-common actively maintained and safe for production?
- Risk is high relative to delivered value: single maintainer, roughly 8 stars, no declared dependents, and a last tagged release in February 2022 with no evident security-response process. The WAMP2 wire format itself is a stable spec and will not break, but PHP and ReactPHP version drift will. Treat it as a pinned, vendored-style dependency rather than something you expect upstream fixes for.
- What are the operational requirements for running a Thruway-based stack alongside Laravel?
- You need to operate and supervise a persistent PHP worker under Supervisor or systemd, alongside PHP-FPM, with health checks and drain-on-deploy. The router deployment dominates the effort — far more than anything ThruwayCommon provides. Keep WAMP at the edge as its own process and do not thread it through domain code.
- How do I test code that uses ThruwayCommon message objects?
- The message types and URI validation are plain value objects, so most of your tests are ordinary unit tests with no router, socket, or event loop involved — construct a message, assert serialization and error behavior. Integration tests are where cost appears, since they need a running router or a fake transport. Stub the client wrapper at the Laravel boundary so domain tests never touch WAMP.
- What are the alternatives to ThruwayCommon, and what is the exit path if upstream stalls?
- For WAMP2 specifically you can swap the router for Crossbar or a Node/Go implementation while keeping clients on the same wire protocol, provided your protocol boundary is clean. If you are not committed to WAMP2, migrate toward Mercure for HTTP/SSE or Reverb/Soketi for native Laravel broadcasting, both of which preserve the pub/sub semantics you would actually be exercising. Do not migrate toward this package — the effort is dominated by router deployment and operational ownership, not by the library itself.
Weaver
How can I help you explore Laravel packages today?