Şöyle ki, Geçen ay, bir pazartesi sabahı Kadıköy’de kahvemi içerken önümde yine aynı soru belirdi: “Bu canlı güncelleme işi için ne kullanılır?” Hani bazı konular vardır — ilk bakışta çok karışık görünür. Aslında — hayır dur, daha doğrusu mesele baya net çıkar. Server-Sent Events de tam öyle bir şey. Adını ilk duyunca insanın aklına sanki özel bir protokol, ayrı bir dünya geliyor… halbuki işin özü daha sade, çok daha sade.
Ben bu konuyla ilk kez 2019’da İstanbul’da küçük bir e-ticaret paneli kurarken uğraşmıştım. Sipariş durumları ekranda akacak, müşteri sayfayı yenilemeden değişimi görecekti. O gün websocket mi, polling mi diye epey düşündük — saatlerce. Sonra fark ettim ki her problem chat uygulaması değil. Bazen server’ın sadece konuşması yeter.
SSE tam olarak ne işe yarıyor?
Server-Sent Events, en kaba hâliyle, sunucunun istemciye tek yönlü veri göndermesi demek. İstemci bir HTTP bağlantısı açıyor ve o bağlantıyı açık tutuyor; sunucu da hazır oldukça yeni veriyi itiyor. Bu kadar. Bir bakıma kapıyı aralık bırakıp içeriden haber beklemek gibi — ne sihir var ne ekstra karmaşa.
Ne yalan söyleyeyim, Önemli nokta şu: SSE iki taraflı sohbet kurmuyor. Yani client “alo” derken server da “ben de buradayım” deyip sürekli cevap vermeye kalkmıyor. Tek yönlü akış lazım olan işlerde bu baya iş görüyor — sipariş durumu, canlı skor, işlem ilerleme çubuğu, log akışı (ciddiyim). liste uzar gider.
Peki neden?
Bence, Açık konuşayım, ilk duyduğumda ben de “Bu iş polling değil mi zaten?” diye düşündüm. Değilmiş. Polling’de client gidip gidip soruyor; SSE’de ise bağlantı açık kalıyor ve sunucu elindeki bilgiyi uygun anda bırakıyor. Aradaki fark küçük gibi duruyor ama ağ yükünde ve hissedilen gecikmede ciddi fark büyüyor. Ciddi fark.
SSE, sürekli “sor-cevap” yapan sistemlerden çok; arada bir haber düşen ekranlar için ideal bir yöntemdir.
Polling mi, long polling mi, SSE mi?
Bakın şimdi… çoğu ekip bu üçlüyü birbirine karıştırıyor. Normal polling’de istemci örneğin her 5 saniyede bir sunucuya istek atar. İş görür mü? Görür. Ama trafik şişer, gereksiz istekler olur ve kullanıcı tarafında hafif bir gecikme hissi kalır — hissedilir, inanın.
Long polling biraz daha kurnazdır; istemci istek atar, sunucu yeni veri gelene kadar cevabı bekletir, veri gelince döner ve istemci yeniden ister. Döngü var ama daha akıllı yönetiliyor. Yine de yüksek frekansta güncelleme gerekiyorsa iş yorucu olabiliyor, hem sunucu hem de geliştirici açısından.
SSE ise bu ikisinin arasında güzel bir yere oturuyor ama tam aynı şey değil. WebSocket’e kıyasla daha hafif hissedilir — çünkü iki yönlü kanal açmaz, klasik HTTP altyapısıyla çalışır. Tarayıcı desteği gayet iyi seviyededir (söylemesi ayıp) (tabi bazı eski köşelerde dikkat etmek gerekir, her zaman olduğu gibi). Benim test ettiğim birkaç panelde SSE’nin en güzel tarafı şuydu: frontend tarafı gereksiz olay yönetimiyle boğuşmadı.
Kafadaki kısa ayrım
| Yöntem | Nasıl çalışır? | Ne zaman mantıklı? |
|---|---|---|
| Polling | İstemci belirli aralıklarla sorar | Düşük öncelikli güncellemeler |
| Long Polling | Sunucu cevap vermeyi biraz bekletir | Anlık sayılır ama çift yön gerekmezse |
| SSE | Sunucu tek bağlantıdan veri iter | Sürekli akan tek yönlü bildirimler |
| WebSocket | İki taraf da serbestçe konuşur | Sohbet, oyun, ortak çalışma araçları |
Neden herkes WebSocket’e koşmamalı?
Size bir şey söyleyeyim, Bence burada asıl hata şu oluyor: “Canlıysa WebSocket’tir.” Hayır efendim, öyle değil! Eğer ihtiyacın olan şey sadece server’dan client’a bilgi akıtmaksa WebSocket fazla gelebilir — hatta bazen gereksiz karmaşa yaratır, ekibi gereksiz yere yorar.
Bir dakika — bununla bitmedi. Daha fazla bilgi için MSI’nin Küçük Kutusu: Cubi NUC TWG Serisi Ne Vadediyor? yazımıza bakabilirsiniz.
Kendi notlarım arasında Mart 2023’te Ankara’da yaptığım küçük bir dashboard deneyi var. Kurumsal tarafta çalışan bir arkadaşım log ekranını WebSocket ile yapmıştı; sonra fark ettik ki mesajların %90’ı zaten tek yöndeydi ve sistemin yarısı boşuna dönüp duruyordu (evet biraz komikti). SSE’ye geçtiklerinde hem — itiraz edebilirsiniz tabi — kod sadeleşti hem de bakım yükü düştü — bence çok yerinde bir karar —. Epey düştü. Overwatch 2’de Harita Oylaması Değişiyor: Çoğunluk Kazanıyor yazımızda bu konuya da değinmiştik.
E tabi burada dürüst olmak lazım: WebSocket hâlâ çok güçlüdür ve bazı senaryolarda onun yerini hiçbir şey tutmaz. Gerçek zamanlı oyunlar, iki tarafın sürekli konuştuğu uygulamalar… orada SSE çare değil. Extraction 3 geliyor: Netflix’in yeni hamlesi ne anlatıyor? yazımızda bu konuya da değinmiştik.
SSE’nin iyi olduğu yerler
- Sipariş durumu izleme (bu kritik)
- Bildirimin ekrana anlık düşmesi
- Konsol benzeri log akışı
- Puan tablosu ya da canlı sayaçlar
Zayıf kaldığı noktalar
// Tek yönlü olduğu için client'tan server'a interaktif mesaj göndermek için uygun değildir.
// Tarayıcı desteği iyi olsa da mobil webview'lerde ayrıca test gerekir.
// Bağlantı koparsa yeniden bağlanma stratejisini sen tasarlamalısın.
// Tek yönlü olduğu için client'tan server'a interaktif mesaj göndermek için uygun değildir.
// Tarayıcı desteği iyi olsa da mobil webview'lerde ayrıca test gerekir.
// Bağlantı koparsa yeniden bağlanma stratejisini sen tasarlamalısın.
.NET tarafında işler nasıl kuruluyor?
.NET ile çalışırken SSE kurmak sandığınız kadar acayip değil aslında… Hatta doğru kurgulanınca temiz bile duruyor (kendi tecrübem). Bir API endpoint açıyorsunuz, Content-Type başlığını text/event-stream yapıyorsunuz ve yanıtı kapatmıyorsunuz. Ardından belli aralıklarla veriyi yazıp stream’i flush ediyorsunuz. İşte kritik kısım burası — her yazdıktan sonra tamponu boşaltmazsanız istemci o veriyi hemen görmeyebilir. Görmez.
Bi saniye — Bunu geçen sene Eylül ayında İzmir’den gelen bir ekip için denediğimde en büyük sorun timeout olmuştu. Klasik HTTP isteği sanıldığı gibi sonsuza dek açık kalamıyor; proxy katmanı, load balancer, tarayıcı… hepsi devreye girince ince ayar gerekiyor. O yüzden üretimde kalıcı bağlantılar kullanacaksanız altyapınızı bilmeniz şart, gerçekten şart (yanlış duymadınız)
Aşağıdaki örnek kaba ama fikir veriyor:
[HttpGet("order/{orderId}/status")]
public async Task StreamOrderStatus(string orderId, CancellationToken cancellationToken)
{
Response.Headers["Content-Type"] = "text/event-stream";
Response.Headers["Cache-Control"] = "no-cache";
Response.Headers["Connection"] = "keep-alive";
while (!cancellationToken.IsCancellationRequested)
{
var status = await _orderService.GetStatusAsync(orderId);
await Response.WriteAsync($"data: {status}
");
await Response.Body.FlushAsync();
await Task.Delay(3000);
}
}Lafı gevelemeden söyleyeyim: bu örnek öğretici ama üretimde çıplak hâliyle bırakılmaz. Hata yönetimi, yeniden bağlanma mantığı, son gönderilen event id’si, kimlik doğrulama… bunların hepsi düşünülmeli. Yoksa demo güzel görünür ama gerçek hayatta pat diye duvara toslarsınız. Mantıklı değil mi? Güzel bir hızla da.
Küçük startup ile enterprise aynı mı? Hiç değil!
Küçük bir startup için SSE genelde rahatlatıcıdır çünkü ekip azdır ve kimse fazladan servis zinciri kurmak istemez. Bir ürün takımının elinde yalnızca sipariş statüsü ya da basit bildirimler varsa SSE gayet yeterli (inanın bana). Az parça, az hareket, az sürpriz…
Muhatap kurumsal ölçek olunca tablo değişiyor. Binlerce eşzamanlı bağlantı varsa connection yönetimi önem kazanıyor — reverse proxy ayarları, idle timeout değerleri, uygulama sunucusunun kaynak kullanımı… hepsi inceleniyor. Açıkçası burada SSE kağıt üstünde tatlı görünse de pratikte sınav başlıyor. Bu ne anlama geliyor? Ağır bir sınav.
İşte tam da bu noktada devreye giriyor.
Bana göre seçim rehberi şöyle:
- Eğer sadece ekrana akan bilgi gerekiyorsa önce SSE düşünün.
- Eğer karşılıklı etkileşim ağır basıyorsa WebSocket’e bakın. — bunu es geçmeyin
- Eğer sistem basitse polling hâlâ işinizi görebilir.
Aslında, Şunu da söylemeden geçmeyeyim: bazen mühendislik kararları teknikten çok operasyoneldir. Takımdaki insanlar hangi teknolojiyi daha iyi biliyor? Mevcut platform nereye izin veriyor? CDN ya da proxy katmanı uzun yaşayan bağlantıları seviyor mu? Bu sorulara cevap vermeden teknoloji seçmek bana hep yarım kalmış gelir — ciddi ciddi yarım. Lenovo’nun Yeni Oyun Tableti Sürprizi: Neler Değişiyor? yazımızda da bu konuya değinmiştik. Artemis II Dönüşü: NASA’nın Deniz İnişi Nasıl İzlenir? yazımızda da bu konuya değinmiştik.
Peki kullanıcı deneyimine etkisi ne oluyor?
Kullanıcının hissettiği şey çoğu zaman teknik ayrıntılardan bağımsızdır. Ekrandaki durum anında değişiyorsa sistem “canlı” görünür. Ben bunu ilk kez eski (belki yanılıyorum ama) bir lojistik panelinde net biçimde gördüm — sipariş hazırlanıyor, yola çıktı, dağıtımda (yanlış duymadınız). Kullanıcı sayfayı yenilemek zorunda kalmayınca destek talepleri bile azalmıştı (en azından benim deneyimim böyle). Ufak gibi duran farkların etkisi bazen baya büyük olur. Gerçekten büyük.
Düşünsenize… Her aşamada push notification atsanız kullanıcıyı bunaltırsınız; hiçbir şey göstermeseniz belirsizlik olur; polling’i fazla sık yapsanız ağ yorulur; az sık yapsanız gecikme artar (evet, doğru duydunuz). SSE tam ortada makul kalan çözümlerden biri oluyor yani… Ama yine de bağlama göre değerlendirmek lazım.
SSE kullanırken dikkat etmem gerekenler neler?
Garip gelecek ama, SSE hoş görünüyor ama her güzel teknolojide olduğu gibi birkaç pürüz var. Önce timeout meselesi gelir; sonra proxy ayarı; arkasından reconnect davranışı… Bunları atlayınca test ortamında çalışan şey prod ortamda garip garip davranmaya başlar. Garip de değil aslında, gayet mantıklı bir sebepten (en azından benim deneyimim böyle)
Geçen yıl Kasım’da bunu birebir yaşadım: lokalde taş gibi çalışan stream, kurumsal ağda otuz saniyede düşmeye başladı. Sebep? Aradaki cihaz bağlantıyı boş sanıp kapatıyormuş. Saatlerce baktık.
Vallahi, Şu ufak detaya bakın: başka noktalar da var: mesaj formatının doğru olması, UTF-8 karakterlerin düzgün aktarılması, event boyutunun kontrolden çıkmaması… ve tabii güvenlik kısmı. Kimlik doğrulama açık bırakılırsa canlı akış kanalı kötüye kullanılabilir — bu kısmı es geçmeyin lütfen.
Sıkça Sorulan Sorular
SSE ile WebSocket arasındaki temel fark nedir?
”
SSE tek yönlüdür; server client’a veri gönderir.Robust chat ya da karşılıklı mesajlaşma gerekiyorsa WebSocket daha uygundur.Sadece bildirim ya da durum akışı istiyorsanız SSE genelde daha sade çözüm olur.”
SSE tarayıcıda otomatik yeniden bağlanır mı?
”
Evet,Döngünün kopması halinde EventSource çoğu modern tarayıcıda yeniden bağlanmayı dener.Ama yine de retry süresini ve kesinti senaryolarını sizin test etmeniz gerekir.
.NET’te SSE performansı iyi mi?”
Evet,ihtiyaç doğruysa gayet iş görür.Aynı anda çok fazla uzun yaşayan bağlantıda kaynak tüketimini ölçmek şarttır.Yani küçük projede rahat,koca platformda planlı olmak lazım.
SSE hangi projelerde tercih edilmeli?
”
Anlık sipariş takibi,bildirim panelleri,sade dashboard’lar ve log ekranları için mantıklıdır.Kullanıcıyla çift yönlü yoğun etkileşim yoksa uğraşmadan kullanılabilir.
Kaynaklar ve İleri Okuma”MDN — Server-Sent Events Rehberi
WHATWG HTML Standard — Server-sent events bölümüg;
<>a href =”https://learn.microsoft.com/en-us/aspnet/core/fundamentals/servers/kestrel?view=aspnetcore-9.0″ target =”_blank” rel =”noopener”>Microsoft Learn — ASP.NET Core and Kestrel Documentation’
<>a href =”https://learn.microsoft.com/en-us/aspnet/core/fundamentals/servers/kestrel?view=aspnetcore-9.0″ target =”_blank” rel =”noopener”>Microsoft Learn — ASP.NET Core and Kestrel Documentation’
20+ yıl deneyimli Azure Solutions Architect. Microsoft sertifikalı bulut mimari ve DevOps danışmanı. Azure, yapay zekâ ve bulut teknolojileri üzerine Türkçe teknik içerikler üretiyor.
İlgili Yazılar
Bu içerik işinize yaradı mı?
Benzer içerikleri kaçırmamak için beni sosyal medyada takip edin.
