SSE vs HTTP Long Polling vs WebSocket: Memilih Teknologi Real-Time yang Tepat

Ketika sebuah aplikasi membutuhkan data yang berubah secara real-time, biasanya kita langsung berpikir tentang WebSocket.

Padahal, WebSocket bukan satu-satunya pilihan.

Ada beberapa pendekatan yang bisa digunakan untuk membuat aplikasi terasa real-time, mulai dari polling dengan interval, HTTP Long Polling, Server-Sent Events (SSE), hingga WebSocket.

Masing-masing memiliki cara kerja, kelebihan, dan trade-off yang berbeda.

Dalam praktiknya, memilih teknologi real-time bukan tentang mencari teknologi yang paling canggih, tetapi memilih teknologi yang paling sesuai dengan pola komunikasi aplikasi.

Apa yang Dimaksud dengan Real-Time?

Pada aplikasi tradisional, browser melakukan request ke server ketika membutuhkan data.

Misalnya:

Browser → GET /api/jobs
Server  → Response

Setelah response diterima, koneksi selesai.

Masalahnya muncul ketika data di server bisa berubah tanpa adanya aksi dari pengguna.

Misalnya kita mempunyai halaman monitoring job:

Job 1 → Processing
Job 2 → Processing
Job 3 → Completed

Ketika Job 1 selesai, kita ingin UI langsung berubah:

Job 1 → Completed

tanpa pengguna melakukan refresh halaman.

Ada beberapa cara untuk melakukannya.

1. Polling dengan Interval

Cara paling sederhana adalah polling.

Browser secara berkala melakukan request ke server untuk menanyakan kondisi terbaru.

Misalnya setiap 5 detik:

Client → GET /api/status
Server → belum ada perubahan

5 detik

Client → GET /api/status
Server → belum ada perubahan

5 detik

Client → GET /api/status
Server → status berubah

Implementasinya juga sederhana:

setInterval(async () => {
  const response = await fetch('/api/status');
  const data = await response.json();

  updateUI(data);
}, 5000);

Masalahnya adalah client tetap melakukan request walaupun tidak ada perubahan.

Misalnya status hanya berubah sekali dalam satu menit:

00s → request
05s → request
10s → request
15s → request
20s → request
25s → request
30s → request
35s → request
40s → request
45s → request
50s → request
55s → request
60s → data berubah

Dari 12 request tersebut, mungkin hanya satu request yang benar-benar mendapatkan perubahan.

2. Polling Interval vs Long Polling

Keduanya sering dianggap sama karena sama-sama melakukan polling.

Padahal mekanismenya berbeda.

Perbedaan paling penting adalah:

Apakah server langsung memberikan response atau menunggu sampai ada data baru?

Polling Interval

Pada polling biasa, client menentukan kapan harus melakukan request.

Misalnya:

setiap 5 detik → request

Server menerima request dan langsung memberikan response.

Client
   │
   │ GET /status
   ▼
Server
   │
   │ response
   ▼
Client

   5 detik kemudian

Client
   │
   │ GET /status
   ▼
Server
   │
   │ response
   ▼
Client

Server tidak menahan request.

Long Polling

Pada Long Polling, client tetap melakukan request seperti biasa.

Namun kali ini server menahan request tersebut sampai ada data baru atau timeout.

Client
   │
   │ GET /status
   ▼
Server
   │
   │ menunggu...
   │
   │ menunggu...
   │
   │ data berubah
   ▼
Response
   │
   ▼
Client

Setelah response diterima, client membuat request baru.

Client → GET /status
             │
             │ menunggu
             │
             ▼
          response
             │
             ▼
Client → GET /status
             │
             │ menunggu
             │
             ▼
          response

3. Contoh Perbedaan Latency

Misalnya kita menggunakan polling interval selama 10 detik.

Event terjadi pada detik pertama:

Event terjadi: 1s

Client baru melakukan pengecekan:
10s

Latency:
~9 detik

Client bisa saja baru mengetahui perubahan hampir 9 detik kemudian.

Sedangkan dengan Long Polling:

Request: 0s
Event:   1s
Response: 1s

Server langsung mengembalikan response ketika event terjadi.

Karena itu Long Polling biasanya memiliki latency yang lebih rendah dibanding polling interval.

4. Perbandingan Polling dan Long Polling

* Long Polling tetap bisa menghasilkan response karena timeout. Jadi setelah timeout, client tetap perlu membuat request baru.

Secara sederhana:

Polling: “Saya akan tanya setiap 5 detik.”

