Teknologi Server-Sent Events (SSE) yang Diremehkan

Server-Sent Events (SSE) diremehkan

• Sebagian besar developer mengenal WebSockets, tetapi SSE adalah alternatif yang lebih sederhana dan sering kali terabaikan.
• SSE membangun kanal komunikasi satu arah dari server ke klien melalui HTTP.
• Berbeda dari koneksi dua arah WebSockets, SSE mempertahankan koneksi HTTP terbuka untuk pembaruan dari server ke klien.

Mengapa SSE diremehkan

• Popularitas WebSocket: Kemampuan komunikasi full-duplex WebSockets menutupi pendekatan SSE yang lebih sederhana.
• Persepsi terhadap keterbatasan: Sifat satu arahnya bisa terlihat membatasi, tetapi sudah memadai untuk banyak kasus penggunaan.

Kekuatan utama SSE

1. Kesederhanaan implementasi

   • Memanfaatkan protokol HTTP standar sehingga menghilangkan kompleksitas pengelolaan koneksi WebSocket.

2. Kompatibilitas infrastruktur

   • Bekerja mulus dengan infrastruktur HTTP yang sudah ada:
     • load balancer
     • proxy
     • firewall
     • server HTTP standar

3. Efisiensi sumber daya

   • Konsumsi sumber daya lebih rendah dibanding WebSockets:
     • sifat satu arah
     • menggunakan koneksi HTTP standar
     • tidak perlu pemeliharaan socket terus-menerus

4. Penyambungan ulang otomatis

   • Dukungan bawaan browser:
     • menangani putusnya koneksi
     • mencoba reconnect otomatis
     • pengalaman real-time yang tangguh

5. Semantik yang jelas

   • Pola komunikasi satu arah memastikan:
     • pemisahan concern yang jelas
     • aliran data yang intuitif
     • logika aplikasi yang disederhanakan

Aplikasi praktis

• feed berita real-time dan pembaruan sosial
• harga saham dan data finansial
• progress bar dan pemantauan pekerjaan
• streaming log server
• editing kolaboratif (untuk pembaruan)
• leaderboard game
• sistem pelacakan lokasi

Contoh implementasi

Sisi server (Flask)

• Rute /stream menangani koneksi SSE.
• generate_random_data() terus menghasilkan event yang telah diformat.
• Tipe MIME text/event-stream menandakan protokol SSE.
• stream_with_context mempertahankan konteks aplikasi Flask.

Sisi klien (JavaScript)

• Objek EventSource mengelola koneksi SSE.
• Handler onmessage memproses event yang diterima.
• onerror menangani masalah koneksi.
• Browser menangani reconnect otomatis.

Keterbatasan dan hal yang perlu dipertimbangkan

1. Komunikasi satu arah

   • Hanya dimungkinkan dari server ke klien
   • Komunikasi dari klien ke server memerlukan request HTTP terpisah

2. Dukungan browser

   • Didukung dengan baik di browser modern
   • Browser lama mungkin memerlukan polyfill

3. Format data

   • Terutama mendukung data berbasis teks
   • Data biner perlu encoding (misalnya: Base64)

Praktik terbaik

• Penanganan error

  • Tangani error koneksi dengan eventSource.onerror.

• Manajemen koneksi

  • Bersihkan koneksi saat selesai.

• Strategi reconnect

  • Tetapkan jumlah percobaan ulang maksimum dan implementasikan logika reconnect.

Contoh nyata: implementasi ChatGPT

• Model bahasa besar (LLM) modern menggunakan SSE untuk menyediakan respons streaming.
• Pola utama:
  • mengembalikan header content-type: text/event-stream
  • streaming blok data yang dipisahkan dengan \r\n\r\n

Kesimpulan

• SSE menawarkan solusi yang elegan untuk komunikasi real-time server-klien.
• Kesederhanaan, efisiensi, dan integrasinya dengan infrastruktur yang sudah ada menjadikannya pilihan yang cocok untuk banyak aplikasi.
• WebSockets tetap berguna untuk komunikasi dua arah, tetapi SSE memberikan solusi yang lebih terfokus dan tepat untuk skenario streaming data satu arah.

