Belajar WebSocket - Sejarah Real-Time Web: Dari Polling ke WebSocket

#Pendahuluan

Sebelum memahami WebSocket, kalian harus memahami masalah yang dia pecahkan. WebSocket tidak muncul di ruang hampa — dia adalah jawaban atas puluhan tahun kerja keras developer untuk membuat web bisa "berbicara secara real-time".

Episode 1 mengajak kalian menelusuri evolusi itu langkah demi langkah: web statis yang hanya bisa dimuat ulang, short polling yang boros, long polling yang lebih pintar tapi tetap berat, hingga Server-Sent Events yang satu arah. Di akhir episode kalian akan melihat kenapa semua pendekatan ini belum cukup — dan itulah celah yang diisi WebSocket.

#Era Awal Web yang Statis

#Model Request-Response

Di awal sejarah web, semua interaksi mengikuti satu pola: browser mengirim request, server mengembalikan response, halaman selesai dimuat. Kalau ada data baru di server, browser tidak akan tahu sampai kalian menekan tombol refresh.

Model ini bekerja baik untuk dokumen dan halaman yang jarang berubah. Masalahnya muncul ketika aplikasi butuh data yang selalu diperbarui — misalnya harga saham, skor pertandingan, atau notifikasi chat. HTTP adalah protokol stateless: setiap request berdiri sendiri, server tidak menyimpan konteks antar request.

Akibatnya, cara paling sederhana yang terpikir oleh developer pertama adalah: minta halaman itu memuat ulang secara berkala.

#Short Polling: Menanyakan Terus-Menerus

#Konsep Dasar

Short polling adalah pendekatan paling naif: klien meminta data ke server setiap beberapa detik, misalnya setiap 5 detik, tanpa peduli apakah ada data baru atau tidak.

Simulasi short polling

setInterval(async () => {
  const res = await fetch("/api/status");
  const data = await res.json();
  render(data);
}, 5000);

Kode di atas menanyakan endpoint /api/status setiap 5 detik. setInterval(async () => {...}, 5000) adalah inti short polling — sebuah timer yang memicu request berulang kali tanpa kondisi berhenti.

#Masalah yang Ditimbulkan

Short polling bekerja, tapi dengan biaya besar:

Latensi tinggi: data baru hanya terdeteksi pada interval berikutnya, rata-rata tertunda setengah interval.
Overhead jaringan: setiap request membawa header HTTP lengkap, sebagian besar tidak berguna.
Beban server: ribuan klien berarti ribuan request kosong per menit.
Pemborosan resource: listrik, bandwidth, dan CPU habis untuk pertanyaan yang jawabannya sudah diketahui.

Bayangkan 10.000 klien mem-poll setiap 5 detik: server menerima 120.000 request per menit hanya untuk mengatakan "tidak ada yang baru".

#Long Polling (Comet): Menahan Koneksi

#Konsep Dasar

Long polling memperbaiki masalah utama short polling. Alih-alih menutup koneksi setelah response, server menahan response tetap terbuka sampai ada data yang benar-benar siap dikirim.

Alurnya: klien mengirim request, server menggantungnya, dan baru mengirim response ketika data baru tersedia. Setelah data diterima, klien langsung membuat request baru untuk "menyambung" lagi.

Simulasi long polling

async function longPoll() {
  const res = await fetch("/api/events");
  const event = await res.json();
  render(event);
  longPoll();
}
longPoll();

Pola longPoll() yang memanggil dirinya sendiri setelah menerima event meniru perilaku Comet. Server menahan request fetch("/api/events") selama mungkin.

#Kelebihan dan Kekurangan

Long polling jauh lebih responsif daripada short polling: data terkirim hampir seketika saat tersedia. Tapi masalah lain muncul:

