Server-Sent Events untuk Dashboard SaaS Indonesia: Cara Real-Time Tanpa Kompleksitas WebSocket di 2026

TL;DR: Server-Sent Events (SSE) adalah protokol HTTP satu-arah dari server ke browser yang ideal untuk dashboard live, notifikasi, dan progress feed. Dibanding WebSocket, SSE lebih sederhana, otomatis reconnect, dan jalan di koneksi HTTP/2 standar. Untuk SaaS Indonesia dengan audiens dashboard internal, SSE biasanya 60-80% lebih murah dipelihara dari WebSocket.

Tim engineering sering reflex langsung pilih WebSocket setiap kali ada kebutuhan real-time, padahal banyak use case di SaaS hanya butuh aliran data satu-arah server ke client. Dalam beberapa proyek dashboard yang saya tangani 2025-2026, mengganti WebSocket dengan Server-Sent Events memangkas kompleksitas infrastruktur tanpa kehilangan pengalaman real-time yang dirasa user.

Apa itu Server-Sent Events dan Bedanya dengan WebSocket

Server-Sent Events adalah standar HTML5 yang memungkinkan server push data ke browser melalui koneksi HTTP yang tetap terbuka. Browser memakai EventSource API untuk subscribe, dan server kirim event dengan format text/event-stream. Komunikasi bersifat satu-arah (server ke client), jadi cocok untuk feed yang client tidak perlu balas.

WebSocket berbeda. Ia full-duplex (dua arah), bekerja di protokol terpisah dari HTTP setelah handshake, dan butuh manajemen state yang lebih rumit. Untuk fitur seperti chat, kolaborasi dokumen, atau game multiplayer, WebSocket tetap pilihan tepat karena client juga sering kirim data ke server. Tapi untuk dashboard analytics, log viewer, build progress, atau notification feed, WebSocket sering overkill.

Kapan SSE Pilihan yang Tepat

Berdasarkan praktik di industri dan project yang saya tangani, SSE jadi pilihan yang tepat saat:

1. Aliran data hanya satu arah server ke client.
2. Pesan kecil dan tidak butuh latency super rendah (di bawah 100 ms tetap aman).
3. Sumber data adalah event-based (notifikasi, log, metric, progress).
4. Anda ingin memakai infrastruktur HTTP standar (CDN, reverse proxy, JWT auth).
5. Tim ingin minimal kode tambahan dan minimal moving parts.

Lawan dari ini, jangan pakai SSE saat:

1. Client perlu kirim banyak event balik ke server.
2. Aplikasi butuh framing biner besar (file streaming, voice, video).
3. Anda perlu peer-to-peer atau koordinasi multi-client (kolaborasi real-time).

Implementasi di Next.js dengan App Router

Next.js 14 dan 15 mendukung SSE via Route Handler dengan Web Streams API. Pola yang saya pakai di proyek client untuk dashboard metrics live:

// app/api/metrics/stream/route.ts
export const runtime = 'edge';

export async function GET(req: Request) {
  const stream = new ReadableStream({
    async start(controller) {
      const encoder = new TextEncoder();
      const interval = setInterval(async () => {
        const data = await fetchLatestMetric();
        controller.enqueue(encoder.encode(`data: ${JSON.stringify(data)}\n\n`));
      }, 2000);

      req.signal.addEventListener('abort', () => {
        clearInterval(interval);
        controller.close();
      });
    },
  });

  return new Response(stream, {
    headers: {
      'Content-Type': 'text/event-stream',
      'Cache-Control': 'no-cache, no-transform',
      'Connection': 'keep-alive',
    },
  });
}

Di sisi React, EventSource dibungkus hook sederhana yang otomatis cleanup saat unmount. Pattern ini ringan dan tidak butuh library tambahan, sejalan dengan prinsip DRY dan stack yang ramping di portfolio Next.js.

Studi Kasus: Atmo dan Dashboard Build Status

Saat membangun Atmo (LMS), salah satu fitur internalnya adalah dashboard yang menampilkan progress import bulk pengajar dan murid. Awalnya tim memakai polling per 3 detik, yang berarti tiap user dashboard menambah beban request 1.200 per jam. Saat 50 admin sekolah membuka dashboard bersamaan saat onboarding, server overhead meningkat signifikan.

Mengganti polling dengan SSE memangkas request cold-start menjadi satu koneksi per user yang tetap terbuka. Memory footprint server justru turun karena tidak ada handshake berulang, dan UX terasa lebih responsif karena update tampil seketika setelah event di backend, bukan menunggu siklus polling berikutnya.

Penting dicatat, SSE punya batas connection per origin (default 6 di HTTP/1.1). Solusi untuk ini adalah memakai HTTP/2 atau HTTP/3 di reverse proxy seperti Nginx atau Cloudflare yang sudah jadi praktik default di Vercel.

Pertanyaan Umum

Apakah SSE bekerja di balik load balancer dan CDN?

Ya, asalkan disabled buffering untuk path stream. Di Nginx pakai proxy_buffering off, di Cloudflare nonaktifkan caching dan rocket loader untuk endpoint SSE. Di Vercel, koneksi otomatis kompatibel.

Berapa banyak koneksi SSE yang bisa dipegang server Node.js?

Per instance Node.js modern, 10.000-30.000 koneksi idle realistis. Di luar itu pertimbangkan worker scaling atau pindah ke runtime yang lebih efisien untuk koneksi long-lived seperti Go atau Cloudflare Workers.

Apakah SSE bisa kirim binary data?

Tidak langsung. SSE hanya kirim teks UTF-8. Untuk binary (gambar, file), encode ke base64 atau pakai WebSocket. Untuk JSON event biasa, SSE lebih dari cukup.

Apakah SSE compatible dengan HTTP/3?

Ya. HTTP/3 (QUIC) bahkan menghilangkan limit 6 koneksi per origin yang ada di HTTP/1.1, jadi SSE makin scalable.

Bagaimana cara handle authentication di SSE?

Karena SSE pakai HTTP biasa, auth pakai cookie session atau JWT di header standar via fetch + ReadableStream. EventSource API native tidak support custom header, jadi sering dibungkus library seperti @microsoft/fetch-event-source untuk akses penuh.

Aksi Praktis

Untuk tim yang sedang merancang fitur real-time, mulai dengan satu pertanyaan: apakah client perlu kirim event balik? Jika tidak, default-nya SSE. Implementasi di Next.js bisa dipasang dalam 1-2 jam, infrastruktur tidak perlu diubah, dan biaya operasional jauh lebih rendah dari WebSocket. Pakai WebSocket hanya saat full-duplex memang dibutuhkan, bukan karena reflex teknologi.