ToolBox Image — ToolBox Image'i neden tamamen tarayıcınızda çalışacak şekilde oluşturduk

Çoğu ücretsiz çevrimiçi görüntü aracı aynı şekilde çalışır: bir dosyayı sunucularına yüklersiniz, sunucu işler ve sonucu indirirsiniz. Bu model oluşturması basittir, ancak gizli maliyetleri vardır — gizliliğiniz, sunucu faturaları ve dosya boyutu ile işleme hızı sınırlamaları.

ToolBox Image farklı bir yaklaşım benimsiyor. Tüm uygulama — kod çözme, kodlama, sıkıştırma, yeniden boyutlandırma, biçim dönüştürme — tarayıcınızda çalışır. Yüklenecek bir sunucu yoktur. Görüntüleriniz cihazınızdan asla ayrılmaz. Bu mimari bilinçli bir seçimdi ve ürün hakkında verdiğimiz her kararı şekillendirdi.

Neden tarayıcı öncelikli yaklaşım?

Açık alternatif geleneksel sunucu tarafı mimarisidir. Bir görüntü yüklersiniz, sunucu ImageMagick veya Sharp gibi bir araçla işler ve sonucu geri gönderir. Bu işe yarar, ancak çözülmesi zor bir dizi sorun yaratır:

• Gizlilik. Kullanıcılar, görüntülerini saklamayacağınıza, analiz etmeyeceğinize veya sızdırmayacağınıza güvenmek zorundadır. Hassas belgeler için — tıbbi görüntüler, tasarım maketleri, kişisel fotoğraflar — bu güveni kazanmak zordur.
• Maliyet. Her sıkıştırma sizin altyapınızda çalışır. Ne kadar başarılı olursanız, o kadar çok ödersiniz. Bu, dosya boyutlarını sınırlama, kuyruklar ekleme veya ücretli seviyeler oluşturma baskısı yaratır.
• Gecikme. Yavaş bir bağlantı üzerinden 100 MB dosya yüklemek, işlem başlamadan dakikalar alır. Kötü bağlantısı olan bölgelerdeki kullanıcılar için araç etkili bir şekilde kullanılamaz.
• Ölçek. Tek bir sunucu düzinelerce eşzamanlı sıkıştırmayı işleyebilir. Peki ya binlerce? Otomatik ölçekleme grupları, yük dengeleyiciler, CDN yükleme uç noktaları gerekir — bunların tümü karmaşıklık ve maliyet ekler.

Tarayıcı öncelikli model tüm bunları tek seferde çözer. İşlem ücretsizdir (kullanıcının CPU döngüleri), özeldir (cihazdan veri çıkmaz) ve sonsuz ölçeklenebilirdir (her kullanıcı kendi donanımını getirir).

Nasıl çalışır: WebAssembly ve Web Workers

On yıl önce, tarayıcıda görüntü codec'leri çalıştırmak imkansızdı. Bugün, WebAssembly C ve Rust kütüphanelerini doğrudan tarayıcının neredeyse yerel hızda çalıştırabileceği bir formatta derlememize olanak tanır. Mozilla'nın mozJPEG'ini, Google'ın libwebp'ini ve libaom AVIF kodlayıcısını — tamamı C ile yazılmış — WebAssembly'ye derliyoruz. Tarayıcı, sanki yerel olarak yüklenmiş gibi verimli bir şekilde çalıştırır.

Ancak tek iş parçacıklı kodlama büyük gruplar için yavaştır. İşte burada Web Workers devreye girer. Her worker ayrı bir CPU çekirdeğinde çalışır ve cihazın sahip olduğu çekirdek sayısı kadar worker oluştururuz. 8 çekirdekli modern bir dizüstü bilgisayarda bu, 8 görüntünün aynı anda sıkıştırılması anlamına gelir. Tek bir iş parçacığında dakikalar sürecek 200 fotoğraflık bir grup saniyeler içinde tamamlanır.

Nelerden vazgeçtik

Tarayıcı öncelikli yaklaşım bedava değildir. En önemli ödünleşim bellektir. Tarayıcı sekmesi cihazın RAM'ine erişebilir, ancak bir görüntünün mevcut belleği aşması nedeniyle tek bir sekmenin çökmesi kötü bir deneyimdir. Güvenli sınırlar içinde kalmak için bireysel dosyaları 100 MB ve grup boyutlarını 200 dosya ile sınırlıyoruz.

Ayrıca kalıcı depolama, e-posta teslimatı ve analitik gibi sunucu tarafı özelliklerinden de vazgeçtik. Sıkıştırılmış görüntü veritabanı, e-posta bülteni veya kullanıcıların hangi biçimleri tercih ettiğine dair kayıt yoktur. Bu, gizlilik duruşumuzla felsefi olarak tutarlıdır, ancak "son sıkıştırmalar" veya "oturumlar arasında kaydedilmiş ön ayarlar" gibi özellikler sunamayacağımız anlamına gelir.

Sırada ne var

Tarayıcı, performansa duyarlı uygulamalar için meşru bir çalışma zamanı haline geliyor. WebAssembly çöp toplama, iş parçacığı ve SIMD desteği kazandıkça, uygulama yığınının daha fazla kısmı istemci tarafına taşınabilir. Daha hızlı piksel işleme için WebGPU ve sorunsuz klasör entegrasyonu için File System Access API'sini araştırıyoruz.

Şimdilik, sıkıştırıcı canlı ve günde binlerce görüntü işliyor — hepsi ait oldukları yerde kalıyor.