Laravel Broadcasting Realtime Events Echo Pusher Driver Concepts

Definisi

Broadcasting di Laravel adalah cara mengirim event aplikasi ke client melalui channel realtime, biasanya lewat WebSocket provider seperti Pusher atau driver lain yang kompatibel.

Kalau request biasa sifatnya client → server → response, broadcasting menambah jalur server → banyak client tanpa menunggu client melakukan polling terus-menerus.

Kapan realtime dipakai

Realtime dipakai kalau UI perlu bereaksi cepat terhadap perubahan yang datang dari luar konteks halaman aktif.

Contoh yang cocok:

• status order berubah dari pending ke paid
• notifikasi baru masuk
• chat message baru
• progress job panjang
• dashboard metrik yang harus ikut bergerak
• kolaborasi multi-user, misalnya typing indicator atau presence

Realtime bukan default untuk semua fitur.

Jangan pakai realtime kalau:

• data jarang berubah
• user tidak butuh update instan
• refresh manual atau polling periodik sudah cukup
• biaya infrastruktur WebSocket terlalu mahal untuk kebutuhan fitur

Aturan kasarnya: kalau keterlambatan beberapa detik masih aman, realtime sering kali bukan kebutuhan wajib.

Cara kerja broadcasting

Alur dasarnya begini:

1. Aplikasi mendeteksi perubahan penting.
2. Laravel membuat event yang mengimplementasikan ShouldBroadcast atau ShouldBroadcastNow.
3. Event dikirim ke broadcaster yang dikonfigurasi di config/broadcasting.php.
4. Driver broadcast menyalurkan event ke layanan realtime, misalnya Pusher, Ably, atau server WebSocket lain yang kompatibel.
5. Client yang subscribe ke channel menerima payload event.
6. Laravel Echo atau WebSocket client di browser menjalankan callback lalu memperbarui state UI.

Mermaid: alur event → broadcast → client update

Komponen inti

1) Event

Event adalah sinyal bahwa sesuatu penting sudah terjadi.

Di konteks realtime, event biasanya membawa data minimal yang dibutuhkan UI untuk update. Jangan asal kirim seluruh model kalau client hanya butuh satu status.

2) Broadcast channel

Channel adalah jalur distribusi event.

Jenis yang umum:

• Public channel: bisa didengar siapa pun yang tahu namanya
• Private channel: perlu authorization sebelum subscribe
• Presence channel: seperti private channel, tapi bisa tahu siapa saja yang sedang online di channel itu

Channel naming harus konsisten dan mudah dipetakan ke domain.

Contoh:

• orders.{orderId}
• chat.{roomId}
• presence.project.{projectId}

3) Broadcaster / driver

Driver adalah implementasi transport yang dipakai Laravel untuk mengirim event ke layanan realtime.

Di Laravel, driver ini dikonfigurasi melalui broadcast connection. Konsepnya sama seperti cache atau queue driver: aplikasi Laravel tidak peduli detail transport selama kontraknya sama.

Contoh driver/transport yang sering ditemui:

• Pusher
• Ably
• Redis-based broadcaster
• custom WebSocket server yang kompatibel

4) Laravel Echo

Laravel Echo adalah helper client-side untuk subscribe channel dan mendengar event dengan API yang lebih nyaman dibanding manipulasi WebSocket mentah.

Echo memudahkan hal seperti:

• subscribe ke private atau presence channel
• listen event dengan nama yang konsisten
• menangani auth channel handshake
• menyusun listener realtime yang mudah dibaca di frontend

Echo tidak menggantikan state management. Echo hanya sumber event; UI tetap perlu memutuskan bagaimana state diperbarui.

Contoh alur implementasi

Event backend

php

use Illuminate\Broadcasting\PrivateChannel;
use Illuminate\Contracts\Broadcasting\ShouldBroadcast;
use Illuminate\Broadcasting\InteractsWithSockets;
use Illuminate\Foundation\Events\Dispatchable;
use Illuminate\Queue\SerializesModels;
 
class OrderPaid implements ShouldBroadcast
{
    use Dispatchable, InteractsWithSockets, SerializesModels;
 
    public function __construct(public int $orderId, public string $status)
    {
    }
 
    public function broadcastOn(): array
    {
        return [new PrivateChannel("orders.{$this->orderId}")];
    }
 
    public function broadcastAs(): string
    {
        return 'order.paid';
    }
 
    public function broadcastWith(): array
    {
        return [
            'order_id' => $this->orderId,
            'status' => $this->status,
        ];
    }
}

Listener frontend dengan Echo

js

Echo.private(`orders.${orderId}`)
  .listen('.order.paid', (event) => {
    updateOrderStatus(event.order_id, event.status)
  })

Catatan penting

• Nama event yang dipakai client harus cocok dengan format broadcast yang sebenarnya.
• Jika memakai broadcastAs(), sering kali nama event di client perlu prefiks titik (.order.paid) agar tidak otomatis diubah.
• Channel private butuh endpoint auth yang benar di backend.

Kenapa konsep driver penting

