Websocket Laravel Package

Technical Evaluation

Architecture fit. morozovsk/websocket is a standalone, long-running PHP CLI daemon that implements the RFC 6455 handshake and frame codec over stream_select() — it is not a Laravel package in any structural sense. There is no service provider, no facade, no config file, no Artisan command, and no publishable migrations. The Yii/Yii2 integration it advertises is a thin bootstrap shim; nothing comparable exists for Laravel. The practical consequence is an architectural split: the WebSocket server is a separate process with its own memory space and lifecycle, entirely outside the Laravel request/response cycle. Any application event (a job completing, a model being updated, a notification firing) must cross a process boundary to reach connected clients, and the package provides no transport for that. You will build and own a Redis pub/sub (or equivalent) bridge, a message envelope contract, and a reconnect/backfill strategy yourself. The package contributes roughly the socket framing layer — the smallest and least differentiated part of a real-time feature — while the TPM-owned surface area is the broker, the auth handshake, the presence model, and the process supervision.

Integration feasibility. Technically feasible and mechanically simple: install it, write a console command that instantiates the server class, and run it under Supervisor. A competent PHP developer can have a "hello world" broadcast working in under a day. The effort estimate is misleading, however, because the demo-grade path is not the production path. What is missing and must be hand-built: token-based authentication on the handshake (the connection must be tied to a Laravel session or Sanctum/Passport token before it is trusted), origin validation, per-connection authorization for channel subscriptions, rate limiting, heartbeat/ping-pong and dead-connection reaping, structured logging, and a graceful-shutdown path so deploys do not sever live connections mid-session. None of this is exotic, but each item is a discrete work package with its own test burden.

Technical risk. The dominant risk is abandonment, not code quality. The last tagged release is February 2017 — PHP 7.0/7.1 era. Running this on PHP 8.2/8.3 means accepting unpatched deprecations and behavior changes in a component that sits directly on the network edge and parses untrusted binary input. A socket server is security-sensitive by nature: handshake parsing, frame length validation, masking, and payload limits are exactly the surfaces where an unmaintained parser is least acceptable. Secondary risks: single-threaded blocking I/O (one slow handler stalls every connected client), unbounded in-memory connection state (memory growth in a process that never restarts by design), no built-in TLS (mandatory reverse proxy), and no horizontal scale-out story (no shared presence registry, no cross-node fan-out). The low opportunity score (2.28) is consistent with this profile — the strategic upside of adopting it is small because the capability it provides is now table stakes.

Key questions. (1) Is the actual requirement "WebSocket transport" or "this package"? The distinction determines whether the next four questions matter at all. (2) Has anyone verified the codebase against the target PHP version under load, or is PHP 8 support an assumption? (3) What is the concurrency target — dozens of connections, or thousands? Past a few hundred, a single blocking PHP process is the wrong shape. (4) Is Laravel Reverb, Soketi, or Centrifugo (all maintained, all with Laravel/Echo clients) genuinely disqualified, and on what grounds — licensing, hosting constraints, or familiarity? (5) Who owns this daemon at 3 a.m.? (6) What is the license, and has legal reviewed a 2017-vintage dependency with no security response process? (7) Is the real-time feature on the critical path or a nice-to-have? If the latter, the risk calculus changes entirely.

Integration Approach

Stack fit. Poor-as-is, adequate-with-scaffolding. Laravel's real-time conventions assume a broadcast driver plus a client library (Laravel Echo + Pusher protocol). This package speaks raw WebSocket and nothing else, so you either write a custom front-end client and a custom server-side broadcaster, or you write a Pusher-protocol adapter — at which point you have reimplemented the thing you were avoiding. If the team is already comfortable with a raw WebSocket object in JavaScript and a small custom message protocol, the impedance is manageable. If the expectation is broadcast(new Event(...)) and Echo.private(...), expect to rebuild that abstraction layer.

