Laravel Broadcasting: Memahami Alur Event dari Server ke Client

Bayangkan halaman status pesanan yang harus diperbarui setelah server menerima perubahan. Tanpa broadcasting, client biasanya perlu meminta ulang data secara berkala atau menunggu navigasi berikutnya. Dengan broadcasting, aplikasi Laravel dapat mengirim event tertentu melalui integrasi WebSocket kepada client yang sedang berlangganan channel.

Kuncinya bukan menghafal nama driver. Anda perlu memahami satu alur: event terjadi di server, event tersebut ditandai untuk di-broadcast, channel menjadi ruang tujuan, client berlangganan, lalu listener menangani data yang diterima. Artikel ini membahas alur konseptual tersebut pada Laravel 13.x. Contoh kode bersifat ilustrasi berbasis dokumentasi dan belum dijalankan pada proyek lokal.

Broadcasting bukan polling dan bukan pilihan arsitektur frontend

Broadcasting adalah mekanisme untuk menyebarkan event aplikasi dari server ke client melalui broadcasting driver yang terhubung ke transport WebSocket. Laravel Echo adalah library JavaScript yang membantu client berlangganan channel dan mendengarkan event dari driver tersebut.

Alurnya dapat diringkas seperti ini:

1. Server membuat atau mengirim event aplikasi.
2. Event yang memenuhi kontrak broadcasting diteruskan ke driver.
3. Driver mengirim representasi event ke channel yang ditentukan.
4. Client yang sudah berlangganan channel menerima event.
5. Listener di client memperbarui tampilan atau state sesuai data event.

Broadcasting tidak otomatis berarti “instan”. Kecepatan, urutan, pengiriman ulang, reconnect, kapasitas, dan ketersediaan bergantung pada aplikasi, driver, jaringan, dan konfigurasi yang tidak diuji di sini. Broadcasting juga tidak menentukan apakah aplikasi memakai Blade, Livewire, React, Vue, atau framework client lain. Fokusnya adalah jalur event dan langganan.

Mulai dari event yang memang perlu diterima client

Event biasa menyimpan data kejadian dan dapat dipicu memakai mekanisme event Laravel. Agar event itu dipancarkan ke client, class event perlu mengimplementasikan ShouldBroadcast. Laravel kemudian menggunakan broadcastOn untuk menentukan channel tujuan.

Contoh berikut menggambarkan perubahan status pesanan. Ia sengaja memakai public channel agar alurnya mudah dipahami tanpa masuk ke desain otorisasi channel atau private channel.

<?php

namespace App\Events;

use Illuminate\Broadcasting\Channel;
use Illuminate\Contracts\Broadcasting\ShouldBroadcast;
use Illuminate\Foundation\Events\Dispatchable;
use Illuminate\InteractsWithSockets;
use Illuminate\Queue\SerializesModels;

class OrderStatusUpdated implements ShouldBroadcast
{
    use Dispatchable, InteractsWithSockets, SerializesModels;

    public function __construct(
        public int $orderId,
        public string $status,
    ) {}

    public function broadcastOn(): array
    {
        return [new Channel('orders')];
    }
}

Ada tiga bagian penting di sini:

• ShouldBroadcast memberi tahu Laravel bahwa event ini ditujukan untuk broadcasting.
• broadcastOn mengembalikan channel tujuan. Channel('orders') adalah public channel pada contoh ini.
• Properti orderId dan status menjadi data yang dapat dipakai listener client, sesuai aturan serialisasi dan data broadcast yang berlaku pada versi aplikasi.

Event tersebut dapat dikirim dari alur aplikasi, misalnya setelah status diproses:

OrderStatusUpdated::dispatch(
    orderId: $order->id,
    status: 'shipped',
);

Contoh ini menunjukkan cara memicu event, bukan bukti bahwa status pesanan pada aplikasi Anda sudah benar atau bahwa event telah terkirim. Nama class, data, dan waktu pemicu harus mengikuti domain aplikasi yang sebenarnya.

Channel adalah alamat langganan, bukan sekadar nama string

Channel membantu memisahkan event berdasarkan ruang tujuan. Pada contoh ini, server menyiarkan event ke channel orders, dan client harus berlangganan nama yang sama. Jika satu sisi memakai orders sementara sisi lain memakai order, keduanya tidak merujuk ke channel yang sama.

Untuk artikel ini, public channel dipakai hanya sebagai model konseptual. Aplikasi nyata mungkin membutuhkan batas akses yang berbeda. Menentukan siapa yang boleh berlangganan, bagaimana callback otorisasi bekerja, atau bagaimana peran dan izin dimodelkan adalah pekerjaan tersendiri. Hal-hal tersebut bukan bagian dari contoh minimal ini, sehingga jangan menganggap public channel cocok untuk data yang tidak boleh dilihat semua client.

Perbedaan pentingnya adalah sebagai berikut:

• Channel menentukan ruang langganan tempat event diterima.
• Event membawa nama kejadian dan data yang akan ditangani client.
• Listener menentukan tindakan client setelah event diterima.
• Otorisasi akses adalah keputusan keamanan aplikasi, bukan konsekuensi otomatis dari nama channel.

Pemisahan ini mencegah kesalahan umum: mengira bahwa mengganti nama channel sudah cukup untuk menyelesaikan seluruh desain akses.

Client menerima event melalui Laravel Echo

Setelah broadcasting driver dan client disiapkan sesuai dokumentasi, Laravel Echo dapat digunakan untuk berlangganan channel dan mendengarkan event. Bentuk minimalnya seperti ini:

