Değeri Yeterince Anlaşılmayan Server-Sent Events (SSE) Teknolojisi

Server-Sent Events (SSE) yeterince değer görmüyor

• Geliştiricilerin çoğu WebSockets'i biliyor, ancak SSE daha basit ve çoğu zaman gözden kaçan bir alternatif.
• SSE, sunucudan istemciye tek yönlü bir iletişim kanalını HTTP üzerinden kurar.
• WebSockets'in çift yönlü bağlantısından farklı olarak SSE, sunucudan istemciye güncellemeler için açık bir HTTP bağlantısını korur.

SSE'nin neden değeri bilinmiyor?

• WebSocket'in popülerliği: WebSockets'in tam çift yönlü iletişim yeteneği, SSE'nin daha basit yaklaşımını gölgede bırakıyor.
• Sınırlamalara dair algı: Tek yönlü yapısı kısıtlayıcı görünebilir, ancak birçok kullanım senaryosu için yeterlidir.

SSE'nin başlıca güçlü yönleri

1. Uygulama kolaylığı

   • Standart HTTP protokolünden yararlanarak WebSocket bağlantı yönetiminin karmaşıklığını ortadan kaldırır.

2. Altyapı uyumluluğu

   • Mevcut HTTP altyapısıyla sorunsuz çalışır:
     • yük dengeleyiciler
     • proxy'ler
     • güvenlik duvarları
     • standart HTTP sunucuları

3. Kaynak verimliliği

   • WebSockets'e kıyasla daha düşük kaynak tüketimi:
     • tek yönlü yapı
     • standart HTTP bağlantısı kullanımı
     • sürekli soket bakımı gerektirmemesi

4. Otomatik yeniden bağlanma

   • Tarayıcının yerleşik desteği sayesinde:
     • bağlantı kesintilerini ele alma
     • otomatik yeniden bağlanma denemeleri
     • dayanıklı bir gerçek zamanlı deneyim

5. Açık anlamsallık

   • Tek yönlü iletişim modeli şunları sağlar:
     • sorumlulukların net ayrımı
     • sezgisel veri akışı
     • sadeleştirilmiş uygulama mantığı

Pratik uygulamalar

• Gerçek zamanlı haber akışları ve sosyal güncellemeler
• Hisse senedi fiyatları ve finansal veriler
• İlerleme çubukları ve iş izleme
• Sunucu loglarının akış halinde iletilmesi
• İşbirlikçi düzenleme (güncellemeler için)
• Oyun liderlik tabloları
• Konum takip sistemleri

Uygulama örneği

Sunucu tarafı (Flask)

• /stream yolu SSE bağlantısını işler.
• generate_random_data() biçimlendirilmiş olayları sürekli olarak üretir.
• text/event-stream MIME türü SSE protokolünü işaret eder.
• stream_with_context, Flask uygulama bağlamını korur.

İstemci tarafı (JavaScript)

• EventSource nesnesi SSE bağlantısını yönetir.
• onmessage işleyicisi alınan olayları işler.
• onerror bağlantı sorunlarını ele alır.
• Tarayıcı otomatik yeniden bağlanmayı yönetir.

Sınırlamalar ve dikkat edilmesi gerekenler

1. Tek yönlü iletişim

   • Yalnızca sunucudan istemciye mümkündür
   • İstemciden sunucuya iletişim için ayrı HTTP istekleri gerekir

2. Tarayıcı desteği

   • Modern tarayıcılarda iyi desteklenir
   • Eski tarayıcılarda polyfill gerekebilir

3. Veri biçimi

   • Esas olarak metin tabanlı verileri destekler
   • İkili veriler için kodlama gerekir (ör. Base64)

En iyi uygulamalar

• Hata yönetimi

  • Bağlantı hatalarını eventSource.onerror ile ele alın.

• Bağlantı yönetimi

  • İş tamamlandığında bağlantıyı temizleyin.

• Yeniden bağlanma stratejisi

  • Maksimum yeniden deneme sayısını belirleyin ve yeniden bağlanma mantığını uygulayın.

Gerçek örnek: ChatGPT'nin uygulaması

• Modern büyük dil modelleri (LLM), akış halinde yanıt sunmak için SSE kullanır.
• Temel desenler:
  • content-type: text/event-stream başlığının döndürülmesi
  • \r\n\r\n ile ayrılmış veri bloklarının akış halinde gönderilmesi

Sonuç

