# WebSocket Her Sorunun Cevabı Değil: Polling, SSE ve Gerçek Zamanlı Veri

Canonical: https://kaantanis.com/bloglar/javascript/websocket-her-sorunun-cevabi-degil-polling-sse-ve-gercek-zamanli-veri

Yayın tarihi: 2026-10-05

Etiketler: JavaScript

Yazar: Kaan Tanış

Bir sayfanın veriyi yenilemeden güncellemesi gerektiğinde çoğu kişinin aklına doğrudan WebSocket geliyor. Sipariş durumu değişecek, bildirim düşecek, yönetim paneli canlı kalacak. Hemen bir socket bağlantısı açılıyor.Bazen doğru karar bu. Bazen de beş saniyede bir çalışan basit bir istek aynı işi daha az uğraşla çözüyor. Gerçek zamanlı veri tek bir teknoloji demek değil. İhtiyaca göre polling, Server-Sent Events (SSE) veya WebSocket seçebilirsiniz.Önce veri akışını tanımlayınKarar vermeden önce şu soruyu sorun: Mesajı kim gönderiyor?Tarayıcı arada bir sunucuya soracaksa polling yeterli olabilir.Sunucu tarayıcıya sürekli bilgi gönderecek, kullanıcı cevap vermeyecekse SSE daha sade bir seçenek olabilir.Tarayıcı ile sunucu iki taraflı ve anlık konuşacaksa WebSocket gerekir.Sunucu tek yönlü konuşacaksa WebSocket açmak zorunda değilsiniz.Bu ayrım küçük görünüyor ama bağlantının kurulması, yetkilendirilmesi, kopunca yeniden açılması ve sunucuda izlenmesi gereken işleri doğrudan değiştiriyor.Polling: Sıkıcı ama çoğu zaman yeterliPolling, tarayıcının belirli aralıklarla aynı endpoint'e istek atıp güncel durumu sormasıdır. Siparişin hazırlanıp hazırlanmadığını, bir export işleminin bitip bitmediğini veya bir admin panelindeki sayacın değişip değişmediğini göstermek için genellikle yeterlidir.Beş saniyelik gecikme kullanıcı için sorun değilse, sürekli açık bağlantı kurmanın anlamı azalır. Üstelik hata ayıklaması da kolaydır. İstek gider, cevap gelir, logda görünür. Socket'in nerede koptuğunu aramazsınız.let timer;
let requestInProgress = false;

async function refreshStatus() {
 if (requestInProgress) {
 return;
 }

 requestInProgress = true;

 try {
 const response = await fetch('/api/orders/123/status', {
 headers: {
 Accept: 'application/json',
 },
 });

 if (!response.ok) {
 throw new Error('Durum alınamadı');
 }

 const data = await response.json();
 renderStatus(data.status);
 } catch (error) {
 console.error(error);
 } finally {
 requestInProgress = false;
 }
}

refreshStatus();
timer = window.setInterval(refreshStatus, 5000);

window.addEventListener('pagehide', () => {
 window.clearInterval(timer);
});Buradaki requestInProgress kontrolü önemli. Sunucu yavaşladığında yeni istekler üst üste binmesin. Bir de kullanıcı sayfadan ayrıldığında interval'i kapatın. Küçük ayrıntı, ama açık sekme sayısı arttıkça gereksiz yük birikir.Laravel tarafında polling için çoğu zaman normal bir JSON endpoint'i yeterlidir:use App\Models\Order;
use Illuminate\Support\Facades\Route;

Route::get('/api/orders/{order}/status', function (Order $order) {
 return response()->json([
 'status' => $order->status,
 ]);
});Burada WebSocket paketi kurmadınız, worker çalıştırmadınız, bağlantı yaşam döngüsü yönetmediniz. İhtiyaç buysa bu bir eksik değil. Daha küçük bir çözüm seçtiniz.SSE: Sunucu konuşsun, tarayıcı dinlesinServer-Sent Events, sunucunun tarayıcıya açık bir HTTP bağlantısı üzerinden olay göndermesidir. İletişim tek yönlüdür. Tarayıcı bir şey göndermez, sadece akışı dinler.Canlı log akışı, uzun süren bir işlemin ilerleme durumu, bildirim listesi veya yönetim panelindeki sistem mesajları SSE için iyi örneklerdir. Kullanıcı sohbet mesajı yazıp sunucuya aynı kanal üzerinden gönderecekse SSE tek başına yetmez.const events = new EventSource('/orders/123/events');

