The Problem with Polling
Imagine building a chat application or a live notification system. The traditional HTTP request/response cycle is one-directional: the client (your Flutter app) has to ask the server for new data. To simulate a live chat, developers used to write timers that pinged the server every 3 seconds: "Any new messages? No. Any new messages? No."
This technique, known as HTTP polling, is disastrous for mobile applications. It drains the user's battery, eats up their data plan, and spams your server with thousands of useless requests. To build truly live features, we need a persistent, two-way connection. We need WebSockets.
The WebSocket Architecture
Unlike HTTP, a WebSocket connection stays open. Once the Flutter app handshakes with the server, the pipe remains active. If an event happens on the server (e.g., another user sends a message), the server instantly pushes that data down the pipe to the client. No asking required.
Historically, setting this up was a massive headache. However, with the introduction of Laravel Reverb (or by using Laravel WebSockets/Pusher), broadcasting events from your backend has never been easier.
Broadcasting from Laravel
In Laravel, you define an Event class that implements the ShouldBroadcast interface. Whenever this event is triggered in your application, Laravel automatically pushes it out over your WebSocket server.
namespace App\Events;
use App\Models\Message;
use Illuminate\Broadcasting\Channel;
use Illuminate\Broadcasting\InteractsWithSockets;
use Illuminate\Contracts\Broadcasting\ShouldBroadcast;
use Illuminate\Foundation\Events\Dispatchable;
use Illuminate\Queue\SerializesModels;
class MessageSent implements ShouldBroadcast
{
use Dispatchable, InteractsWithSockets, SerializesModels;
public $message;
public function __construct(Message $message)
{
$this->message = $message;
}
// Broadcast to a specific chat room channel
public function broadcastOn()
{
return new Channel('chat-room.' . $this->message->room_id);
}
}
Listening in Flutter
On the mobile side, Flutter needs to maintain this persistent connection. Using a package like laravel_echo combined with pusher_client (which is compatible with Laravel's open-source WebSocket servers), you can easily listen to these channels.
You initialize the Echo client when your app starts, and then listen to the specific channel your user is currently viewing:
import 'package:laravel_echo/laravel_echo.dart';
void listenToChat(int roomId) {
// Assume 'echo' is your initialized Laravel Echo instance
echo.channel('chat-room.$roomId')
.listen('MessageSent', (e) {
// This callback fires instantly when the Laravel backend broadcasts!
final newMessage = Message.fromJson(e['message']);
// Update your UI state (e.g., add message to Riverpod/BLoC list)
addMessageToUI(newMessage);
});
}
Conclusion
WebSockets represent a fundamental shift in how mobile apps communicate with APIs. By moving away from RESTful polling and adopting event-driven broadcasting with Laravel and Flutter, you can build hyper-responsive applications. Whether it is live trading charts, real-time GPS tracking, or instant messaging, WebSockets are the engine powering the modern smart tech ecosystem.