28 Nov 2025·7 menit
WebSockets vs Server-Sent Events: pilih yang tepat
Perbandingan WebSockets dan Server-Sent Events untuk dashboard live, dengan aturan sederhana memilih, dasar penskalaan, dan langkah ketika koneksi terputus.
Perbandingan WebSockets dan Server-Sent Events untuk dashboard live, dengan aturan sederhana memilih, dasar penskalaan, dan langkah ketika koneksi terputus.
Dashboard live pada dasarnya adalah janji: angka berubah tanpa Anda menekan refresh, dan apa yang Anda lihat mendekati apa yang terjadi saat ini. Orang mengharapkan pembaruan terasa cepat (seringkali dalam satu atau dua detik), tapi mereka juga ingin halaman tetap tenang. Tidak ada flicker, tidak ada chart yang melompat, tidak ada banner "Disconnected" setiap beberapa menit.
Kebanyakan dashboard bukan aplikasi chat. Mereka terutama mendorong pembaruan dari server ke browser: titik metrik baru, status berubah, batch baris baru, atau alert. Bentuk-bentuk umum sudah akrab: papan metrik (CPU, pendaftaran, pendapatan), panel alerts (hijau/kuning/merah), tail log (event terbaru), atau tampilan progres (job di 63%, lalu 64%).
Pilihan antara WebSockets dan Server-Sent Events (SSE) bukan sekadar preferensi teknis. Itu mengubah seberapa banyak kode yang Anda tulis, berapa banyak kasus tepi aneh yang harus ditangani, dan seberapa mahal ketika 50 pengguna menjadi 5.000. Beberapa opsi lebih mudah diload-balance. Beberapa membuat logika koneksi ulang dan catch-up lebih sederhana.
Tujuannya sederhana: dashboard yang tetap akurat, responsif, dan tidak berubah menjadi mimpi buruk on-call saat tumbuh.
WebSockets dan Server-Sent Events sama-sama mempertahankan koneksi terbuka sehingga dashboard bisa diperbarui tanpa polling terus-menerus. Bedanya ada pada bagaimana percakapan berlangsung.
WebSockets dalam satu kalimat: satu koneksi panjang yang hidup di mana browser dan server sama-sama bisa mengirim pesan kapan saja.
SSE dalam satu kalimat: koneksi HTTP jangka panjang di mana server terus mendorong event ke browser, tetapi browser tidak mengirim pesan kembali di aliran yang sama.
Perbedaan itu biasanya menentukan apa yang terasa natural.
Contoh konkret: papan KPI penjualan yang hanya menampilkan pendapatan, uji coba aktif, dan tingkat error bisa berjalan nyaman dengan SSE. Layar trading di mana pengguna memasang order, menerima konfirmasi, dan mendapat umpan balik langsung untuk setiap aksi lebih berbentuk WebSocket.
Apapun yang Anda pilih, beberapa hal tidak berubah:
Transport adalah mil terakhir. Bagian tersulit seringkali sama baik dengan SSE atau WebSockets.
Perbedaan utama adalah siapa yang bisa berbicara, dan kapan.
Dengan Server-Sent Events, browser membuka satu koneksi jangka panjang dan hanya server yang mengirim pembaruan ke bawah pipa itu. Dengan WebSockets, koneksi bersifat dua arah: browser dan server bisa keduanya mengirim pesan kapan saja.
Untuk banyak dashboard, sebagian besar trafik adalah server ke browser. Pikirkan "order baru datang", "CPU 73%", "jumlah tiket berubah". SSE cocok dengan pola itu karena klien sebagian besar mendengarkan.
WebSockets lebih masuk akal ketika dashboard juga berfungsi sebagai panel kontrol. Jika pengguna perlu sering mengirim aksi (acknowledge alert, ganti filter bersama, kolaborasi), messaging dua arah bisa lebih bersih daripada terus-menerus membuat request baru.
Payload pesan biasanya JSON sederhana di kedua pendekatan. Pola umum adalah mengirim amplop kecil agar klien bisa merutekan pembaruan dengan aman:
{"type":"metric","name":"active_users","value":128,"ts":1737052800}
Fan-out adalah titik menarik saat dashboard: satu pembaruan sering perlu menjangkau banyak penonton sekaligus. Baik SSE maupun WebSockets bisa menyiarkan event yang sama ke ribuan koneksi terbuka. Bedanya operasional: SSE berperilaku seperti respons HTTP panjang, sementara WebSockets beralih ke protokol terpisah setelah upgrade.
Bahkan dengan koneksi live, Anda tetap akan menggunakan permintaan HTTP normal untuk hal-hal seperti load awal halaman, data historis, ekspor, aksi create/delete, refresh auth, dan query besar yang tidak masuk ke feed live.
Aturan praktis: simpan channel live untuk event kecil dan sering, dan gunakan HTTP untuk semuanya yang lain.
Jika dashboard Anda hanya perlu mendorong pembaruan ke browser, SSE biasanya menang soal kesederhanaan. Itu adalah respons HTTP yang tetap terbuka dan mengirim event teks saat terjadi. Lebih sedikit bagian bergerak berarti lebih sedikit kasus tepi.
WebSockets bagus ketika klien harus sering berbicara kembali, tetapi kebebasan itu menambah kode yang harus Anda pelihara.
Dengan SSE, browser terhubung, mendengarkan, dan memproses event. Koneksi ulang dan perilaku retry dasar sudah tertanam di banyak browser, jadi Anda menghabiskan lebih banyak waktu pada payload event dan lebih sedikit pada state koneksi.
Dengan WebSockets, Anda cepat menjadi pengelola lifecycle socket sebagai fitur utama: connect, open, close, error, reconnect, dan kadang ping/pong. Jika Anda punya banyak tipe pesan (filter, perintah, acknowledgement, sinyal presence), Anda juga perlu amplop pesan dan routing di klien maupun server.
Aturan praktis:
SSE seringkali lebih mudah di-debug karena berperilaku seperti HTTP biasa. Anda biasanya bisa melihat event dengan jelas di devtools browser, dan banyak proxy serta alat observabilitas sudah memahami HTTP dengan baik.
WebSockets bisa gagal dengan cara yang kurang jelas. Masalah umum adalah disconnect diam-diam dari load balancer, idle timeout, dan koneksi "half-open" di mana salah satu pihak mengira masih terhubung. Anda sering kali menyadari masalah hanya setelah pengguna melaporkan dashboard yang usang.
Contoh: jika Anda membangun dashboard penjualan yang hanya butuh total live dan order terbaru, SSE menjaga sistem stabil dan mudah dibaca. Jika halaman yang sama juga harus mengirim interaksi pengguna secara cepat (filter bersama, editing kolaboratif), WebSockets mungkin layak untuk kompleksitas ekstra.
Ketika dashboard naik dari beberapa penonton ke ribuan, masalah utama bukan bandwidth mentah. Melainkan jumlah koneksi terbuka yang harus Anda pertahankan, dan apa yang terjadi ketika beberapa klien itu lambat atau flaky.
Dengan 100 penonton, kedua opsi terasa mirip. Pada 1.000, Anda mulai peduli tentang batas koneksi, timeout, dan seberapa sering klien reconnect. Pada 50.000, Anda mengoperasikan sistem berat-koneksi: setiap kilobyte ekstra yang dibuffer per klien bisa berubah menjadi tekanan memori nyata.
Perbedaan penskalaan sering muncul pada load balancer.
WebSockets adalah koneksi jangka panjang dua arah, jadi banyak setup membutuhkan sticky sessions kecuali Anda punya lapisan pub/sub bersama dan server mana pun bisa menangani pengguna mana pun.
SSE juga jangka panjang, tapi itu HTTP biasa, sehingga cenderung bekerja lebih mulus dengan proxy yang ada dan bisa lebih mudah untuk fan-out.
Menjaga server stateless biasanya lebih sederhana dengan SSE untuk dashboard: server bisa mendorong event dari stream bersama tanpa mengingat banyak per klien. Dengan WebSockets, tim sering menyimpan state per-koneksi (subscriptions, last-seen IDs, konteks auth), yang membuat penskalaan horizontal lebih rumit kecuali Anda merancangnya sejak awal.
Klien lambat bisa merugikan Anda di kedua pendekatan. Perhatikan mode kegagalan ini:
Aturan sederhana untuk dashboard populer: pertahankan pesan kecil, kirim lebih jarang daripada yang Anda pikirkan, dan siap untuk menjatuhkan atau menggabungkan pembaruan (misalnya, hanya kirim nilai metrik terbaru) sehingga satu klien lambat tidak menarik seluruh sistem turun.
Dashboard live gagal karena alasan biasa: laptop tidur, Wi‑Fi pindah jaringan, perangkat mobile melewati terowongan, atau browser menangguhkan tab latar. Pilihan transport kurang penting dibandingkan bagaimana Anda memulihkan ketika koneksi putus.
Dengan SSE, browser memiliki koneksi ulang bawaan. Jika stream terputus, ia mencoba lagi setelah jeda singkat. Banyak server juga mendukung replay menggunakan event id (sering lewat header bergaya Last-Event-ID). Itu memungkinkan klien berkata, "Saya terakhir melihat event 1042, kirimkan apa yang saya lewatkan", yang jadi jalur sederhana menuju ketahanan.
WebSockets biasanya memerlukan logika klien lebih banyak. Ketika socket tertutup, klien harus mencoba lagi dengan backoff dan jitter (agar ribuan klien tidak reconnect sekaligus). Setelah reconnect, Anda juga butuh alur resubscribe yang jelas: autentikasi lagi jika perlu, lalu bergabung kembali ke channel yang benar, lalu minta pembaruan yang terlewat.
Risiko yang lebih besar adalah celah data diam-diam: UI terlihat baik, tetapi sudah usang. Gunakan salah satu pola ini agar dashboard bisa membuktikan dirinya mutakhir:
Contoh: dashboard penjualan yang menampilkan "orders per minute" bisa mentolerir celah singkat jika ia me-refresh total setiap 30 detik. Dashboard trading tidak bisa; ia butuh nomor urut dan snapshot pada setiap reconnect.
Dashboard live menjaga koneksi jangka panjang, jadi kesalahan kecil pada auth bisa bertahan selama menit atau jam. Keamanan kurang soal transport dan lebih soal bagaimana Anda mengautentikasi, mengotorisasi, dan mengakhiri akses.
Mulailah dengan dasar: gunakan HTTPS dan perlakukan setiap koneksi seperti sesi yang harus kedaluwarsa. Jika Anda mengandalkan cookie sesi, pastikan cakupannya benar dan diputar saat login. Jika menggunakan token (seperti JWT), buatlah berumur pendek dan rencanakan bagaimana klien memperbaruinya.
Satu jebakan praktis: SSE di browser (EventSource) tidak mengizinkan Anda mengatur header kustom. Itu sering mendorong tim ke arah auth berbasis cookie, atau menaruh token di URL. Token di URL bisa bocor lewat log dan copy‑paste, jadi jika Anda harus menggunakannya, buat berumur pendek dan hindari mencatat query string penuh. WebSockets biasanya memberi Anda lebih banyak fleksibilitas: Anda bisa mengautentikasi saat handshake (cookie atau query string) atau segera setelah connect dengan pesan auth.
Untuk dashboard multi-tenant, otorisasi dua kali: saat connect dan setiap subscribe. Seorang pengguna seharusnya hanya bisa subscribe ke stream yang mereka miliki (misalnya, org_id=123), dan server harus menegakkannya meskipun klien meminta lebih.
Untuk mengurangi penyalahgunaan, batasi dan pantau penggunaan koneksi:
Log itu adalah jejak audit Anda dan cara tercepat menjelaskan mengapa seseorang melihat dashboard kosong atau data orang lain.
Mulailah dengan satu pertanyaan: apakah dashboard Anda sebagian besar menonton, atau juga sering berbicara kembali? Jika browser terutama menerima pembaruan (chart, counter, lampu status) dan aksi pengguna bersifat sesekali (ubah filter, acknowledge alert), pertahankan channel realtime satu-arah.
Selanjutnya, lihat 6 bulan ke depan. Jika Anda mengharapkan banyak fitur interaktif (inline edit, kontrol mirip chat, drag-and-drop) dan banyak tipe event, rencanakan channel yang menangani kedua arah dengan bersih.
Kemudian putuskan seberapa benar tampilan harusnya. Jika boleh melewatkan beberapa pembaruan intermediate (karena pembaruan berikutnya menggantikan state lama), Anda bisa memilih kesederhanaan. Jika Anda butuh replay yang tepat (setiap event penting, audit, tick finansial), Anda butuh sequencing yang kuat, buffering, dan logika re-sync apa pun transport yang dipakai.
Terakhir, estimasi konkruensi dan pertumbuhan. Ribuan penonton pasif biasanya mendorong Anda ke opsi yang ramah infrastruktur HTTP dan penskalaan horizontal yang mudah.
Pilih SSE ketika:
Pilih WebSockets ketika:
Jika bimbang, pilih SSE dulu untuk dashboard baca‑berat tipikal, dan migrasikan hanya ketika kebutuhan dua-arah menjadi nyata dan terus‑menerus.
Kegagalan paling umum dimulai dengan memilih alat yang lebih kompleks daripada kebutuhan dashboard. Jika UI hanya butuh update server-ke-klien (harga, counter, status job), WebSockets bisa menambah bagian bergerak tanpa banyak manfaat. Tim menghabiskan waktu debugging state koneksi dan routing pesan alih-alih dashboard.
Reconnect adalah jebakan lain. Reconnect biasanya memulihkan koneksi, bukan data yang hilang. Jika laptop pengguna tidur selama 30 detik, mereka bisa melewatkan event dan dashboard bisa menampilkan total yang salah kecuali Anda merancang langkah catch-up (misalnya: last seen event id atau since timestamp, lalu refetch).
Broadcast frekuensi tinggi bisa diam-diam menjatuhkan Anda. Mengirim setiap perubahan kecil (setiap update baris, setiap tick CPU) meningkatkan beban, chatter jaringan, dan jitter UI. Batching dan throttling sering membuat dashboard terasa lebih cepat karena pembaruan tiba dalam potongan bersih.
Perhatikan jebakan produksi ini:
Contoh: dashboard tim support menampilkan jumlah tiket live. Jika Anda mendorong setiap perubahan tiket segera, agen melihat angka berkedip dan kadang mundur setelah reconnect. Pendekatan yang lebih baik adalah mengirim pembaruan setiap 1-2 detik dan, saat reconnect, ambil total saat ini sebelum melanjutkan event.
Bayangkan dashboard admin SaaS yang menampilkan metrik billing (langganan baru, churn, MRR) ditambah alert insiden (error API, backlog queue). Sebagian besar penonton hanya menonton angka dan ingin mereka terupdate tanpa refresh halaman. Hanya beberapa admin yang mengambil tindakan.
Di awal, mulai dengan stream paling sederhana yang memenuhi kebutuhan. SSE sering cukup: dorong pembaruan metrik dan pesan alert satu-arah dari server ke browser. Lebih sedikit state untuk diolah, lebih sedikit kasus tepi, dan perilaku reconnect terduga. Jika update terlewat, pesan berikutnya bisa menyertakan total terbaru sehingga UI cepat sembuh.
Beberapa bulan kemudian, penggunaan tumbuh dan dashboard jadi interaktif. Sekarang admin ingin filter live (ubah jendela waktu, toggle region) dan mungkin kolaborasi (dua admin acknowledge alert yang sama dan melihatnya terupdate instan). Di sinilah pilihan bisa berubah. Messaging dua-arah memudahkan mengirim aksi pengguna pada channel yang sama dan menjaga state UI bersama tetap sinkron.
Jika perlu migrasi, lakukan dengan aman daripada mengganti semalam:
Sebelum menampilkan dashboard live ke pengguna nyata, anggap jaringan akan fluktuatif dan beberapa klien akan lambat.
Berikan setiap update ID event unik dan timestamp, dan tulis aturan pengurutan Anda. Jika dua update tiba tidak berurutan, mana yang menang? Ini penting saat reconnect memutar ulang event lama atau ketika banyak layanan menerbitkan pembaruan.
Reconnect harus otomatis dan sopan. Gunakan backoff (cepat pada awal, lalu melambat) dan hentikan retry selamanya ketika pengguna keluar.
Juga tentukan apa yang dilakukan UI saat data usang. Misalnya: jika tidak ada pembaruan selama 30 detik, redupkan chart, jeda animasi, dan tampilkan status "stale" daripada diam-diam menampilkan angka lama.
Tetapkan batas per pengguna (koneksi, pesan per menit, ukuran payload) agar satu tab storm tidak menjatuhkan semua orang.
Lacak memori per koneksi dan tangani klien lambat. Jika browser tidak bisa mengejar, jangan biarkan buffer tumbuh tanpa batas. Putuskan koneksi, kirim pembaruan lebih kecil, atau beralih ke snapshot periodik.
Catat connect, disconnect, reconnect, dan alasan error. Buat alert untuk lonjakan terbuka koneksi yang tidak biasa, tingkat reconnect, dan backlog pesan.
Simpan saklar darurat sederhana untuk menonaktifkan streaming dan kembali ke polling atau refresh manual. Saat sesuatu salah jam 2 pagi, Anda menginginkan satu opsi aman.
Tampilkan "Last updated" di dekat angka kunci, dan sertakan tombol refresh manual. Itu mengurangi tiket dukungan dan membantu pengguna percaya pada apa yang mereka lihat.
Mulailah kecil dengan sengaja. Pilih satu stream dulu (misalnya, CPU dan rate request, atau hanya alert) dan tulis kontrak event: nama event, field, unit, dan frekuensi pembaruan. Kontrak jelas menjaga UI dan backend tidak menyimpang.
Bangun prototipe sekali pakai yang fokus pada perilaku, bukan tampilan. Buat UI menunjukkan tiga status: connecting, live, dan catching up setelah reconnect. Lalu paksa kegagalan: matikan tab, aktifkan mode pesawat, restart server, dan lihat apa yang dilakukan dashboard.
Sebelum meningkatkan trafik, putuskan bagaimana Anda akan memulihkan dari celah. Pendekatan sederhana adalah mengirim snapshot saat connect (atau reconnect), lalu kembali ke pembaruan live.
Langkah praktis sebelum rollout lebih luas:
Jika Anda bergerak cepat, Koder.ai (koder.ai) dapat membantu Anda memprototaip loop penuh dengan cepat: UI React, backend Go, dan alur data dibangun dari prompt chat, dengan ekspor kode sumber dan opsi deploy saat siap.
Setelah prototipe Anda bertahan kondisi jaringan jelek, penskalaan sebagian besar menjadi repetisi: tambah kapasitas, terus ukur lag, dan jaga jalur reconnect tetap membosankan dan andal.
Gunakan SSE ketika browser sebagian besar hanya mendengarkan dan server sebagian besar menyiarkan. Ini cocok untuk metrik, alert, lampu status, dan panel "event terbaru" di mana aksi pengguna terjadi sesekali dan bisa dikirim lewat permintaan HTTP biasa.
Pilih WebSockets ketika dashboard juga berfungsi sebagai panel kontrol dan klien perlu mengirim aksi berfrekuensi tinggi dengan latensi rendah. Jika pengguna sering mengirim perintah, acknowledgment, perubahan kolaboratif, atau input real-time lain, komunikasi dua arah biasanya lebih sederhana dengan WebSockets.
SSE adalah respons HTTP yang berlangsung lama di mana server mendorong event ke browser. WebSockets meng-upgrade koneksi ke protokol dua arah terpisah sehingga kedua pihak bisa mengirim pesan kapan saja. Untuk dashboard yang banyak membaca, fleksibilitas dua arah itu seringkali menjadi overhead yang tidak perlu.
Tambahkan ID event (atau nomor urut) ke setiap update dan sediakan jalur "catch-up" yang jelas. Saat reconnect, klien sebaiknya memutar ulang event yang terlewat (jika memungkinkan) atau mengambil snapshot segar dari state saat ini, lalu melanjutkan pembaruan live sehingga UI kembali benar.
Anggap staleness sebagai status UI yang nyata, bukan kegagalan tersembunyi. Tampilkan sesuatu seperti “Last updated” di dekat angka kunci, dan jika tidak ada event selama beberapa waktu, tandai tampilan sebagai stale sehingga pengguna tidak mempercayai data lama secara tidak sengaja.
Mulai dengan menjaga pesan kecil dan jangan kirim setiap perubahan kecil. Gabungkan pembaruan yang sering (kirim nilai terakhir alih-alih setiap nilai perantara), dan gunakan snapshot periodik untuk total. Masalah penskalaan paling sering berasal dari banyak koneksi terbuka dan klien lambat, bukan bandwidth mentah.
Klien lambat bisa membuat buffer server membengkak dan menghabiskan memori per koneksi. Batasi antrean data per klien, turunkan atau batasi pembaruan saat klien tidak bisa mengejar, dan prioritaskan pesan “state terakhir” dibandingkan backlog panjang untuk menjaga stabilitas sistem.
Autentikasi dan otorisasi setiap stream seperti sesi yang harus kedaluwarsa. SSE di browser biasanya mendorong penggunaan cookie karena EventSource tidak mengizinkan header kustom, sementara WebSockets memberi fleksibilitas untuk autentikasi saat handshake atau dengan pesan autentikasi pertama. Di kedua kasus, tegakkan izin tenant dan stream di server, bukan di UI.
Kirim event kecil dan sering di saluran live, dan simpan pekerjaan berat pada endpoint HTTP biasa. Load awal halaman, query historis, ekspor, dan respons besar lebih baik lewat permintaan biasa, sementara stream live membawa pembaruan ringan yang menjaga UI tetap mutakhir.
Jalankan keduanya paralel untuk sementara dan mirror event yang sama ke tiap saluran. Pindahkan sebagian kecil pengguna terlebih dahulu, uji reconnect dan restart server di kondisi nyata, lalu bertahap lakukan cutover. Menjaga jalur lama sebentar sebagai fallback membuat rollout jauh lebih aman.