WebTransport Baseline oldu. Fallback'i silmenin tam zamanı mı?
Mart ayında Safari 26.4 ile WebTransport dört büyük tarayıcıda çalışır hâle geldi. Xaron'da WebSocket fallback'ini hiç yazmadık — bu kararın getirisini de bedelini de anlatayım.
Mart 2026'da Safari 26.4 WebTransport'u varsayılan olarak getirdi. Chrome 97'den, Edge 98'den, Firefox 115'ten beri vardı zaten; eksik olan tek büyük tarayıcı Safari'ydi. Bu, WebTransport'un Baseline'a geçtiği an oldu — yani web platformunun "artık her yerde var, üretimde kullanabilirsin" dediği eşik.
Bir API'nin Baseline'a geçmesi teknik bir olay gibi görünür ama aslında ticari bir olaydır. Baseline öncesinde bir yetenek, A/B testi yapıp ölçtüğün bir şeydir. Baseline sonrasında müşteriye söz verebildiğin bir şeye dönüşür. Aradaki fark, yol haritasının yarısı.
Ama Baseline "her yerde çalışır" demek değil
**WebTransport HTTP/3 üzerinden, yani QUIC üzerinden çalışıyor. QUIC ise UDP kullanıyor. Ve bazı kurumsal ağlar, kampüsler, misafir Wi-Fi'ları UDP 443'ü filtreliyor. TCP üzerinden geçen WebSocket'in sorunsuz kurduğu bağlantı, aynı ağda QUIC ile kurulmuyor.
Yani tarayıcı desteği tamam, ağ desteği tam değil. Bu ikisini karıştıran ekipler Baseline haberini okuyup fallback'lerini siliyor ve iki hafta sonra "bazı kullanıcılar bağlanamıyor" biletleriyle uğraşıyor.
Xaron'da fallback yazmadık — bilerek
Xaron'da WebTransport tek realtime taşıma katmanı. WebSocket'e düşen bir yol yok, ve üretim ortamı geçerli bir taşıma sertifikası olmadan hiç açılmıyor.
Bu kararın arkasındaki mantık şu: iki taşıma katmanı demek iki kod yolu, iki hata yüzeyi, iki ayrı güvenlik modeli demek. Ve pratikte olan şey her zaman aynı — fallback varsa, ekip hızlı yolu test etmeyi bırakıyor. Bir süre sonra gerçekten çalışan tek yol yavaş olan oluyor, kimse fark etmiyor.
Yedek yol, yeterince uzun süre yaşarsa asıl yola dönüşür. Sadece kimse bunu yazılı olarak kabul etmez.
Tek taşıma katmanına bağlanmak, o katmanın etrafındaki her şeyi ciddiye almayı zorunlu kıldı. WebTransport API'si tasarım gereği çerez göndermiyor, dolayısıyla oturum doğrulaması için otuz saniye yaşayan tek kullanımlık bir bilet kullanıyoruz. İstemci uç sertifikanın parmak izini sabitliyor. Kullanıcı çıkış yaptığında veya hesabını sildiğinde yalnızca HTTP oturumu değil, canlı bağlantılar da düşüyor. Bunların hiçbiri fallback'li bir mimaride bu kadar net olmazdı, çünkü her davranışı iki kez tarif etmek gerekirdi.
Kimin için doğru karar, kimin için değil
Tüketici ürünündeysen ve kullanıcın oyun oynayan biriyse, bu riski alabilirsin. Bağlanamayan kullanıcının ağı zaten sesli sohbeti de bozuyordur; kaybettiğin oran küçük ve ölçülebilir.
Kurumsal SaaS satıyorsan alamazsın. Müşterinin ağı senin mimari tercihini umursamıyor, sadece ürünün açılmadığını görüyor.
İkisi arasındaki fark bir teknoloji tercihi değil — kimin ağında çalışmak zorunda olduğunla ilgili bir soru. Cevabı bilmeden fallback silinmez.