[eususu]

Saya benar-benar menggunakan SSE saat mengimplementasikan OpenAI dengan REST.
Saya pasti akan mengadopsinya dalam situasi yang memerlukan komunikasi satu arah.

[galadbran]

SSE biasanya tidak diblokir oleh perangkat keamanan (seperti web application firewall atau keamanan cerdas), tetapi saya cukup sering menemui kasus di mana streaming per karakter baris baru tidak berjalan. Misalnya, di tengah (on-premise) respons diterima penuh terlebih dahulu lalu dikirim sekaligus.

[savvykang]

Sayang sekali OpenAPI tidak mendukung SSE.

[alska1039]

Ini benar-benar cara yang sangat bagus untuk membangun komunikasi dua arah di lingkungan NAT.

[GN⁺]

Komentar Hacker News

• Mercure adalah protokol terbuka berbasis SSE yang digunakan sebagai alternatif solusi berbasis WebSockets. Mercure bekerja dengan berpusat pada hub independen yang mempertahankan koneksi SSE berkelanjutan dengan klien, serta menyediakan HTTP API sederhana yang dapat digunakan oleh aplikasi server dan klien. Mercure menambahkan fitur seperti mekanisme autentikasi berbasis JWT, langganan banyak topik dalam satu koneksi, pencatatan event, dan penyesuaian status otomatis saat terjadi masalah jaringan

• Kekurangan besar SSE adalah adanya batas jumlah koneksi maksimum jika tidak menggunakan HTTP/2. Ini bisa menjadi masalah saat membuka banyak tab karena batas per browser cukup rendah

• Di CLI Doppler, SSE digunakan untuk mengimplementasikan fitur restart otomatis. Melalui SSE, event diterima dari server, lalu secret terbaru diambil dan disuntikkan ke proses aplikasi. Alasan memilih SSE alih-alih WebSockets adalah agar tidak menambah dependensi tambahan pada aplikasi Golang. Untuk mengatasi masalah HTTP timeout, perlu mengirim event "ping" secara berkala

• Sifat satu arah SSE mungkin terlihat membatasi, tetapi dalam banyak kasus itu sudah cukup. Keterbatasan utama SSE adalah hanya mendukung teks dan adanya batas koneksi browser pada HTTP/1.1. Jika menggunakan HTTP/2 atau lebih tinggi, batas koneksi tidak lagi menjadi masalah. Jika performa penting, bisa memilih solusi yang lebih fleksibel dan dengan overhead lebih rendah menggunakan fetch dan ReadableStream

• Karena kesederhanaan SSE, banyak developer tidak menggunakan implementasi yang tepat dan malah mem-parsing potongan data dengan regular expression. Ini bisa menimbulkan masalah karena SSE mendukung komentar di dalam stream

• Data-star.dev adalah library frontend yang berfokus pada streaming respons hypermedia melalui SSE. Library ini dikembangkan menggunakan Go dan NATS sebagai teknologi backend, serta kompatibel dengan semua implementasi SSE

• SSE tidak diremehkan. Faktanya, SSE digunakan di Open AI untuk streaming completion. Mengimplementasikan SSE di codebase ReactJS cukup sulit, dan pada saat itu Axios tidak mendukungnya sehingga harus menggunakan fetch bawaan

• Saat mengimplementasikan SSE di proyek web, ketika lebih dari 6 tab dibuka, situs web berhenti berfungsi. Firefox menghitung koneksi SSE ke dalam batas maksimum 6 koneksi per host, sehingga permintaan tambahan menjadi terblokir

• SSE diremehkan saat berfungsi dengan baik. Dalam proyek yang sedang dikerjakan saat ini, ada kesulitan karena masalah autentikasi dan masalah keep-alive pada tunnel. Ini bukan masalah protokolnya, tetapi sulit menemukan solusinya