Product Decisions This Supports
- Build vs. buy for real-time features. This package is the "build the protocol layer" option in a three-way decision: managed service (Pusher/Ably), first-party server (Laravel Reverb), or protocol library (this). It does not decide the product question — it decides how much of the stack you own. Framing it as "the WebSocket dependency" overstates it: it is roughly 10% of a real-time feature and 0% of the channel, presence, auth, and delivery semantics a product team actually ships.
- Feature scoping and honest roadmap sizing. Useful as a scoping instrument. A spike proves feasibility in 1–2 engineer-weeks; a single user-facing feature on a single node lands around 3–5 engineer-weeks; production-grade single node is 6–10; horizontal scale adds another 4–8. That is the true cost of "add live updates," and it should enter the roadmap as a named initiative, not a backlog line item.
- Use cases where the protocol layer earns its keep: custom subprotocol negotiation, non-standard frame or compression policy, client-side handshake (connecting out to third-party WebSocket APIs), or embedding sockets into an event loop the team already runs. These are the differentiators a higher-level server cannot give you.
- Use cases where it is the wrong lever: chat, notifications, live dashboards, collaborative presence — anything that maps cleanly onto channels, broadcasts, and presence. Those are 80%+ of real-time product asks, and Reverb or a managed service prices them dramatically lower.
- Architecture decision with product consequences. Adopting it ratifies a two-tier system: Laravel as system of record, a separate long-running socket process as the real-time edge. That is a platform commitment affecting deploys, on-call, capacity planning, and hiring — a decision worth an explicit ADR rather than a Composer require.
- Differentiation check. Ask what users get from this that Reverb plus Echo cannot deliver. If the answer is "nothing specific," the build is not justified by product value. If the answer is "custom subprotocol for X integration," that is a real reason and should be documented.
- Scope discipline for delivery semantics. Durable delivery, replay, and at-least-once guarantees are not in this package. Any product promise like "messages are never lost" becomes a design and estimate item above the transport. Better to catch that in discovery than in a launch retro.
When to Consider This Package
- You have a specific protocol-level requirement that a higher-level server does not expose: custom subprotocols, control over frame sizing or permessage-deflate policy, handshake behavior Reverb will not let you tune.
- You need client-side handshake — your PHP service acts as a WebSocket client to an external endpoint. This is a genuinely underserved case and a strong fit.
- You already run, or are committed to running, an event loop (ReactPHP or Amp) and have the operational muscle for a long-lived process.
- You are building a platform primitive other teams will consume, where owning the wire contract is strategically worth the maintenance burden.
- Look elsewhere — Laravel Reverb or a managed service — when: the need is broadcast/rooms/presence; the team has no event-loop experience; there is no named on-call owner; the timeline is measured in weeks; or you rely on Laravel Echo's channel authorization semantics and do not intend to rebuild them. That rebuild is the single most common source of estimate slippage here.
- Look elsewhere immediately if: you expect "install the package and add a Laravel feature." This library owns no I/O, ships no service provider, no facade, no config. Everything above the frame is yours.
- Governance flags before adopting: it is pre-1.0 (0.4.0 changed the HTTP abstraction and raised the PHP floor — plan for breaking changes); adoption signals are thin in our scan (236 stars, near-zero direct dependents), though that understates usage because
ratchet/ratchet is the primary consumer; there is no commercial support; and the recorded last release date is anomalous (a future date) — verify tag provenance and signing before pinning. Treat release cadence as unproven until confirmed.
- Kill criteria to set up front: no spike result within two weeks, no designated owner, or an unresolved why-not-Reverb answer. Any of those should end the build rather than let it drift.
How to Pitch It (Stakeholders)
To executives: This is a building block, not a product. It is a small, MIT-licensed, spec-compliant WebSocket protocol library — think of it as the plumbing for the pipe, not the pipe, and certainly not the water. It passes the industry conformance suite (Autobahn), integrates cleanly with modern PHP HTTP standards, and imposes no framework coupling, which is a genuine long-term advantage. But it handles only the wire format. Everything a customer experiences — connections, authentication, presence, message routing, reconnection, scaling — we would build and then operate indefinitely. The realistic cost of a production real-time capability is 6–10 engineer-weeks for a single node, plus a permanent on-call surface, and our default should be to compare against Laravel Reverb and a managed vendor before funding it. Recommendation: fund a 1–2 week spike only if we can name a capability that Reverb and managed vendors do not provide; otherwise buy.
To engineering: You get a battle-tested RFC6455 implementation with server and client handshake, frame encode/decode, message assembly, and permessage-deflate, behind PSR-7/17 interfaces and with no I/O assumptions — so you choose the event loop. The Autobahn suite passing and the recent modernization work (PHP 7.4+, PSR-17 factory replacing Guzzle objects, explicit buffer and payload limits) are real quality signals. What you do not get: any Laravel integration, any connection registry, heartbeats, reconnect/resume, backpressure, graceful shutdown, presence, or channel authorization. Those are our code, our review burden, and our bugs. Pin exact versions — upstream is pre-1.0 and will break — and verify the anomalous release date before pinning. Two named owners and a written runbook before the first production feature, or we do not ship it.