Echo.channel('orders')
    .listen('OrderStatusUpdated', (event) => {
        console.log('Status pesanan berubah:', event.status);

        // Perbarui state atau tampilan aplikasi di sini.
    });

Urutan bacanya sama dengan alur server:

1. Echo.channel('orders') membuat langganan client ke public channel orders.
2. listen('OrderStatusUpdated', ...) memasang handler untuk nama event tersebut.
3. Saat event diterima, callback memperoleh data event dan dapat memperbarui tampilan.

Nama event perlu diperiksa terhadap aturan penamaan yang dipakai aplikasi. Laravel mendokumentasikan namespace event default dan opsi broadcastAs untuk nama khusus. Jika event memakai broadcastAs, listener Echo perlu mengikuti nama broadcast yang dikustomisasi, termasuk aturan titik awal yang dijelaskan dalam dokumentasi. Jangan menebak nama event dari nama file saja.

Contoh listener di atas juga belum memilih library state, framework UI, atau strategi rendering. Itu disengaja: broadcasting menyampaikan event, sedangkan aplikasi client memutuskan bagaimana event tersebut mengubah state dan tampilan.

Driver dan Echo memiliki peran yang berbeda

Laravel membutuhkan server-side broadcasting driver untuk memancarkan event. Echo berada di sisi client dan membantu subscription serta listener. Dokumentasi Laravel saat ini menyebut integrasi seperti Reverb, Pusher Channels, dan Ably sebagai opsi driver/integrasi yang didukung pada konteks masing-masing.

Nama-nama tersebut tidak menjadi perbandingan dalam artikel ini. Pilihan driver perlu mengikuti dokumentasi versi yang digunakan, kebutuhan aplikasi, dan pemeriksaan operasional yang berada di luar cakupan draf ini. Mengetahui peran masing-masing komponen sudah cukup untuk menelusuri alur dasar:

• Laravel event: sumber kejadian di server.
• Broadcasting driver: jalur server-side yang meneruskan broadcast.
• Transport WebSocket: koneksi yang dipakai integrasi untuk menyampaikan pesan ke client.
• Laravel Echo: antarmuka client untuk subscribe dan listen.
• Listener aplikasi: kode yang menentukan respons terhadap event.

Jika salah satu lapisan belum tersedia atau belum terhubung, listener client tidak akan menjadi bukti bahwa event sudah terkirim.

Dua catatan yang sering memengaruhi waktu broadcast

Broadcasting berdekatan dengan beberapa mekanisme Laravel lain, tetapi keduanya tidak perlu diubah menjadi topik utama.

Pertama, dokumentasi broadcasting menjelaskan bahwa broadcast dapat diproses melalui queue sesuai konfigurasi dan kontrak event. Artinya, waktu ketika event dibuat dan waktu ketika client menerimanya tidak boleh dijadikan jaminan dari contoh konseptual ini. Menentukan worker, retry, kapasitas, atau tuning queue adalah topik operasional terpisah.

Kedua, jika event berhubungan dengan transaksi database, data yang dibaca oleh proses broadcast perlu dipikirkan terhadap waktu commit. Laravel mendokumentasikan opsi event tertentu untuk dikirim setelah transaksi commit. Catatan ini bukan tutorial transaksi. Intinya hanya: pastikan event tidak dibaca pada waktu yang mendahului keadaan database yang ingin Anda umumkan.

Kedua caveat tersebut mengubah cara kita membaca alur: dispatch bukan jaminan bahwa browser langsung melihat keadaan akhir. Aplikasi perlu menentukan kapan event layak diumumkan dan data apa yang aman dikirim.

Cara menelusuri alur ketika client tidak menerima event

Gunakan pertanyaan berurutan, bukan langsung menyimpulkan bahwa WebSocket atau driver bermasalah:

1. Apakah event benar-benar dipicu pada cabang kode yang diharapkan?
2. Apakah class event mengimplementasikan ShouldBroadcast?
3. Apakah broadcastOn mengembalikan channel yang sama persis dengan yang dipakai client?
4. Apakah nama event pada listen cocok dengan nama broadcast yang sebenarnya?
5. Apakah driver dan Echo sudah dikonfigurasi mengikuti dokumentasi versi proyek?
6. Apakah client berhasil membuat subscription dan tetap memiliki koneksi yang diperlukan?
7. Apakah callback listener menangani bentuk data yang benar?

Daftar ini membantu mengisolasi batas tanggung jawab. Ia bukan panduan deployment, uji jaringan, atau jaminan diagnosis untuk semua kegagalan. Untuk pemeriksaan nyata, lihat log aplikasi, status koneksi client, dan dokumentasi driver yang dipakai.

Kapan broadcasting menjadi pilihan yang masuk akal?

Gunakan broadcasting ketika client perlu diberi tahu tentang event server tanpa menjadikan refresh halaman atau polling sebagai satu-satunya jalur pembaruan. Contohnya adalah perubahan status yang memang perlu tercermin pada client yang sedang membuka halaman.

Mulailah dari satu event yang jelas, satu channel dengan batas akses yang dipahami, satu payload kecil yang memang diperlukan, dan satu listener yang dapat diamati. Setelah alurnya terbukti pada proyek Anda, barulah periksa kebutuhan channel yang lebih ketat, queue, transaksi, reconnect, observability, dan deployment melalui dokumentasi serta pengujian khusus. Artikel ini tidak menjalankan server, client, driver, atau koneksi WebSocket, jadi tidak ada hasil pengiriman, latency, ordering, scaling, atau kesiapan produksi yang dapat disimpulkan dari contoh di atas.