Long Polling: “Saya tanya sekarang. Kasih tahu saya kalau ada perubahan.”

5. Kekurangan Long Polling

Walaupun lebih efisien dibanding polling biasa, Long Polling tetap memiliki satu masalah:

Request tetap harus dibuat berulang kali.

Misalnya server memiliki timeout 30 detik:

Request #1
    ↓
menunggu
    ↓
timeout
    ↓
Request #2
    ↓
menunggu
    ↓
event
    ↓
response
    ↓
Request #3

Client harus mengelola siklus tersebut.

Kita juga perlu menangani:

• timeout
• reconnect
• connection failure
• duplicate event
• request cancellation
• race condition

Untuk kebutuhan sederhana, ini masih masuk akal.

Tetapi ketika kebutuhan kita memang berupa streaming event dari server, ada mekanisme yang lebih natural.

6. Server-Sent Events (SSE)

Server-Sent Events, atau SSE, menggunakan HTTP connection yang tetap terbuka.

Berbeda dengan Long Polling, browser tidak perlu membuat request baru setiap kali menerima event.

Browser
   │
   │ GET /events
   ▼
Server
   │
   │ connection tetap terbuka
   │
   ├── event 1
   ├── event 2
   ├── event 3
   ├── event 4
   │
   ▼
Browser

SSE sangat cocok untuk komunikasi:

Server → Client

Contohnya:

• progress job
• notification
• monitoring
• log streaming
• status processing
• live dashboard
• replication status

7. SSE Sebenarnya Masih HTTP

Salah satu hal menarik dari SSE adalah SSE tidak membutuhkan protokol komunikasi baru seperti WebSocket.

SSE berjalan di atas HTTP.

Client membuat request:

GET /api/events
Accept: text/event-stream

Server kemudian memberikan response:

Content-Type: text/event-stream

Connection tersebut tetap terbuka.

Server dapat mengirim event kapan saja:

data: {"status":"processing"}

data: {"status":"completed"}

Browser akan menerima event tersebut tanpa perlu membuat request baru.

8. Contoh Implementasi SSE

Browser sudah menyediakan API khusus untuk SSE melalui EventSource.

const eventSource = new EventSource('/api/events');

eventSource.onmessage = (event) => {
  const data = JSON.parse(event.data);

  console.log(data);
};

Berbeda dengan polling:

setInterval(...)

kita tidak perlu terus-menerus membuat request.

Cukup membuka satu connection:

Browser
   │
   │ GET /api/events
   ▼
Server
   │
   ├── event
   ├── event
   ├── event
   ├── event
   └── ...

9. WebSocket

Jika SSE fokus pada:

Server → Client

WebSocket memungkinkan komunikasi dua arah:

Client ↔ Server

Setelah connection WebSocket dibuat, kedua pihak dapat mengirim message kapan saja.

Client
   │
   ├──── message ────→ Server
   │
   │ ←──── message ────┤
   │
   ├──── message ────→ Server
   │
   │ ←──── message ────┤

Contohnya:

• chat
• multiplayer game
• collaborative editing
• trading interface
• live location
• realtime interaction

10. SSE vs WebSocket

Perbedaan paling penting bukan sekadar mana yang lebih cepat.

Tetapi arah komunikasinya.

Jika kebutuhan aplikasi hanya:

Backend → UI

SSE sering kali sudah cukup.

Jika membutuhkan:

UI ↔ Backend

secara real-time, WebSocket lebih cocok.

11. Contoh Kasus: Monitoring Job

Misalnya kita memiliki sistem yang menjalankan banyak job.

Status job berubah:

Queued
   ↓
Processing
   ↓
Completed

UI ingin mengetahui perubahan status tanpa refresh.

Ada empat pendekatan.

Polling

Browser bertanya setiap beberapa detik:

GET /jobs/123
GET /jobs/123
GET /jobs/123
GET /jobs/123

Walaupun tidak ada perubahan, request tetap terjadi.

Long Polling

Browser melakukan:

GET /jobs/123/events

Server menunggu sampai status berubah atau timeout.

Setelah response diterima, browser melakukan request lagi.

SSE

Browser membuka:

GET /jobs/123/events

Kemudian server dapat terus mengirim:

status: processing

status: completed

Tanpa request baru.

WebSocket

Browser membuka connection:

ws://example.com/jobs

Server dapat mengirim status:

{
  "event": "job.updated",
  "job_id": 123,
  "status": "completed"
}

Client juga dapat mengirim command:

{
  "action": "cancel",
  "job_id": 123
}

12. Bagaimana Memilihnya?

Gunakan pertanyaan sederhana.

Data tidak perlu benar-benar real-time?

Gunakan:

Polling Interval

Misalnya:

Refresh dashboard setiap 30 detik
Sync status setiap 1 menit

Tidak perlu membuat sistem yang lebih kompleks.

Ingin lebih cepat tetapi tetap menggunakan HTTP request/response?

Gunakan:

Long Polling

Cocok ketika:

• event tidak terlalu sering
• jumlah client tidak terlalu besar
• infrastructure masih berbasis HTTP
• ingin mengurangi request kosong

Server perlu terus mengirim event ke browser?

Gunakan:

SSE

Contohnya:

Monitoring
Notification
Progress
Logs
Dashboard
Replication status

Client dan server harus berkomunikasi dua arah secara real-time?

Gunakan:

WebSocket

Contohnya:

Chat
Gaming
Collaborative application
Live interaction
Realtime location

13. Jangan Selalu Memilih WebSocket

WebSocket memang powerful.

Tetapi powerful tidak selalu berarti lebih tepat.

Jika kebutuhan kita hanya:

Backend → UI

menggunakan WebSocket berarti kita membawa kompleksitas tambahan yang sebenarnya belum diperlukan.

Kita harus memikirkan:

• connection lifecycle
• reconnect
• heartbeat
• authentication
• connection state
• scaling
• connection management
• load balancer
• WebSocket support pada infrastructure

Sementara SSE sudah menyediakan mekanisme yang lebih sederhana untuk kebutuhan server-to-client streaming.

14. Bagaimana dengan Reconnect?

SSE memiliki mekanisme reconnect bawaan melalui EventSource.

Misalnya koneksi terputus:

Server
   X
Client

Browser dapat mencoba membuat koneksi kembali.

Server juga dapat menentukan interval retry:

retry: 5000

Sehingga client dapat mencoba reconnect setelah beberapa waktu.

Ini cukup berguna untuk aplikasi monitoring karena koneksi jaringan tidak selalu stabil.

15. SSE dan Reverse Proxy

Walaupun SSE menggunakan HTTP, ada satu hal yang perlu diperhatikan:

response harus benar-benar dikirim sebagai stream.

Arsitekturnya bisa seperti:

Application
     ↓
    SSE
     ↓
Reverse Proxy
     ↓
  Browser

Jika reverse proxy melakukan buffering, event yang seharusnya dikirim satu per satu dapat tertahan.

Akibatnya UI terlihat seperti tidak real-time.

Jadi ketika menggunakan SSE, konfigurasi application server dan reverse proxy juga perlu diperhatikan.

16. Jangan Mengukur Hanya dari “Mana yang Paling Cepat”

Kesalahan yang cukup umum ketika membandingkan teknologi real-time adalah hanya melihat latency.

Padahal ada faktor lain:

Latency
Connection management
Server resource
Infrastructure
Reconnect
Scalability
Communication direction
Implementation complexity

Teknologi yang paling tepat bukan yang paling canggih, tetapi yang memberikan kompleksitas paling rendah untuk kebutuhan yang sebenarnya.

Kesimpulan

Polling Interval, Long Polling, SSE, dan WebSocket sebenarnya berada pada spektrum yang sama: bagaimana client mendapatkan perubahan data dari server.

Perbedaannya terutama berada pada cara connection dikelola.

Polling

Request → Response
Request → Response
Request → Response

Long Polling

Request → menunggu → Response
Request → menunggu → Response

SSE

Request → connection terbuka
             ↓
          Event
          Event
          Event

WebSocket

Connection terbuka
       ↕
Client ↔ Server

Kalau data tidak membutuhkan update cepat, polling interval mungkin sudah cukup.

Kalau ingin mengurangi request kosong tetapi tetap menggunakan pola HTTP request/response, Long Polling bisa digunakan.

Kalau server perlu mengirim event secara terus-menerus ke client, SSE menjadi pilihan yang sederhana.

Dan kalau komunikasi harus benar-benar dua arah secara real-time, WebSocket lebih tepat.

Jadi, jangan mulai dengan pertanyaan:

“Teknologi real-time apa yang paling canggih?”

Lebih baik mulai dengan:

“Seberapa sering data berubah, siapa yang mengirim data, dan apakah connection perlu tetap terbuka?”

Dari tiga pertanyaan tersebut, pilihan teknologinya biasanya menjadi jauh lebih jelas.