Etkinlik fotoğrafı uygulamalarının geliştiricileri, kalabalık mekanlarda tarayıcı yüklemelerini canlı tutmak için artık somut bir kontrol listesine sahip. Tek bir kullanıcı, onlarca cihaz aynı hotspot için yarışırken Wi-Fi'dan hücresel veriye geçiş yapabilir. Bu kılavuz, konuk telefonu kilitlemiş olsa veya ağda aksaklık yaşansa bile, bir fotoğrafın "yükleme tamamlandı" toast bildirimi sonrası kaybolmasını nasıl önleyeceğinizi gösteriyor.

Sıradan yüklemeler düğünlerde ve festivallerde neden başarısız olur?

Bir ofiste dizüstü bilgisayar sabit bir Ethernet bağlantısına bağlıdır ve tek bir kullanıcı "gönder"e tıklar. Bir düğün resepsiyonunda veya müzik festivalinde ise aynı eylem bir dizi sorunu tetikleyebilir: konuk tören salonundan otoparka yürür, yönlendirici (router) yüzlerce telefonun yükü altında ezilir veya telefon Wi-Fi bağlantısını kaybedip hücresel veriye geçer. Tarayıcı her baytı sunucuya aktarmış olabilir ancak sunucu dosyayı henüz depolama birimine kaydetmemiş olabilir. Eğer kullanıcı arayüzü (UI), ilerleme çubuğu %100 olduğunda başarıyı ilan ederse, konuk fotoğrafı silebilir ve organizatörün elinde eksik bir dosya kalabilir.

"Sadece yükle" yaklaşımının gizli maliyeti

Saf bir yaklaşım, yüklemeyi tek bir HTTP POST işlemi olarak ele alır. Bağlantı sabit olduğunda bu yöntem işe yarar, ancak yoğun bir ağda her kesinti tüm dosyanın baştan başlamasına neden olur. Onlarca telefon aynı anda tekrar denediğinde kullanıcılar hayal kırıklığına uğrar ve bant genişliğinde ani dalgalanmalar yaşanır. Dosyayı parçalara (chunks) ayırmak ve her bir parçayı takip etmek karmaşıklığı artırır, ancak bunun karşılığında ağ geçişlerinden etkilenmeyen, öngörülebilir ve düşük maliyetli bir veri aktarımı elde edilir.

Devam ettirilebilir, parçalı bir yükleme sistemi oluşturmak

Aşağıda pratik, adım adım bir yöntem sunulmaktadır.

1. Herhangi bir veri tarayıcıdan çıkmadan önce bir yükleme kimliği (upload ID) oluşturun

Yerel olarak evrensel olarak benzersiz bir tanımlayıcı (UUID) oluşturun ve bunu ilk istek olarak sunucuya gönderin. Sunucu, o kimlik altında bir oturum kaydeder. Tarayıcı daha sonra bir zaman aşımı (timeout) nedeniyle tekrar deneme yaparsa, aynı UUID'yi dahil eder; böylece sunucu oturumu tanıyabilir ve mükerrer bir kayıt oluşmasını önleyebilir. Bu, iş akışını idempotent (aynı isteğin tekrarlanmasının olumsuz bir etki yaratmaması) hale getirir.

2. Dosyayı 5 – 10 MB'lık parçalara bölün

Parça boyutu bir denge meselesidir. Küçük parçalar (1 MB'ın altı), HTTP istek sayısını ve buna bağlı başlık (header) yükünü artırır. Çok büyük parçalar ise herhangi bir kesintiyi maliyetli hale getirir çünkü istemcinin büyük bir parçayı yeniden göndermesi gerekir. Tipik fotoğraflar ve kısa videolar için 5 – 10 MB ideal bir dengedir: her istek, kullanıcı arayüzünü (UI) yanıt verebilir tutacak kadar hızlı tamamlanır, ancak istek sayısı da yönetilebilir düzeyde kalır.

3. Paralel yükleme sayısını sınırlayın

Mobil tarayıcılar birçok bağlantı açabilir, ancak yoğun bir Wi-Fi ağında her ek akış (stream), sınırlı bant genişliği için rekabet eder. İki sabit akış, birbiriyle yarışan sekiz akıştan daha iyidir. Düşük bant genişliği koşullarını tespit etmek ve eşzamanlılığı (concurrency) otomatik olarak azaltmak için navigator.connection API'sini kullanın.

4. Yükleme durumunu IndexedDB'de saklayın

Yükleme kimliğini, halihazırda gönderilmiş olan parçaların listesini ve sunucu tarafından onaylanmış tüm ofsetleri (offsets) tarayıcının IndexedDB'sinde saklayın. Sayfa yenilenirse veya kullanıcı sekmeyi kapatırsa, istemci bir sonraki yüklemede durumu geri yükleyebilir. Kullanıcı sayfayı tekrar açtığında, onlardan aynı dosyayı seçmelerini isteyin; saklanan meta veriler, yüklemenin baştan başlaması yerine son onaylanan parçadan devam etmesini sağlar.

5. Sadece navigator.onLine değil, gerçek ağ değişikliklerini tespit edin

navigator.onLine bayrağı, bağlantı kullanılamaz olsa bile genellikle "çevrimiçi" (online) rapor eder. Bunun yerine, her parça için kısa bir istek zaman aşımı (örneğin 5 saniye) belirleyin. Bir zaman aşımı gerçekleşirse, ağı kesik kabul edin. Bağlantı geri geldiğinde, sunucuya halihazırda sahip olduğu parçaların listesini sorun ve ardından yalnızca eksik parçaları yüklemeye devam edin. Bu, kısa süreli bir kesintiden sonra yinelenen verilerin gönderilmesini önler.

6. Yeniden denemeler için "jitter" ile birlikte "exponential backoff" uygulayın

Birçok konuğun cihazı ağın geri geldiğini fark ettiğinde, hepsi aynı anda yeniden deneme yapabilir ve bu da sunucuyu aşırı yükleyebilir. Exponential backoff (üstel geri çekilme), her yeniden denemenin bir öncekinden daha uzun beklemesini sağlarken, jitter rastgele küçük bir sapma ekler. Bu kombinasyon, yeniden deneme trafiğini birkaç saniyeye yayarak ani bir yükselmeyi önler.

7. Katmanlı ve erişilebilir geri bildirim gösterin

Üç aşamalı bir durum çubuğu, dosyanın gerçek durumunu iletir:

  • Alındı (Received) – sunucu her parçayı depoladı ve dosyayı tamamlandı olarak işaretledi.
  • Hazırlanıyor (Preparing) – sunucu küçük resimler (thumbnails) oluşturuyor veya bir videoyu dönüştürüyor (transcoding).
  • Mevcut (Available) – organizatör dosyayı görüntüleyebilir veya indirebilir.

Sadece renge güvenmekten kaçının; ekran okuyucu kullanıcılarının da ilerlemeyi anlayabilmesi için simgeleri kısa metinlerle eşleştirin.

Neler hâlâ ters gidebilir?

İyi mühendislik ürünü, kaldığı yerden devam edebilen bir yükleme işlemi bile bazı uç durumlarda aksayabilir.

Sırada nelere dikkat edilmeli?

Web platformu gelişmeye devam ediyor.

Özet

Her parçayı takip eden, durumu yerel olarak saklayan ve akıllıca yeniden deneyen, kaldığı yerden devam edebilen ve parçalı (chunked) bir yükleme işlemi; istikrarsız bir etkinlik ağını, konuk fotoğrafları için güvenilir bir kanala dönüştürür. Yukarıdaki kontrol listesini uygulayın.