WebAssembly Kullanım Alanları: Tarayıcı, WASI Sunucu ve Edge Compute

WebAssembly konuşmaları sürekli birbirini ıskalıyor; çünkü tek bir kelime üç çok farklı mimari bahsi örtüyor. Frontend geliştirici “web’i hızlandırır” diye düşünüyor, backend geliştirici “container’ların yerine geçer” diye okuyor, platform geliştirici “edge’i çalıştırır” diye varsayıyor ve üçü de kısmen haklı. Tek bir runtime’ı değerlendirmeden önce problemini bu üçünden birine oturt; hiçbiri mevcut mimarini tarif etmiyorsa dürüst cevap Wasm’i şimdilik ertelemek.

30 Saniyede WASM

Tek bytecode, üç ayrı bahis: tarayıcıda performans, sunucuda WASI runtime, edge’de compute. Her biri farklı bir soruya cevap veriyor.

Rust, C, C++, Go, AssemblyScript ve Zig gibi kaynak diller ikili bir talimat formatına derleniyor: .wasm dosyası. Bu bytecode stack tabanlı, bellek güvenli, varsayılan olarak sandbox’lanmış ve neredeyse yerel hıza yakın çalışacak şekilde tasarlanmış. Hangi host üstünde çalışacağı onun umurunda değil. Host’tan bağımsızlık zaten olayın kendisi; hangi host’u seçtiğin de sonraki her kararı belirliyor.

Bahis 1: Tarayıcıda Performans

Tarayıcı bahsinin cevapladığı soru net: JavaScript bu CPU yoğun iş için yeterince hızlı değil; mevcut C++ veya Rust kod tabanını tarayıcıya taşıyabilir miyim? Cevap evet ve 2017’den beri evet.

Üç somut örnek bu bahsi gerçek kılıyor. Figma, 2017’de WebAssembly’i devreye aldı ve editör yüklenme süresini yaklaşık 3× kısalttığını raporladı; C++ render motorunu derleyip tarayıcı içinde çalıştırdılar. Google Earth, 3D render’ını ve coğrafi matematik işlerini Wasm’e taşıyarak masaüstü deneyimini web’e getirdi. Photoshop Web, Adobe ile Chrome ekibinin yıllara yayılan ortak çalışmasının ürünü; Photoshop’un C++ çekirdeği Emscripten üstünden derleniyor ve 2021’de herkese açık web betası yayınlandı.

Adlandırmaya değer sınır: Wasm’in doğrudan DOM erişimi yok. Wasm kodu bir DOM düğümüne, bir özelliğe veya bir event’e her uzandığında çağrı bir JavaScript ↔ Wasm köprüsünden geçiyor. Bu köprü bedava değil; “JavaScript yerine Wasm kullanalım” yanlış zihinsel modeli bu yüzden. Wasm uygulamanın içindeki hesaplama için; arayüz hâlâ JavaScript’in alanı.

Tarayıcı bahsi üçü içinde en olgunu ve dört büyük tarayıcının hepsi destekliyor. Açık tasarım soruları Emscripten, bellek düzeni ve SharedArrayBuffer üstünden çoklu thread etrafında dönüyor. Platformun kendisi oturmuş durumda.

Bahis 2: Sunucuda Runtime (WASI)

Sunucu bahsi farklı bir soruyu cevaplıyor: Tam bir container açmadan, Docker’ın sunduğundan daha küçük bir sandbox ve daha hızlı soğuk başlangıçlarla izole, çok dilli iş yüklerini çalıştırabilir miyim? Cevap “evet, ama ekosistem container’lardan daha genç.”

Bir kere tanıtıp geçmek gereken terimler. WASI (WebAssembly System Interface), Wasm kodunun altındaki OS’u umursamadan dosyalarla, saatlerle, soket’lerle ve ortam değişkenleriyle konuşmasını sağlayan standart yüzey. İki aktif sürümü var. Preview 1, hâlâ yaygın kullanılan eski POSIX’e yakın API. Preview 2, 25 Ocak 2024’te yayınlandı; Component Model üstüne yeniden inşa edildi ve WASI’yi syscall’lar yerine tiplenmiş arayüzler kümesi olarak yeniden düşünüyor. Preview 3 (WASI 0.3) Wasmtime üstünde çoktan release-candidate aşamasında; async desteği ve yerel thread’ler kapsamda, 1.0 kesimi 2026 sonu ile 2027 başı arasında bekleniyor.

Sunucu tarafı ekosisteminde üç referans nokta var. Wasmtime, referans runtime; Bytecode Alliance tarafından yürütülüyor ve Cranelift kod üreteci üstünde çalışıyor. Wasmer, kendi paketleme ve dağıtım modelini taşıyan alternatif bir runtime. wasmCloud, Wasm bileşenleri ve NATS mesajlaşması üstüne kurulu daha üst seviye bir platform. wasmCloud ve NATS etrafındaki bileşen-taşınabilirliği tezine daha derin bir bakış için wasmCloud + NATS: bir event-bus taşınabilirlik bahsi yazısına bakabilirsin.