events.addEventListener('status', (event) => {
 const data = JSON.parse(event.data);
 renderStatus(data.status);
});

events.addEventListener('error', () => {
 console.log('SSE bağlantısı koptu. Tarayıcı yeniden deneyecek.');
});

window.addEventListener('pagehide', () => {
 events.close();
});SSE'nin güzel tarafı tarayıcı API'sinin sade olmasıdır. Bağlantı koparsa tarayıcı yeniden bağlanmayı da dener. Yine de bunu sihirli bir garanti gibi görmeyin. Kimlik doğrulama, yetki kontrolü, proxy zaman aşımı ve Nginx'in response buffering ayarı sunucuda hâlâ sizin işinizdir.Akışın gerçekten parça parça istemciye ulaştığını da kontrol edin. Uygulama olayları üretiyor olabilir, fakat aradaki proxy bütün cevabı biriktiriyorsa kullanıcı güncellemeleri en sonda görür.WebSocket: İki taraf da konuşacaksaWebSocket, bağlantı kurulduktan sonra tarayıcı ile sunucunun iki yönde de mesaj gönderebilmesini sağlar. Chat, çevrim içi kullanıcı durumu, ortak düzenleme ekranları ve anlık teklif veya oyun akışları bu modele daha yakındır.const socket = new WebSocket('wss://example.com/socket');

socket.addEventListener('open', () => {
 socket.send(JSON.stringify({
 type: 'subscribe',
 channel: 'orders',
 }));
});

socket.addEventListener('message', (event) => {
 const message = JSON.parse(event.data);

 if (message.type === 'order.updated') {
 renderStatus(message.status);
 }
});

socket.addEventListener('close', (event) => {
 console.log('Bağlantı kapandı', event.code);
});Bu örnek bağlantının açıldığını ve mesaj aldığını gösteriyor. Üretimde bundan fazlası gerekir: yeniden bağlanma stratejisi, artan bekleme süresi, bağlantı kimliği, yetkilendirme ve aynı mesajın iki kez işlenmesine karşı koruma.Özellikle yeniden bağlanma konusu gözden kaçıyor. Kullanıcının interneti iki saniye kesildiğinde socket geri gelebilir, fakat o arada gönderilen mesajları kaçırmış olabilirsiniz. Sunucu son durumu tekrar göndermeli ya da istemci eksik mesajları isteyebilmelidir. Sadece onclose içine tekrar new WebSocket() yazmak çözüm değil, sonsuz bağlantı döngüsüdür.Laravel projesinde hangisi mantıklı?Laravel kullanıyorsanız framework seçimi bu kararı ortadan kaldırmıyor. Broadcast sistemi veya WebSocket sunucusu kurmadan önce verinin nasıl aktığını netleştirin.Bir siparişin durumunu birkaç saniye gecikmeyle göstermek için polling yeterli olabilir.Uzun süren bir raporun ilerlemesini kullanıcıya akıtmak için SSE daha sade olabilir.Mesajlaşma, typing göstergesi veya çevrim içi durumu için WebSocket daha uygun olur.Laravel tarafında bir çözümün popüler olması, her ekranda kullanılacağı anlamına gelmiyor. Bir admin panelinde iki saniyede bir JSON isteği atmak, sadece teknoloji daha havalı görünsün diye WebSocket işletmekten daha doğru olabilir.Karar vermeden önce kontrol edinGüncelleme gecikmesi gerçekten kaç saniye olabilir?İletişim tek yönlü mü, iki yönlü mü?Açık sekme sayısı arttığında sunucu hangi yükü taşıyacak?Bağlantı koparsa istemci ne yapacak?Mesaj iki kere gelirse uygulama bozulacak mı?Yetkisiz bir kullanıcı başka bir kanalın verisini dinleyebilir mi?Proxy, Nginx ve load balancer uzun bağlantıları destekliyor mu?Bu soruların cevabı yoksa teknoloji seçimi için erken. Önce akışın kendisini tarif edin, sonra bağlantı yöntemini seçin.Kısa cevapPolling en basit seçenektir ve küçümsenmemeli. SSE, sunucudan tarayıcıya akan tek yönlü veride temiz bir ara çözümdür. WebSocket ise gerçekten iki taraflı ve anlık iletişim gerektiğinde anlam kazanır.WebSocket kullanmak zor değil. Zor olan, ona gerçekten ihtiyaç olup olmadığını dürüstçe söylemek. Çoğu projede ilk doğru karar en karmaşık olan değil, yeterli olan çözüm çıkıyor.