Weave Code
Laravel Wave Laravel Package
qruto/laravel-wave
Laravel Wave adds real-time features to Laravel apps without WebSockets. It broadcasts your events to the frontend over Server-Sent Events, with a simple JavaScript client and seamless integration with Laravel's existing event system—no external services required.
Painless Laravel Broadcasting with SSE
Frequently asked questions about Laravel Wave
- How do I install and configure qruto/laravel-wave in a Laravel app?
- Install it with Composer using composer require qruto/laravel-wave, then publish its config file with the vendor:publish command. Set BROADCAST_DRIVER=wave in your .env so Laravel's broadcaster uses the SSE transport instead of Pusher or Reverb. Finally, add the package's JavaScript client to your frontend bundle and subscribe to the private or public channels you already broadcast on.
- Does Laravel Wave require WebSockets, Pusher, or any external service?
- No. Laravel Wave delivers broadcasts over Server-Sent Events, a plain HTTP streaming response, so there is no WebSocket server, no Pusher account, and no third-party service to pay for or operate. The only requirement is that your web server or edge allows long-lived streaming HTTP responses. That makes it attractive for self-hosted Laravel apps that want real-time updates without adding infrastructure.
- Which Laravel and PHP versions does Laravel Wave support?
- Laravel Wave targets modern Laravel applications, with Laravel 10 and 11 on PHP 8.1 or newer as the expected baseline. Check the composer.json constraints on the repository before upgrading, since supported Laravel majors are tied to specific package releases. If you are still on Laravel 8 or 9, you should plan an upgrade path first.
- How does Laravel Wave integrate with existing ShouldBroadcast events and channel authorization?
- Your event classes stay exactly as they are: anything implementing ShouldBroadcast is delivered through the Wave driver with no code changes. Channel authorization reuses Laravel's Broadcast::channel() callbacks, so your existing auth logic and guards transfer unchanged. In practice you swap the driver and the client listener, and the rest of the broadcasting abstraction behaves the same.
- Do I need Laravel Octane, Swoole, or FrankenPHP to run Laravel Wave, or does it work with PHP-FPM?
- It runs on classic PHP-FPM, but each open SSE connection occupies a PHP worker for the entire lifetime of that connection. Under PHP-FPM a few hundred concurrent viewers can exhaust the pool and starve normal HTTP traffic, so an Octane, Swoole, or FrankenPHP runtime is strongly recommended. If you must stay on PHP-FPM, isolate the SSE route onto a dedicated pool or host so ordinary requests keep their workers.
- Why do my Laravel Wave SSE events arrive late or all at once behind nginx or a CDN?
- Something between the browser and PHP is buffering the stream. On nginx you need proxy_buffering off for the SSE location, and you should send the X-Accel-Buffering: no header from the response to override buffering downstream. Also make sure no CDN or edge cache sits in front of the endpoint and that proxy idle timeouts are long enough for the connection to stay open.
- How many concurrent SSE connections can Laravel Wave handle, and does the browser connection limit matter?
- The ceiling is set by how many workers or coroutines you can keep occupied, so your realistic per-node budget is a runtime and infrastructure question, not a package constant. On HTTP/1.1 browsers cap around six connections per origin, and SSE streams compete with your normal fetch and XHR calls for that budget. Serving the app over HTTP/2 largely removes that constraint, but verify it end to end through your load balancer.
- Can Laravel Wave scale across multiple servers, or does it need sticky sessions?
- A broadcast has to reach whichever node is holding the subscriber's open connection, so a single node or sticky routing is the simple case. Once you run several nodes you need a shared pub/sub fan-out layer so every node receives the event and can push it to its own connected clients. Do not assume a multi-node deployment will work without planning that fan-out, because it is the most common scaling cliff with SSE broadcasting.
- What happens to events a client misses while disconnected, and does Laravel Wave replay them?
- Server-Sent Events have no message store, replay, or acknowledgement, so a client that is reconnecting, backgrounded, or briefly offline silently misses whatever was broadcast in that window. If you need at-least-once delivery, treat the stream as a hint and have the UI reconcile with a normal REST fetch when the connection is re-established. Wave is best for notifications, counters, activity feeds, and progress indicators where a refresh is an acceptable recovery path.
- How do I migrate from Pusher or Laravel Reverb to Laravel Wave, and can I roll back?
- Adopt it incrementally rather than as a cutover: keep your existing driver configured and route only new, read-only, server-push channels through Wave. Because channel authorization is shared and the driver is set in config, a feature can move per channel and you can flip BROADCAST_DRIVER back to resume delivery over WebSockets almost immediately. Keep in mind that Wave is one-directional only, so anything needing client-to-server messaging such as chat presence or typing indicators should stay on Reverb or Pusher.
Weaver
How can I help you explore Laravel packages today?