Laravel Wave Laravel Package

Technical Evaluation

Architecture fit. qruto/laravel-wave slots into Laravel's existing broadcasting abstraction as a transport driver, replacing the WebSocket/Pusher path with Server-Sent Events. For a Laravel codebase already emitting ShouldBroadcast events, this is architecturally appealing: domain events stay unchanged, only the delivery mechanism and client listener swap. It is a strong fit for one-directional, server-to-client notification workloads — order status changes, dashboard counters, activity feeds, progress indicators — and a poor fit for anything needing low-latency client-to-server messaging (chat presence, collaborative editing, typing indicators), where SSE's half-duplex nature forces a parallel HTTP path.

Integration feasibility. Low on the application side: Composer install, publish config, change BROADCAST_DRIVER to wave, add the JS client and subscribe. Event classes and channel authorization reuse Laravel's Broadcast::channel() conventions, so existing authorization logic transfers. The real integration cost sits in infrastructure, not code: the SSE endpoint must be exempt from proxy buffering and response buffering (nginx proxy_buffering off, X-Accel-Buffering: no, no CDN/edge caching, aggressive idle timeouts disabled), and it must be reachable at a stable path through the load balancer.

Technical risk.

• Worker occupancy is the dominant risk. Each open SSE connection holds a PHP process for the connection's lifetime. Under PHP-FPM, a few hundred concurrent viewers can exhaust the pool and starve normal HTTP traffic unless the app runs on Octane/Swoole/FrankenPHP or the SSE route is isolated onto a dedicated pool or host.
• Browser connection caps. HTTP/1.1 limits ~6 connections per origin, and SSE connections compete with normal XHR/fetch for that budget. HTTP/2 largely resolves this but must be verified end-to-end.
• No durability. SSE has no message store, replay, or acknowledgement. A client that is reconnecting, backgrounded, or briefly offline silently misses events. Anything requiring at-least-once delivery needs a reconciliation fetch on reconnect.
• Multi-node fan-out. Broadcast must reach whichever node holds a given connection; a single-node or sticky-session assumption is a scaling cliff.
• Maintainer concentration. A small-maintainer MIT package at ~879 stars with a March 2025 release is viable but not vendor-backed; bus-factor and security-response time are unverified.
• Maturity signal. The low opportunity score (2.28) suggests limited ecosystem pull versus Reverb/Pusher — fine for internal use, weak as a strategic dependency.

Key questions.

1. Do we run Octane/Swoole/FrankenPHP, or classic PHP-FPM? What is the per-node concurrent-connection budget?
2. Is the workload strictly server-push, or is there any bidirectional requirement on the roadmap?
3. What is our tolerated event-loss window, and can the UI reconcile via a REST fetch on reconnect?
4. Does our edge (CDN, WAF, ALB, nginx) permit long-lived streaming responses, and what are the idle timeouts?
5. How many nodes, and is sticky routing or a shared pub/sub fan-out layer available?
6. What is our exit cost — is the broadcast driver abstracted enough to swap to Reverb later?

Integration Approach

Stack fit. Requires a modern Laravel (10/11) and PHP 8.1+; assumes Composer and a JS bundler for the client. Cleanest fit is a Laravel monolith on a single region with HTTP/2 termination and an Octane-based runtime. If the platform is shared PHP-FPM behind a buffering CDN, expect meaningful platform work before the first event ships.

Migration path. Adopt incrementally and in parallel, not as a cutover. Keep the existing driver (Pusher/Reverb/Echo) configured for any bidirectional or latency-critical channels, and route only new, read-only streams through Wave. Because channel authorization is shared, a feature can migrate per-channel with a config flag, giving a cheap rollback: flip BROADCAST_DRIVER back and the same events resume over WebSockets.

Compatibility. Verify three surfaces before committing: (a) the Laravel version constraint against our pinned framework, (b) whether Octane worker reuse interacts badly with long-lived responses in our deployment, and (c) the JS client's framework binding — Vue/React/Livewire support varies, and Livewire-heavy apps may need wire:poll fallbacks where the client doesn't integrate.

Sequencing.

1. Spike: one low-traffic, read-only feature (e.g., an admin activity ticker) behind a feature flag.
2. Instrument connection counts, worker utilization, and reconnect rates for two weeks.
3. Harden infrastructure: dedicated SSE route, proxy config, timeouts, reconnect/backoff, and a REST reconciliation call on reconnect.
4. Only then expand to customer-facing surfaces; keep one WebSocket driver available as fallback until the reliability story is proven.
5. Defer any decision about full replacement of the WebSocket stack until concurrency data exists.

Operational Impact

Maintenance. Low ongoing code maintenance — the package is a thin driver — but we inherit the burden of a small-vendor dependency. Pin the version, subscribe to release notifications, and budget a periodic review of the repo's health (issue response, PHP/Laravel version support). Contingency: the surface area is small enough that a fork or in-house driver is a realistic fallback, which materially reduces the vendor risk.

Support. Community-only; no commercial SLA. Internal ownership must be explicit — name a backend owner for the SSE route and an ops owner for the proxy/runtime config. Documentation burden is modest but real: reconnect semantics and "events may be missed" must be written into the frontend contract, or teams will assume WebSocket-grade delivery.

Scaling. Scales linearly with nodes only if connections are evenly distributed and the broadcast reaches the right node. Connection density, not request throughput, becomes the capacity metric — a fundamentally different autoscaling signal than CPU/RPS. Expect to scale on open-connection count and PHP worker saturation, and to isolate SSE onto its own worker pool so a traffic spike in streaming cannot take down checkout or login.

Failure modes to instrument.

• PHP-FPM pool exhaustion → cascading 502s on unrelated routes (highest severity).
• Silent event loss during reconnect or tab backgrounding → stale UI, user trust erosion; mitigate with reconciliation-on-reconnect.
• Proxy/CDN buffering the stream → connections that open but never deliver; test behind the real edge.
• Idle timeout kills → thundering-herd reconnects; require jittered backoff.
• Memory growth under Octane if listeners or buffers aren't released per request.
• Auth expiry on long-lived connections — private channel authorization is evaluated at connect time, so session/role changes mid-stream may not take effect.

Ramp-up. Application developers ramp in under a day — the API mirrors Laravel broadcasting they already know. The real ramp is on the ops side: capacity planning for persistent connections, proxy tuning, and observability for connection counts and reconnect rates. Budget roughly a sprint of platform engineering before production exposure, and treat the frontend reconnect/reconciliation contract as a first-class deliverable rather than an afterthought.