- Web platformunun standartlaştırılmış API’ler üzerinde her yerde aynı şekilde çalıştığı algısı yaygın olsa da, gerçekte çok sayıda API tarayıcı üreticisine özgü altyapıya bağımlıdır
- Geolocation, Speech, Push, Payments, Passkeys gibi özellikler yüzeyde web standardı gibi görünse de, arka planda Google, Apple ve Microsoft hizmetlerini çağırır
- Aynı API çağrısında bile doğruluk, kullanılabilirlik, bölgesel uyumsuzluk ve gizlilik politikaları tarayıcıya göre büyük farklılık gösterebilir; geliştiriciler ise çoğu zaman bunun farkında olmadan bu altyapılara bağımlı hale gelir
- Büyük üretici merkezli standartlaştırma yapısı, küçük ve orta ölçekli tarayıcılar ile açık kaynak ekosisteminin önüne giriş engeli koyar ve fiili kilitlenme etkisini (lock-in) güçlendirir
- Geliştiriciler bu API’leri saf bir ‘web standardı’ değil, üretici hizmetlerini soyutlayan bir katman olarak görmeli; gizlilik bildirimi, alternatif tasarım ve tarayıcı bazlı testleri birlikte yürütmelidir
Web platformuna dair yaygın algı ve gerçek yapı
- Web platformu, standart spesifikasyonlara dayalı birleşik bir sistem olarak algılanır; aynı motoru kullanan tarayıcılarda aynı davranış beklenir
- Gerçekte ise çok sayıda API, tarayıcıya özgü özel uygulamalara ve üçüncü taraf hizmetlere, kapalı altyapılara, üretici iç sistemlerine dayanır
- Arayüz standartlaştırılmış olsa da uygulama ayrıntıları, tarayıcı üreticisinin tercihine göre ciddi biçimde değişir
Geolocation API ve konum verisinin gerçek kaynağı
- Geolocation API standartlaştırılmış bir arayüz sunar, ancak gerçek konum bilgisi çeşitli yollarla toplanır
- İşletim sistemi konum servisleri ve GPS kullanımı
- Wi-Fi AP bilgilerine dayalı konum tahmini
- IP adresi tabanlı konum veritabanı sorgusu
- Chrome Google Location Services, Safari Apple sunucuları, Firefox ise 2024’ten itibaren Google hizmetlerini kullanır
- Konum bilgisi kullanılırken kullanıcı verileri belirli bir üreticinin sunucusuna gönderiliyor olabilir; ancak bu durum tarayıcı arayüzünde açıkça görünmez
- Belirli bölgelerde üretici hizmetlerine erişim engellenirse özelliğin düzgün çalışmama ihtimali vardır
Speech Synthesis ve ses işleme altyapısı
- Web Speech API içindeki konuşma sentezi, tarayıcıya, işletim sistemine ve cihaza göre farklı motorlar kullanır
- Speech Synthesis API standartlaştırılmış bir arayüzdür, ancak ses verisi işletim sisteminin TTS motorunda veya bulut sunucularında işlenir
- Chrome yerel ve bulut işleme birlikte kullanır, Safari ise işletim sisteminin ses motorunu kullanır
- Bazı yüksek kaliteli sesler, bulut tabanlı işleme için çevrimiçi aktarım gerektirir; bu da kullanıcı verilerinin sunucuya gönderilmesi anlamına gelir
- Kişisel mesajlar veya hassas bilgiler istenmeden harici sunuculara gönderilme riski taşır
- Ayrıca test ortamında seçilen ses, kullanıcının ortamında bulunmayabilir
Speech Recognition ve gerçek zamanlı ses aktarımı
- Speech Recognition API çoğunlukla bulut tabanlı tanıma hizmetlerine bağımlıdır
- Chrome Google’ı, Safari Apple’ı, Edge ise Azure tabanlı hizmetleri kullanır
- Chrome 139’dan itibaren
processLocally seçeneği ile yerel işleme mümkündür; ancak varsayılan değildir ve bu özellik de yalnızca Chrome’a özgüdür
- Doğruluk ve dil desteği, üreticiye ait modellerin kalitesine göre değişir
Passkey’ler ve WebAuthn’in gerçek temeli: tarayıcı ekosistemine bağımlılık
- WebAuthn API, parolasız kimlik doğrulama vaat eder; fakat pratikte tarayıcının parola yöneticisi altyapısına bağımlıdır
- Chrome Google Password Manager’ı, Safari iCloud Keychain’i, Edge ise Microsoft Account’u kullanır
- Polypane gibi araçlar Electron sınırlamaları nedeniyle Passkey desteği sunmaz; bunun için 1Password gibi eklentiler gerekebilir
- Kimlik bilgilerinin saklanması, senkronizasyonu ve kurtarılması tamamen üreticiye özgü uygulamalarla belirlenir
Payment Request API ve ödeme üreticisine bağımlılık
- Payment Request API standart gibi görünür, ancak gerçekte ödemenin çalışıp çalışmayacağı üretici ortaklarına göre değişir
- Chrome Google Pay’i, Safari Apple Pay’i, Edge Microsoft entegrasyonunu kullanır; Firefox ise desteklemez
- Bölgesel destek durumu, kullanıcı deneyimi ve ek kullanıcı ayarı gereksinimleri tarayıcıdan tarayıcıya değişir
- Sonuç olarak her ödeme yöntemi için ayrı sözleşmeler ve özel uyum mantığı gerekir
Push API ve üreticiye özgü bildirim ağları
- Push API bir standarttır, ancak tarayıcıların bildirim iletimi için kullandığı gerçek sunucu altyapısı farklıdır
- Chrome/Edge FCM’yi, Safari APNs’i, Firefox ise Mozilla Push Service’i kullanır
- İletim sınırları, mesaj boyutu, çevrimdışı işleme ve gizlilik politikaları hizmete göre değişir
- Üretici altyapısında yaşanacak kesintiler, ilgili tarayıcıdaki push işlevinin tamamını etkileyebilir
Medya API’leri, codec ve DRM sorunları
- Media Source Extensions(MSE) ve Encrypted Media Extensions(EME) standarttır; ancak destek durumu codec ve DRM lisanslarına göre değişir
- Chrome, Edge ve Firefox Widevine, Safari ise FairPlay kullanır; yani sistem tamamen kapalı teknolojilere dayanır
- Tarayıcı üreticilerinin tercih ettiği codec’ler ve stratejiler farklıdır
- DRM lisans maliyetleri ve teknik kısıtlar nedeniyle küçük tarayıcıların destek sunması zordur
Tarayıcı içi yapay zeka API’lerinin ortaya çıkışı: yeni bir kapalı yapı
- Chrome, Gemini Nano tabanlı AI API’lerini (özetleme, çeviri, düzeltme vb.) deniyor
- Yerelde çalıştığı için veri aktarımı yoktur; ancak model boyutu (yaklaşık 4 GB) ve GPU gereksinimi yüksektir, ayrıca Google’a ait kapalı bir modeldir
- Diğer tarayıcıların kendi modellerini geliştirmesi gerekir; küçük tarayıcılar veya açık kaynak projeleri aynı modeli edinip sürdüremediği için rekabet edemez
- Bu durum, yapay zeka tabanlı yeni bir üretici bağımlılığı yapısı yaratır
Neden önemli
- Taşınabilirlik sorunu: Aynı kod bile tarayıcıya, bölgeye ve ortama göre farklı kalitede çalışabilir
- Gizlilik riski: Ses, konum ve push verileri istenmeden üretici sunucularına gönderilebilir
- Standartlaştırmadaki dengesizlik: Büyük şirketler hem spesifikasyonu hem uygulamayı yönlendirerek kendi altyapılarını fiilen zorunlu hale getirir ve küçük tarayıcıları dışarıda bırakır
- Geliştiricilere etkisi: Özellikler faydalı olsa da, bunların standart değil hizmet bağımlılığı olduğunu bilmek gerekir
Geliştiricilerin benimsemesi gereken yaklaşım
- API’leri üretici hizmetlerini soyutlayan katmanlar olarak görmek ve test, belgelendirme, alternatif akışlar hazırlamak
- Kademeli bozulma (graceful degradation) yaklaşımıyla özellik uyumsuzluklarına hazırlıklı olmak
- Gizlilikte şeffaflık sağlamak: Verilerin üçüncü taraf sunuculara gönderilebileceğini açıkça belirtmek
- Üretici bağımlılığını yönetmek: Hizmet kesintisi veya politika değişikliği durumlarına karşı plan yapmak
- Tarayıcı ve bölge bazlı testlerle kalite farklarını doğrulamak
- Stratejik tercihlerle üretici bağımlılığını mümkün olduğunca azaltmak
Düşündüğümüz web ile gerçek web arasındaki fark
- Standartlaştırılmış API çağrıları aynı görünse de veri akışı, doğruluk, bölgesel destek, gizlilik ve maliyet yapısı tarayıcıya göre değişir
navigator.geolocation.getCurrentPosition() çağrısı gerçekte çoğu zaman Google veya Apple konum hizmetlerini çağırmak anlamına gelir
- Standart spesifikasyonlar yalnızca arayüzü tanımlar; gerçek davranış ise üretici altyapısına ve politikalarına bağımlıdır
- Bir API çağrısı yapmak, fiilen belirli bir üreticinin sunucularını, politikalarını ve iş modelini kullanmak anlamına gelir
- Web platformu güçlüdür; ancak gerçekte daha parçalı ve üretici merkezli bir yapıdadır
- Geliştiriciler tasarım yaparken standart ile uygulama arasındaki sınırı net biçimde anlamalıdır
Henüz yorum yok.