Migration path. Treat this as greenfield, not a migration: there is no prior Laravel integration to move from. Recommended path — Phase 0, spike: stand the server up behind nginx (TLS termination + Upgrade proxying), prove auth-on-connect and one round-trip broadcast. Phase 1, bridge: add Redis pub/sub, define a versioned message envelope, and wire a Laravel-side publisher (a queued job or event listener) so HTTP handlers never touch the socket process. Phase 2, hardening: heartbeat, dead-connection reaping, connection registry, metrics endpoint, graceful shutdown on SIGTERM. Phase 3, operationalize: Supervisor unit, deploy runbook, dashboards. If Phase 1 exceeds roughly two engineer-weeks, stop and re-evaluate — that is the signal that the build-vs-buy math has inverted.

Compatibility. Two independent axes. Runtime: PHP 8.x compatibility is unverified from repo metadata and must be empirically tested, not assumed; the code predates several language-level removals. Protocol: RFC 6455 is stable, so browser compatibility is not a concern — the concern is the package's framing edge cases under adversarial input. Also verify it coexists with your process supervisor, your container base image (a php:8.x-cli image with the right extensions, no FPM), and your observability stack (stdout logging, not file logging, for container-native collection).

Sequencing. Do not sequence this behind other work as if it were a library install. Front-load a timeboxed spike with an explicit kill criterion, and hold the decision to proceed until the PHP-version and concurrency questions are answered with evidence. If the spike succeeds, the bridge and the hardening work should ship as one unit — a socket server without heartbeats and graceful shutdown is not partially done, it is a latent incident.

Operational Impact

Maintenance. High relative to the code volume, because the code volume is not the cost driver. You inherit the entire lifecycle of a network daemon: process supervision, log rotation, dependency drift, and an upgrade path that does not exist. Upstream is dormant, so "maintenance" means either forking the package into your own vendor namespace (accepting full ownership) or pinning indefinitely and absorbing the security exposure. Budget a standing fraction of an engineer's capacity, plus an annual "do we still own this?" review that will increasingly answer no.

Support. Effectively internal-only. Community support for a 2017 package is thin; the issue tracker is not a support channel with an SLA. Any production incident debugs down to your team reading the socket loop. This is acceptable for internal tooling and unacceptable for a customer-facing real-time surface with an uptime commitment.

Scaling. The hard ceiling. One process, one event loop, one address space: vertical scaling only, and the blocking I/O model means a single slow consumer or a synchronous database call inside a message handler degrades every connected client. Horizontal scale-out requires sticky routing plus a shared pub/sub fan-out plus a distributed presence store — none of which the package supplies. Estimate the ceiling empirically during the spike and write the number down; it becomes the trigger for re-platforming, and you want that trigger defined before launch rather than during an incident.

Failure modes. Silent process death with no supervisor restart (total outage, no error surfaced to users beyond stalled sockets); memory exhaustion or leak in a never-restarting process (degradation, then OOM kill); connection-table saturation at the file-descriptor limit; reverse proxy idle-timeout eviction of connections the server believes are still live (phantom presence — the classic symptom is users showing "online" forever); deploy-time mass disconnect; and unauthenticated connections if the handshake auth hook is skipped or misconfigured. Each of these needs a detection signal and a documented response before go-live.

Ramp-up. The code itself is small and readable — a mid-level PHP developer can understand the whole server in a day or two, which is genuinely a point in its favor for a team that wants to learn the protocol. The operational ramp-up is the real cost: socket debugging, proxy configuration, and load testing are skills that must exist on the team or be borrowed. The organizational question is whether that learning investment buys anything durable, given that the maintained alternatives (Reverb, Soketi, Centrifugo) are themselves open source and equally instructive.

Recommendation. Do not adopt as a platform foundation. The favorable read is a narrow one: a disposable internal tool, a small connection count, a team that accepts ownership of a fork, and a documented plan to replace it. For anything on the product surface, the low opportunity score is the correct signal — the strategic value of this dependency is that it will eventually be removed.