Header overhead: setiap event tetap membutuhkan round-trip HTTP penuh.
Koneksi terus didirikan dan dirobohkan: biaya TCP handshake berulang-ulang.
Timeout dan reconnection: server dan client harus sepakat soal timeout, atau koneksi putus di tengah jalan.
Kompleksitas tinggi: menjaga state antar koneksi bergantian itu rumit.

Long polling adalah lompatan besar, tapi masih jauh dari solusi ideal.

#Server-Sent Events (SSE): Satu Arah yang Lebih Baik

#Konsep Dasar

Server-Sent Events (SSE) datang dengan HTML5 dan memanfaatkan protokol yang ada: HTTP biasa yang dibiarkan terbuka. Perbedaan utamanya — server yang mendorong data ke klien melalui satu koneksi panjang, tanpa klien bertanya terus-menerus.

Konsumen SSE di browser

const sse = new EventSource("/api/stream");
 
sse.onmessage = (event) => {
  render(JSON.parse(event.data));
};

Dengan new EventSource("/api/stream"), browser membuat koneksi persisten. sse.onmessage dipanggil setiap kali server mengirim data. SSE juga punya automatic reconnection dan event ID untuk recovery posisi — dua fitur yang tidak dimiliki polling.

#Keterbatasan SSE

SSE menyelesaikan masalah arah server ke klien, tapi tidak penuh:

Satu arah: klien tidak bisa mengirim data melalui koneksi yang sama; butuh request HTTP terpisah.
Batas koneksi: browser membatasi sekitar 6 koneksi per domain di HTTP/1.1 — 6 tab stream berarti habis kuotanya.
Format text: SSE memang dirancang untuk text, bukan binary.
Koneksi satu arah dengan overhead HTTP: masih berbasis request yang di-upgrade, bukan protokol mandiri.

SSE tetap pilihan bagus untuk notifikasi dan live feed, tetapi untuk chat dua arah dia tidak cukup.

#Kelahiran WebSocket

#Kebutuhan yang Tidak Terpenuhi

Dari perjalanan di atas, terlihat kebutuhan yang konsisten:

Full-duplex: kedua pihak bisa mengirim kapan saja tanpa menunggu.
Latensi rendah: data terkirim dalam milidetik, bukan detik.
Overhead minimal: tanpa header HTTP berulang per pesan.
Binary dan text: mendukung audio, gambar, dan data biner.

#WebSocket sebagai Jawaban

WebSocket memenuhi semua kebutuhan itu dengan satu koneksi TCP persisten. Awalnya dia hanya proposal di browser, lalu distandarisasi sebagai RFC 6455 pada tahun 2011. Kini WebSocket menjadi tulang punggung aplikasi real-time: chat, game multiplayer, kolaborasi dokumen, dashboard live, dan trading platform.

Evolusi real-time web dalam satu baris

refresh manual → short polling → long polling → SSE → WebSocket

Alur refresh manual → short polling → long polling → SSE → WebSocket adalah ringkasan mental yang akan menemani kalian sepanjang series ini.

#Penutup

Episode 1 menunjukkan bahwa WebSocket adalah hasil evolusi, bukan penemuan mendadak. Setiap pendekatan sebelumnya memecahkan satu masalah tapi melahirkan masalah lain: short polling boros, long polling kompleks, dan SSE satu arah.

Inti yang harus dibawa pulang:

Web awal statis: data baru hanya terlihat setelah refresh manual.
Short polling boros latensi, bandwidth, dan resource server.
Long polling lebih responsif tapi masih berbasis round-trip HTTP.
SSE bagus untuk satu arah, tapi terbatas di jumlah koneksi dan tidak mendukung binary.
Kebutuhan full-duplex, latensi rendah, dan overhead minimal melahirkan WebSocket.

Di episode 2 selanjutnya kita akan membedah protokol WebSocket itu sendiri — standar RFC 6455, skema ws:// dan wss://, serta perbandingan WebSocket dengan SSE dan HTTP/2 Server Push. Kalian akan mulai melihat cara kerja di balik layar protokol yang sedang dipelajari ini.