Server-Sent Events vs WebSockets untuk Realtime

Setiap beberapa bulan sebuah proyek meminta fitur realtime dan seseorang langsung meraih WebSockets. Sering kali itu berlebihan. Sebagian besar fitur realtime bersifat satu arah: dashboard yang diperbarui, progress bar untuk job panjang, notifikasi, live log, atau model AI yang men-streaming token. Untuk semua itu, Server-Sent Events menyelesaikan tugas dengan kode jauh lebih sedikit dan beban operasional jauh lebih ringan.

Saya menjalankan beberapa layanan di VPS self-hosted di belakang reverse proxy, dan pilihan antara dua transport ini punya konsekuensi nyata terhadap berapa banyak logika reconnection yang harus saya tulis, bagaimana proxy berperilaku, dan berapa banyak koneksi yang bahkan diizinkan oleh browser. Berikut cara saya menalarnya dalam praktik, dengan trade-off yang benar-benar penting.

Satu arah vs dua arah: pembeda utama

Server-Sent Events bersifat satu arah secara desain. Klien membuka satu request HTTP berumur panjang dan server men-streaming aliran teks event ke bawahnya, terus-menerus, sampai ada yang menutupnya. Klien tidak bisa mengirim data balik lewat kanal yang sama; untuk berbicara ke server ia membuat request HTTP biasa di samping stream itu. Sebaliknya, WebSockets meng-upgrade koneksi menjadi protokol full-duplex di mana kedua sisi mendorong frame kapan pun mereka mau.

Perbedaan tunggal itu menentukan sebagian besar kasus. Jika interaksinya benar-benar percakapan, dengan klien memancarkan pesan terus-menerus, WebSockets cocok secara alami. Jika klien sebagian besar hanya pendengar yang sesekali membuat request biasa, SSE adalah model yang lebih sederhana dan lebih jujur. Memaksakan pipa dua arah pada masalah satu arah hanya menambah permukaan yang harus diamankan dan dipelihara.

Reconnection: SSE memberikannya secara gratis

Ini adalah fitur SSE yang paling diremehkan orang. API EventSource di browser reconnect otomatis saat koneksi putus, dengan retry default sekitar tiga detik yang bisa diubah server dengan mengirim field retry di dalam stream. Lebih bagus lagi, jika Anda melampirkan id pada setiap event, browser menyimpannya dan mengirim header Last-Event-ID saat reconnect, sehingga server bisa melanjutkan tepat dari titik terakhir alih-alih memutar ulang atau menjatuhkan pesan.

// SSE stream — reconnection and resume are built in
// Client:
const es = new EventSource("/api/updates");
es.onmessage = (e) => console.log("data:", e.data);
es.onerror = () => console.log("reconnecting automatically...");

// Server (Node/Express) response body format:
//   id: 42\n
//   retry: 5000\n
//   data: {"progress":73}\n\n
// On reconnect the browser sends:  Last-Event-ID: 42
res.writeHead(200, {
  "Content-Type": "text/event-stream",
  "Cache-Control": "no-cache",
  "Connection": "keep-alive",
});
res.write(`id: ${seq}\nretry: 5000\ndata: ${JSON.stringify(payload)}\n\n`);

WebSockets tidak punya semua ini. Saat WebSocket tertutup, klien hanya diam; Anda harus menulis sendiri loop reconnect, backoff, dan logika replay pesan, atau memakai library yang melakukannya. Bagi banyak tim biaya tersembunyi itu menjadi faktor penentu: SSE menghadirkan perilaku tangguh yang jika tidak, akan Anda implementasikan ulang, dengan buruk, di bawah tenggat waktu.

Perilaku proxy dan HTTP/2

Karena SSE hanyalah response HTTP panjang, ia biasanya lewat melalui infrastruktur yang ada, load balancer, middleware auth, dan CDN, tanpa perlakuan khusus. WebSockets butuh handshake HTTP Upgrade eksplisit, dan setiap proxy di jalur harus dikonfigurasi untuk mengizinkan dan meneruskannya. Itu lebih banyak bagian bergerak yang harus dibereskan.

# Nginx: SSE endpoint behind a reverse proxy
location /api/updates {
    proxy_pass http://app_upstream;
    proxy_http_version 1.1;
    proxy_set_header Connection "";     # keep upstream alive
    proxy_buffering off;                # critical: flush each event
    proxy_cache off;
    proxy_read_timeout 86400s;          # do not kill idle-ish streams
    add_header X-Accel-Buffering no;    # override buffering explicitly
}

# WebSocket endpoint needs the Upgrade dance instead:
location /ws {
    proxy_pass http://app_upstream;
    proxy_http_version 1.1;
    proxy_set_header Upgrade $http_upgrade;
    proxy_set_header Connection "upgrade";
}

Keluhan lama terhadap SSE adalah batas koneksi HTTP/1.1: browser hanya mengizinkan sekitar enam koneksi bersamaan per origin, dan setiap stream SSE memakan satu, yang bisa membuat sisa halaman kelaparan di beberapa tab. HTTP/2 menghapus batasan itu dengan mem-multiplex banyak stream di atas satu koneksi TCP, dengan default hasil negosiasi sekitar seratus stream bersamaan. Jadi di deployment HTTP/2 modern mana pun, batasan itu praktis hilang, yang menjadi alasan besar SSE menjadi transport default bagi SDK AI yang men-streaming token model.

Perbandingan sekilas

Cara saya memilih per use case

• Dashboard live, metrik, progress bar, notifikasi, activity feed: SSE. Push satu arah, reconnect otomatis, tak ada yang perlu dibuat manual.
• Streaming token AI dan LLM: SSE. Ia menjadi transport default SDK AI besar justru karena alirannya server ke klien dengan multiplexing HTTP/2 yang rapi.
• Chat, editing kolaboratif, game multiplayer, kursor live: WebSockets. Klien memancarkan aliran terus-menerus, jadi full duplex layak dipakai.
• Input klien biner atau frekuensi tinggi, seperti audio atau upload telemetri: WebSockets. SSE hanya membawa teks UTF-8 satu arah.
• Ragu dan sisi klien mayoritas membaca: mulai dengan SSE. Lebih murah menambah endpoint POST biasa nanti daripada mengoperasikan socket dua arah yang tak Anda butuhkan.

Kesalahan yang paling sering saya lihat adalah meraih alat yang lebih powerful secara refleks. WebSockets memang lebih baik saat Anda membutuhkannya, tapi ia membawa biaya berkelanjutan: kode reconnection, konfigurasi proxy, dan protokol yang berada di luar tooling HTTP normal Anda. SSE diam-diam menyelesaikan kasus umum. Cocokkan transport dengan arah data Anda yang sebenarnya, dan sebagian besar fitur realtime jadi lebih sederhana.