sserealtimeeventsourceMahir4 mnt baca

Server-Sent Events: Radio Satu Arah dari Server

Memahami SSE sebagai alternatif ringan WebSocket untuk data satu arah: format event stream dan EventSource.

Radio broadcast vs telepon

WebSocket seperti telepon: dua arah, butuh sambungan khusus. SSE (Server-Sent Events) seperti radio broadcast: satu arah dari server ke klien, memakai koneksi HTTP biasa yang dibiarkan terbuka. Untuk notifikasi, feed live, atau progress bar, SSE jauh lebih sederhana.

Kenapa SSE sering dilupakan (padahal berguna)

Banyak developer langsung lompat ke WebSocket untuk semua kebutuhan real-time, padahal 80% kasus hanya butuh server mendorong data satu arah. SSE menang di kesederhanaan: tidak perlu protokol baru, otomatis reconnect oleh browser, dan bekerja lewat proxy HTTP standar tanpa konfigurasi khusus.

Contoh 1: format event stream

Server mengirim response dengan Content-Type khusus dan membiarkan koneksi terbuka:

http
HTTP/1.1 200 OK
Content-Type: text/event-stream
Cache-Control: no-cache
Connection: keep-alive

data: {"notif": "Pesanan #123 lunas"}

data: {"notif": "Kurir dalam perjalanan"}

Formatnya sederhana: setiap pesan diawali data:, diakhiri baris kosong ganda. Browser mem-buffer sampai baris kosong, lalu memicu event.

Contoh 2: menerima di browser

javascript
const sumber = new EventSource("/api/notifikasi");

sumber.onmessage = function(event) {
  const data = JSON.parse(event.data);
  tampilkanNotifikasi(data.notif);
};

sumber.onerror = function() {
  console.log("Terputus, browser akan reconnect otomatis...");
};

Tidak perlu library. EventSource menangani reconnect otomatis dengan backoff. Bisa juga memakai event bernama (event: harga) untuk memisahkan jenis pesan.

Kesalahan umum

Salah: memakai SSE untuk komunikasi dua arah. SSE hanya server ke klien. Yang benar: butuh dua arah? Pakai WebSocket.

Salah: lupa header yang benar. Tanpa Content-Type: text/event-stream dan Cache-Control: no-cache, browser tidak memproses stream. Yang benar: set kedua header di server.

Salah: tidak menangani batas koneksi browser. Browser membatasi ~6 koneksi SSE per domain. Yang benar: satu koneksi SSE untuk semua event, bedakan lewat tipe event.

Salah: mengirim terlalu sering tanpa perlu. Setiap pesan membangunkan radio browser. Yang benar: batch update kecil, atau pertimbangkan WebSocket untuk frekuensi sangat tinggi.

Event bernama untuk banyak tipe pesan

Satu koneksi SSE bisa membawa banyak jenis event:

http
event: harga
data: {"saham": "BBCA", "harga": 9750}

event: berita
data: {"judul": "Pasar menguat"}
javascript
sumber.addEventListener("harga", function(e) {
  updateHarga(JSON.parse(e.data));
});
sumber.addEventListener("berita", function(e) {
  tampilkanBerita(JSON.parse(e.data));
});

Satu koneksi, handler terpisah per tipe. Jauh lebih rapi daripada mencampur semua pesan dalam satu onmessage dengan if-else berlapis.

Catatan teknis: SSE tidak mendukung header kustom (tidak bisa pasang Authorization) karena memakai GET biasa. Solusinya: token lewat query param (kurang ideal) atau cookie. Ini salah satu alasan WebSocket dipilih untuk kasus yang butuh auth header.

Tantangan

Bangun notifikasi live dengan SSE

Buat halaman notifikasi live:

  1. Tulis kode server (Node/Express atau pseudo) yang mengirim event tiap 3 detik dengan Content-Type text/event-stream.
  2. Tulis kode browser dengan EventSource yang menampilkan tiap pesan.
  3. Jelaskan kenapa SSE cukup (tidak perlu WebSocket) untuk kasus ini.

Tulis sebagai 2 blok kode + 2 baris penjelasan.