• SSE, gerçek zamanlı sunucu-istemci iletişimi için zarif bir çözüm sunar.
• Basitliği, verimliliği ve mevcut altyapıyla entegrasyonu, onu birçok uygulama için uygun bir seçenek haline getirir.
• WebSockets çift yönlü iletişim için hâlâ yararlı olsa da, SSE tek yönlü veri akışı senaryolarında daha odaklı ve uygun bir çözüm sunar.

[eususu]

OpenAI'yi REST ile uygularken SSE'yi gerçekten kullandım.
Tek yönlü iletişimin gerektiği durumlarda kesinlikle benimseyeceğimi düşünüyorum.

[galadbran]

SSE güvenlik cihazları tarafından (web uygulama güvenlik duvarı ya da akıllı güvenlik gibi) genelde engellenmiyor, ancak satır sonu karakteri bazında streaming'in çalışmadığı durumlarla sık karşılaşıyoruz. Özellikle (on-premise) ortadaki bir katman tüm yanıtı önce alıp sonra tek seferde gönderiyor.

[savvykang]

OpenAPI'nin SSE'yi desteklememesi gerçekten üzücü.

[alska1039]

NAT ortamında çift yönlü iletişim kurmak için gerçekten çok iyi bir yöntem.

[GN⁺]

Hacker News görüşleri

• Mercure, SSE tabanlı açık bir protokoldür ve WebSockets tabanlı çözümlere alternatif olarak kullanılır. Mercure, istemcilerle kalıcı SSE bağlantıları sürdüren bağımsız bir hub etrafında çalışır ve sunucu uygulamaları ile istemcilerin kullanabileceği basit bir HTTP API sunar. Mercure ayrıca JWT tabanlı kimlik doğrulama mekanizması, birden fazla konu için tek bağlantı üzerinden abonelik, olay geçmişi ve ağ sorunları yaşandığında otomatik durum senkronizasyonu gibi özellikler ekler

• SSE'nin büyük dezavantajı, HTTP/2 kullanılmadığında azami bağlantı sayısı sınırının olmasıdır. Bu, tarayıcı başına sınırın düşük olması nedeniyle birden fazla sekme açıldığında sorun yaratabilir

• Doppler'ın CLI'ında otomatik yeniden başlatma özelliğini uygulamak için SSE kullanıldı. SSE üzerinden sunucudan olaylar alınıyor, en güncel gizli bilgiler çekiliyor ve uygulama sürecine enjekte ediliyor. WebSockets yerine SSE seçilmesinin nedeni, Golang uygulamasına ek bağımlılık getirmemekti. HTTP timeout sorununu çözmek için aralıklı olarak "ping" olayları göndermek gerekti

• SSE'nin tek yönlü yapısı sınırlayıcı görünebilir, ancak birçok durumda yeterlidir. SSE'nin başlıca sınırlamaları yalnızca metin desteklemesi ve HTTP/1.1'deki tarayıcı bağlantı sınırıdır. HTTP/2 veya üzeri kullanıldığında bağlantı sınırı sorun olmaz. Performansın kritik olduğu durumlarda, fetch ve ReadableStream kullanılarak daha esnek ve daha az ek yükü olan bir çözüm tercih edilebilir

• SSE'nin sadeliği nedeniyle birçok geliştirici uygun bir implementasyon kullanmak yerine veri parçalarını düzenli ifadelerle ayrıştırıyor. Bu, SSE'nin akış içinde yorum satırlarını desteklemesi nedeniyle sorun yaratabilir

• Data-star.dev, SSE üzerinden hipermedya yanıtlarını stream etmeye odaklanan bir frontend kütüphanesidir. Go ve NATS arka uç teknolojileri kullanılarak geliştirilmiştir ve tüm SSE implementasyonlarıyla uyumludur

• SSE küçümsenen bir teknoloji değil. Hatta Open AI tarafından streaming completion için kullanılıyor. ReactJS kod tabanında SSE'yi uygulamak zordu ve o dönemde Axios bunu desteklemediği için native fetch kullanmak gerekti

• Bir web projesinde SSE uygulandığında, 6'dan fazla sekme açılınca web sitesi çalışmayı durdurdu. Firefox, SSE bağlantılarını host başına 6 azami bağlantı sınırına dahil ediyor ve bu da ek isteklerin engellenmesine yol açıyor

• SSE, düzgün çalıştığında küçümseniyor. Şu anda üzerinde çalışılan projede kimlik doğrulama sorunları ve tüneldeki keep-alive sorunları nedeniyle zorluk yaşanıyor. Bu protokolün sorunu değil, ancak çözüm bulmak zor