Driver menentukan bagaimana event keluar dari aplikasi.

Secara praktis, ini memengaruhi:

• latensi update
• kemampuan scale
• biaya operasional
• kebutuhan infrastruktur tambahan
• cara debugging saat realtime gagal

Kalau app kecil, driver managed seperti Pusher sering lebih simpel. Kalau volume tinggi atau arsitektur sudah kompleks, tim biasanya mulai mempertimbangkan trade-off biaya, kontrol, dan observability.

Jebakan umum saat bikin realtime UI

1) Mengandalkan realtime untuk sumber kebenaran

Realtime bukan database.

Kalau browser keburu disconnect, event bisa terlewat. Karena itu UI tetap harus bisa:

• fetch ulang state saat halaman dibuka
• sinkron ulang setelah reconnect
• menangani missed updates

Praktik aman: gunakan realtime untuk notifikasi perubahan, lalu ambil ulang state penting dari API saat perlu.

2) Mengirim payload terlalu besar

Mengirim seluruh objek sering kelihatan praktis, tapi mahal.

Masalahnya:

• bandwidth membengkak
• payload sulit di-debug
• data sensitif lebih mudah ikut bocor
• client jadi bergantung pada shape data yang terlalu besar

Lebih baik kirim data minimum yang cukup untuk update UI.

3) Lupa authorization channel

Private dan presence channel harus dilindungi.

Kalau authorization salah, subscribe gagal diam-diam atau event tidak pernah masuk. Di production, ini sering terlihat seperti “realtime-nya mati”, padahal masalahnya ada di auth handshake.

4) UI update duplikat

Event bisa datang lebih dari sekali, atau state bisa di-refresh dari sumber lain pada saat yang sama.

Kalau logic frontend tidak idempotent, UI bisa double insert, angka jadi dobel, atau list urutannya rusak.

5) Tidak ada fallback saat socket mati

Koneksi WebSocket bisa putus karena jaringan, proxy, timeout, atau tab tidur.

UI yang sehat biasanya punya fallback:

• reconnect otomatis
• polling cadangan untuk kasus penting
• manual refresh bila perlu

6) Mencampur event domain dan event UI

Broadcasting paling enak kalau event merepresentasikan kejadian domain, bukan sekadar aksi visual.

Contoh yang bagus:

• OrderPaid
• MessageSent
• InventoryAdjusted

Contoh yang kurang sehat:

• FlashToastNow
• ToggleModal

Kalau event terlalu UI-centric, backend jadi susah dirawat dan logic bisnis ikut bocor ke layer presentasi.

7) Tidak memikirkan queue

Beberapa broadcast berjalan lewat queue. Kalau queue worker mati, event tidak terkirim.

Di production, itu artinya realtime tampak rusak padahal problemnya ada di worker, retry, atau failed jobs.

Catatan implementasi production

• Pastikan BROADCAST_CONNECTION atau konfigurasi broadcasting konsisten dengan environment.
• Jalankan queue worker kalau event broadcast diproses async.
• Monitor error auth channel dan koneksi WebSocket.
• Pakai nama channel yang stabil dan domain-driven.
• Pisahkan kebutuhan notifikasi, presence, dan live update supaya tidak semua data dipaksa lewat satu jalur.
• Jika UI bergantung pada urutan event, siapkan strategi untuk race condition dan refresh state.

Perbedaan singkat yang sering tertukar

Broadcasting vs event internal

• Event internal: dipakai untuk memisahkan logic server-side
• Broadcasting: event yang juga dikirim ke client realtime

Laravel Echo vs broadcaster

• Echo: client library untuk subscribe dan listen
• Broadcaster/driver: transport yang dipakai Laravel untuk mengirim event

Public vs private vs presence

• Public: mudah subscribe, cocok untuk data non-sensitif
• Private: butuh auth, cocok untuk data per user/per resource
• Presence: untuk mengetahui siapa saja yang sedang hadir di channel

Kapan arsitektur ini layak dipakai

Pakai broadcasting kalau:

• perubahan harus terlihat cepat oleh banyak client
• ada sumber update yang tidak selalu berasal dari tab yang sama
• UI harus terasa live, bukan sekadar refresh halaman
• manfaat bisnis dari update instan lebih besar daripada biaya dan kompleksitasnya

Kalau kebutuhan utamanya cuma “UI jangan terasa lambat”, sering kali caching, polling ringan, atau refresh manual sudah cukup.

Ringkasan

Broadcasting di Laravel adalah jalur server-to-client untuk update realtime. Event mendefinisikan kejadian, channel menentukan siapa yang menerima, driver menentukan bagaimana event dikirim, dan Laravel Echo membantu client mendengarkan update itu dengan rapi.

Kalau dipakai dengan benar, realtime membuat UX lebih responsif. Kalau dipakai asal-asalan, hasilnya justru rawan race condition, payload besar, dan state UI yang susah dijaga.

Referensi terkait

• Laravel Events & Listeners
• Queue workers dan failed jobs
• Authorization dengan private/presence channel
• State management frontend untuk sinkronisasi realtime