Hesaba katılması gereken kısıt: Component Model hâlâ stabilize oluyor. Preview 2 stabil kilometre taşı; Preview 3 ise Wasmtime’da release-candidate aşamasında. Solomon Hykes’ın 2019’da, WASM ile WASI 2008’de var olsaydı Docker’a ihtiyaç kalmayacağı yönündeki yorumu güzel bir uzun vadeli çerçeve ama 2026 için hâlâ bir vizyon ifadesi. Kütüphane kapsamı, dil desteği ve araç zinciri runtime’a göre değiştiği için, bugün sunucu tarafında Wasm’e yönelen bir ekip hâlâ olgunlaşmakta olan bir ekosisteme bahse giriyor.

Bahis 3: Edge Compute

Edge bahsi üçüncü soruyu cevaplıyor: Kullanıcılarım coğrafi olarak dağınık; her isteğe özel kodun onlara yakın, container soğuk-başlangıç maliyetini ödemeden çalışmasını istiyorum. Wasm burada doğal oturuyor; çünkü soğuk başlangıcı milisaniye mertebesinde kalıyor (container’larda aynı süre saniyelerle ölçülüyor) ve sandbox’ı istek başına ucuza ayağa kalkıyor.

Bugün üretimdeki edge platformları üç ayrı biçimde karşımıza çıkıyor. Cloudflare Workers, V8 izolatları ile Wasm modüllerini eşleştiriyor; resmi Rust yolu workers-rs crate’i üstünden geçiyor. Fastly Compute, önünde V8 katmanı olmayan saf Wasm tabanlı bir edge runtime; bu ona farklı bir izolasyon hikâyesi ve farklı bir performans profili veriyor. Shopify Functions, satıcıların Rust, JavaScript veya AssemblyScript’ten derlediği Wasm modüllerini Shopify’ın checkout ve indirim akışlarında inline çalıştırmasına izin veren ticaret mantığı platformu.

Vaadin bittiği yer: Bytecode taşınabilir; host binding’leri değil. Her edge platformu kendi KV deposunu, kuyruğunu, binding ABI’sını ve runtime şeklini sunuyor. Cloudflare Workers için derlenmiş bir Wasm modülü Fastly Compute veya Shopify Functions’a olduğu gibi taşınmıyor. Taşınabilirlik vaadi talimat düzeyinde bitiyor; platform katmanında her sağlayıcı ayrışıyor. Binding’lerin kilitlenmeyi nereye sakladığı, wasmCloud + NATS taşınabilirlik yazısının derinlemesine işlediği tam da bu gerilim. CPU-yoğun bir modülü V8-artı-Wasm edge’ine göndermenin pratikte nasıl göründüğüne (ve üç sert limitin nerede ısıracağına) uygulamalı bir bakış için: Cloudflare Workers’a WASM Görsel Yeniden-Boyutlama Modülü Yüklemek.

Hangi İş İçin Hangi Eksen

Üç bahis isimlendirildikten sonra karar kısa bir ağaca dönüşüyor. “Wasm kullanmalı mıyım?” diye başlamak seni alışverişe gönderiyor. Bunun yerine mevcut mimarini üç problemden hangisinin tarif ettiğinden başla.

“Hiçbiri” dalı diğer üçü kadar önemli. Bu üç durumdan biri önünde durmadan Wasm’i devreye almak, henüz kullanım senaryosu olmayan bir platform bahsini omuzlamak demek.

Kapanış

Tarayıcı zaten günlük yüzeyindeyse ve JavaScript motorunun yutamadığı CPU yoğun bir ağrın varsa Bahis 1 ile başla; üç bahis içinde en olgunu ve en net geri dönüşü veren o. Sunucu ve edge bahislerine ise WASI Preview 3 release-candidate aşamasından stabil sürüme geçip runtime ekosistemi kalınlaştığında tekrar bakmaya değer.

Kaynaklar

• WebAssembly.org - WebAssembly standardının resmi evi; bytecode’un kapsamı için yetkili kaynak.
• MDN WebAssembly genel bakış - Geliştirici odaklı kavram dizini; JavaScript ↔ Wasm entegrasyonu, bellek ve araç rehberlerini kapsıyor.
• WASI.dev - Resmi WASI portalı; Preview 1 ile Preview 2 ayrımını adlandırıyor ve aktif runtime ekosistemini listeliyor.
• Bytecode Alliance - Wasmtime, WASI ve Component Model’i yürüten kâr amacı gütmeyen yapı; üye listesi sunucu tarafı Wasm’i kimlerin desteklediğini gösteriyor.
• WebAssembly/component-model (GitHub) - Güncel Component Model deposu; README hangi preview’ın aktif kilometre taşı olduğunu ve sonraki preview’ın kapsamını belgeliyor.
• WASI 0.2 duyurusu (Bytecode Alliance) - Preview 2 oylamasını 25 Ocak 2024 olarak tarihliyor ve Component Model mantığını anlatıyor.
• Figma blog: WebAssembly Figma’nın yüklenme süresini 3× kısalttı - Evan Wallace’ın 2017 yazısı; tarayıcıda Wasm için kanonik örnek olay.
• Photoshop’un web’e yolculuğu (web.dev) - Adobe ve Chrome ekibinin Photoshop C++ çekirdeğini Emscripten üstünden derlemesine dair çok yıllık vaka incelemesi.
• Cloudflare Workers: Rust dil desteği - V8-izolat-artı-Wasm edge modelinin ve workers-rs crate yolunun resmi dokümantasyonu.
• Fastly Compute ürün sayfası - Fastly’nin saf Wasm edge runtime için birinci elden konumlandırması; V8 sarmalı modeline karşı kullanışlı bir kontrast.