WebSocket — Dari Polling ke Koneksi Langsung: Kenapa Aplikasi Real-Time Butuh Protokol Ini

Beberapa waktu lalu, aku iseng bikin halaman sederhana buat nampilin log server secara live. Ide awalnya cuma refresh halaman tiap 5 detik pakai JavaScript. Pas dilihat hasilnya, rasanya kaya menunggu pesan di era SMS: tegang, lambat, dan boros baterai. Baru aku sadar, ada cara yang jauh lebih elegan buat komunikasi dua arah antara browser dan server: WebSocket.

WebSocket itu kaya terowongan langsung yang dibuka dari browser ke server. Sekali pintu terbuka, kedua belah pihak bisa saling kirim pesan kapan saja tanpa harus membuka pintu baru. Kalau HTTP biasa kaya bertamu ke rumah teman, habis ngobrol langsung pulang, WebSocket itu kaya ngobrol lewat intercom yang selalu nyambung.

HTTP Bukanlah Jalur Dua Arah

Sebelum WebSocket, cara paling umum buat dapetin data terbaru dari server adalah polling. Browser minta data ke server setiap beberapa detik, meski data-nya belum tentu berubah. Kaya kamu nanyain teman, "Sudah sampai belum?" setiap menit, padahal dia masih di jalan.

Ada varian yang lebih efisien namanya long polling. Server menahan request sampai ada data baru, baru kemudian balas. Tetapi tetap saja, setiap balasan harus ditutup dan request baru dibuka lagi. Overhead-nya masih besar, terutama buat aplikasi yang butuh latensi rendah kaya chat, notifikasi live, atau dashboard monitoring.

HTTP dirancang buat request-response: client minta, server balas, selesai. Dia tidak punya mekanisme bawaan buat server ngirim data ke client secara aktif. WebSocket datang buat mengisi celah itu.

WebSocket: Terowongan TCP yang Dibuka lewat HTTP

WebSocket dimulai dengan HTTP biasa. Client kirim request dengan header khusus:

GET /chat HTTP/1.1
Host: example.com
Upgrade: websocket
Connection: Upgrade
Sec-WebSocket-Key: dGhlIHNhbXBsZSBub25jZQ==
Sec-WebSocket-Version: 13

Server yang mendukung WebSocket akan balas dengan status 101 Switching Protocols:

HTTP/1.1 101 Switching Protocols
Upgrade: websocket
Connection: Upgrade
Sec-WebSocket-Accept: s3pPLMBiTxaQ9kYGzzhZRbK+xOo=

Setelah handshake ini, koneksi HTTP berubah jadi koneksi WebSocket. Dari sini, browser dan server bisa saling kirim frame data dalam satu saluran yang sama, tanpa header HTTP berulang kali. Lebih ringan, lebih cepat, dan lebih real-time.

Hands-On: Server Node.js Sederhana

Aku suka Node.js buat eksperimen WebSocket karena ringan. Cukup install paket ws, lalu buat file server. Contoh di bawah ini membuat server yang menyebarkan pesan dari satu client ke semua client yang terhubung:

// server.js
const WebSocket = require('ws');
const wss = new WebSocket.Server({ port: 8080 });

wss.on('connection', (ws) => {
  console.log('Client baru terhubung');

  ws.on('message', (message) => {
    const text = message.toString();
    console.log('Diterima:', text);

    // Broadcast ke semua client
    wss.clients.forEach((client) => {
      if (client.readyState === WebSocket.OPEN) {
        client.send(text);
      }
    });
  });

  ws.on('close', () => {
    console.log('Client terputus');
  });
});

console.log('WebSocket server berjalan di ws://localhost:8080');

Jalankan dengan node server.js, maka server sudah siap menerima koneksi. Bagian paling menarik: satu baris client.send() dari server bisa langsung sampai ke browser tanpa menunggu request baru.

Client di Browser

Di sisi browser, kita pakai objek WebSocket bawaan JavaScript. Tidak perlu library tambahan untuk kasus sederhana:

// client.js
const socket = new WebSocket('ws://localhost:8080');

socket.addEventListener('open', () => {
  console.log('Terhubung ke server');
  socket.send('Halo dari browser!');
});

socket.addEventListener('message', (event) => {
  console.log('Pesan dari server:', event.data);
  document.getElementById('log').innerText += event.data + '\n';
});

socket.addEventListener('close', () => {
  console.log('Koneksi tertutup');
});

socket.addEventListener('error', (error) => {
  console.error('Terjadi error:', error);
});

Perhatikan event message: ini yang membuat WebSocket beda dari fetch atau AJAX. Server bisa memicu event ini kapan saja. Browser tidak perlu refresh atau polling. Cukup dengerin, seperti radio yang selalu menyala.

Kapan Harus Pakai WebSocket?

WebSocket bukan solusi untuk semua masalah. Dia paling berharga saat aplikasi punya pola push dari server ke client. Berikut beberapa contohnya:

• Chat dan messaging: pesan masuk harus langsung muncul di penerima tanpa reload.
• Live notification: notifikasi real-time kaya alert monitoring atau update harga saham.
• Collaborative editing: Google Docs-style, di mana perubahan dari satu user harus langsung terlihat user lain.
• Online gaming: latensi rendah adalah segalanya.
• Dashboard IoT: sensor mengirim data terus-menerus ke dashboard.

Semua skenario di atas punya kesamaan: data mengalir terus, arahnya bisa dua arah, dan delay harus kecil.

Kapan Tidak Perlu WebSocket?

Di sisi lain, pakai WebSocket untuk hal yang sebenarnya cocok pakai HTTP biasa justru menambah kompleksitas. Jangan pakai WebSocket kalau:

• Data jarang berubah dan user tidak butuh update instan.
• Aplikasi hanya butuh request-response sederhana, kaya halaman login atau submit form.
• Server kamu tidak punya mekanisme buat menangani banyak koneksi terbuka secara bersamaan.

WebSocket membuat koneksi tetap terbuka. Setiap koneksi itu memakan memori dan file descriptor. Kalau aplikasi sudah cukup dengan polling setiap 30 detik, mungkin tidak perlu repot-repot.

Catatan Keamanan dan Produksi

Kalau aplikasi sudah production, jangan lupa gunakan wss:// bukan ws://. wss:// adalah versi terenkripsi, sama kaya HTTPS. Selain itu, pertimbangkan:

• Autentikasi: verifikasi client saat handshake, misalnya lewat token di query string atau cookie.
• Rate limiting: batasi berapa pesan yang boleh dikirim client per detik.
• Heartbeat: kirim ping/pong secara berkala buat memastikan koneksi masih hidup.
• Reconnect: di browser, siapkan logika reconnect dengan exponential backoff kalau koneksi putus.

Di home server, aku sering pakai WebSocket buat hal-hal kecil: log monitoring, status download, atau notifikasi proses backup. Hasilnya? Dashboard terasa hidup, tanpa harus dipaksa refresh setiap saat.

Kesimpulan

WebSocket adalah protokol yang mengubah komunikasi web dari pola "tanya-jawab" menjadi percakapan dua arah yang terus berlangsung. Untuk aplikasi real-time, dia jauh lebih efisien daripada polling atau long polling. Tapi seperti setiap teknologi, dia punya tempat yang tepat: pakai saat kamu butuh push dari server, rendah latensi, dan koneksi persisten.

Kalau kamu punya project kecil yang butuh update live, coba buat server WebSocket sederhana. Rasanya berbeda ketika browser berhenti jadi pengunjung yang terus mengetuk pintu, dan mulai jadi penghuni yang duduk ngobrol di ruang tamu.

Ada pengalaman pakai WebSocket sendiri? Atau masih bingung kapan pakai polling dan kapan pakai WebSocket? Tulis di kolom komentar, aku senang dengar ceritamu.