Cloudflare Workers artık Python ile yazılabiliyor

 (blog.cloudflare.com)
3 puan yazan GN⁺ 2024-04-03 | 1 yorum | WhatsApp'ta paylaş
  • Cloudflare Workers, Python ile yazmayı açık beta olarak destekliyor; Pyodide’ı açık kaynak Workers çalışma zamanı workerd’e doğrudan entegre ederek JavaScript merkezli modeli genişletiyor
  • Python Workers, Vectorize, Workers AI, R2, Durable Objects gibi mevcut binding’leri ilk günden destekliyor ve FastAPI, Langchain, Numpy gibi bazı Python paketlerini import edebiliyor
  • Uygulamanın temeli, CPython’ın WebAssembly portu olan Pyodide; JavaScript ile Python arasındaki FFI sayesinde Request, Response, Fetch API ve Cloudflare kaynak binding’leri Python kodundan kullanılabiliyor
  • Cloudflare, dağıtım anında import işlemlerini çalıştırıp WebAssembly doğrusal bellek anlık görüntüsü oluşturarak Pyodide ve paket başlatma maliyetini azaltıyor; temel bir Python Worker’ın cold start süresini 1 saniyenin altına indiriyor
  • Python sürümü ile Pyodide ve paket güncellemeleri Compatibility Dates ve Compatibility Flags ile yönetiliyor; 5 yıllık destek süresi bitmiş bir Python sürümünde kalan Worker’lar otomatik olarak bir sonraki en eski Python sürümüne taşınıyor

Python Workers açık beta

  • Cloudflare Workers’ta Python Workers açık beta olarak kullanılabiliyor
  • JavaScript dışındaki dillere yönelik önceki destekten farklı olarak, Python uygulamasını workerd çalışma zamanına doğrudan entegre ediyor
  • İlk günden desteklenen Cloudflare binding’leri şunları içeriyor
  • Python Workers, FastAPI, Langchain, Numpy gibi bazı popüler Python paketlerini import edebiliyor
  • Ayrı bir build aşaması veya harici toolchain gerekmiyor

Yalnızca WebAssembly’ye derlemek neden yeterli değildi

  • Workers, 2018’den beri WebAssembly destekliyor ve her Worker, Chrome’dakiyle aynı JavaScript motoru olan V8 isolate içinde çalışıyor
  • İlke olarak Python dahil birçok dil, önce WebAssembly’ye veya JavaScript’e derlendiğinde Workers’ta çalıştırılabiliyordu
  • Gerçek uygulamalar “hello world” çalıştırmaktan fazlasını gerektirir; geliştiricilerin alışık olduğu paket ekosistemi desteği önemlidir
  • Python Workers, Workers’ta JavaScript dışındaki dillere birinci sınıf destek verme yönündeki erken bir biçimdir

Python Worker çalışma akışı

  • Pyodide’ın workerd’e gömülmesiyle Python Worker, istekleri on_fetch handler’ı ile işleyebiliyor
  • wrangler.toml içinde .py dosyası main olarak belirtilir ve compatibility_flags = ["python_workers"] ayarlanır
  • npx wrangler@latest dev çalıştırıldığında Workers çalışma zamanı şunları yapar
    • compatibility date temelinde gerekli Pyodide sürümünü belirler
    • Worker için isolate oluşturur ve Pyodide’ı otomatik olarak enjekte eder
    • Python kodunu Pyodide’a sağlar
  • Python yürütme ortamı içeride ele alınır ve JavaScript Workers’a benzer şekilde platform tarafından sağlanır

Pyodide neden Workers’a uygun

  • Pyodide, CPython’ın WebAssembly’ye port edilmiş bir uygulamasıdır ve Python kodunu başka bir biçime önceden derlemeden yorumlar
  • Python standart kütüphanesinin büyük bölümünü sağlar ve JavaScript API’lerinin Python’dan çağrılabilmesi için yabancı fonksiyon arayüzü (FFI) sunar
  • Çekirdek interpreter’ı ve her yerel Python modülünü ayrı WebAssembly modülleri olarak build edip çalışma zamanında dinamik link edilebilecek şekilde tasarlanmıştır
  • Aynı makinede çalışan birden fazla Worker, modüllerin kod footprint’ini paylaşabildiğinden, makine başına binlerce Worker çalıştıran Cloudflare ortamı için önemlidir
  • WebAssembly hedefli dillerin çoğu henüz dinamik link desteğine sahip olmadığı için, her uygulama çoğu zaman kendi dil çalışma zamanı kopyasını içerir

Pyodide ve WebAssembly dinamik link

  • WebAssembly, host çalışma zamanından ayrılmış sandbox ortamı olduğundan, dosya okuma gibi saf hesaplama dışındaki işler çalışma zamanı ortamı tarafından sağlanmalı ve modül tarafından import edilmelidir
  • LLVM’nin WebAssembly hedefi üçe ayrılır
    • wasm32-unknown-unknown: C standart kütüphanesi veya sistem çağrısı arayüzü sağlamaz
    • wasm32-wasi: WASI çalışma zamanının uyguladığı standart sistem arayüzünü kullanır
    • wasm32-unknown-emscripten: Gerekli import’ları tanımlar ve bunları uygulayan JavaScript kütüphanesini birlikte çıktı olarak üretir
  • Pyodide, CPython interpreter’ı, Python-JavaScript FFI’sini ve WebAssembly’ye derlenmiş üçüncü taraf Python paketlerini sağlamak için Emscripten kullanır
  • Bu hedefler arasında şu anda yalnızca Emscripten dinamik link destekler
  • WASI, CPython’ın kullandığı dlopen/dlsym dinamik link soyutlamasını henüz desteklemiyor

Python ile JavaScript’i bağlayan FFI

  • Python Worker örneği, JavaScript’in Response nesnesini from js import Response ile getirir
  • Pyodide’ın FFI’si, Python’dan tüm JavaScript özelliklerine erişim sağlayarak Python Workers’ın işlev açısından JavaScript Workers’ın gerisinde kalması sorununu azaltır
  • String ve sayı gibi değişmez tipler iki dil arasında şeffaf biçimde dönüştürülür; değiştirilebilir nesneler ise uygun proxy’lerle sarılır
  • Bir JavaScript nesnesi Python’a aktarıldığında Pyodide, nesnenin desteklediği JavaScript protokollerini kontrol eder ve karşılık gelen Python protokolünü uygulayan sınıfı dinamik olarak oluşturur
    • JavaScript iteration protokolünü destekliyorsa Python iteration protokolünü de destekler
    • Promise veya thenable ise Python’da awaitable bir nesne olur
  • İstek işleme akışında da gelen JavaScript Request nesnesi, Python kodundan erişilebilen JsProxy ile sarılır ve Python handler’ının dönüş değeri JavaScript Response nesnesine dönüştürülür

Dinamik link ve Python paketleri

  • Birçok Python paketi, C FFI üzerinden yerel kütüphaneleri getirir; Workers çalışma zamanında çalışabilmeleri için bu kütüphanelerin WebAssembly’ye derlenmiş olması gerekir
  • Pyodide, Emscripten ile build edildiği için Python’ın C FFI’sini override eder ve paket yerel kütüphaneyi yüklemeye çalıştığında Workers çalışma zamanının sağladığı WebAssembly modülünü yükler
  • Dinamik link, yerel kütüphane bağımlılığı olan birden çok Python paketinin Pyodide tarafından desteklenmesini sağlar
  • Statik link, binary çalışmadan önce gerekli tüm kodun yüklenmesini gerektirir; dinamik link ise maliyeti ihtiyaç duyulan anda ödeme yaklaşımıdır
  • Workers, her Worker için çalışma zamanında Python dağıtımı gibi görünen bir dosya sistemi oluşturur, ancak temel dosyaları Worker’lar arasında paylaşır
  • Şu anda dosyalar Worker’lar arasında paylaşılıyor fakat her yeni isolate için kopyalanıyor; gelecekte copy-on-write tekniğiyle underlying resource’ların daha fazla paylaşılabileceği düşünülüyor

HTTP istemci ve sunucu kütüphanesi desteği

  • Python’da httpx, urllib3, requests gibi çok sayıda HTTP istemci kütüphanesi var, ancak bunlar Pyodide’da varsayılan olarak çalışmıyor
  • Bu kütüphaneler ham soketler kullanıyor; tarayıcı güvenlik modeli ve CORS buna izin vermediği için Workers çalışma zamanı içinde farklı bir yaklaşım gerekiyor

  • Asenkron istemciler

    • aiohttp ve httpx gibi asenkron istek yapabilen kütüphaneler Workers’ın Fetch API özelliğini kullanabiliyor
    • Cloudflare, Pyodide FFI ile kütüphaneleri JavaScript’in Fetch API’sini kullanacak şekilde yamalıyor
    • httpx yaması 100 satırdan az koddan oluşuyor

  • Senkron istemciler ve sınırlar

    • Birçok Python API’si senkron ve bu durumda asenkron Fetch API doğrudan kullanılamıyor
    • urllib3’e, Pyodide tarayıcı desteği için Atomics.wait() ve fetch worker thread’i ya da senkron XMLHttpRequest kullanan katkılar eklendi
    • Cloudflare Workers şu anda worker thread’leri ve senkron XMLHttpRequest desteklemediğinden, bu iki yaklaşım Python Workers’ta çalışmıyor
    • Şu anda senkron istekler desteklenmiyor

  • WebAssembly Stack Switching

    • WebAssembly’de stack switching ekleyen stage 3 aşamasında bir öneri var ve V8’de bunun bir uygulaması bulunuyor
    • Pyodide katkıcıları Eylül 2022’den beri stack switching desteği ekliyor ve destek neredeyse hazır
    • Bu destek geldiğinde Pyodide’ın run_sync işlevi, awaitable’ın tamamlanmasını beklemek için bloklanabilecek; böylece senkron istek desteği için bir yol açılacak

FastAPI ve ASGI

  • FastAPI, Python sunucu tanımları için yaygın kullanılan bir kütüphane ve ASGI protokolünü kullanıyor
  • FastAPI uygulamaları soketleri doğrudan okuyup yazmaz; ham soket işlemlerini genellikle uvicorn gibi bir ASGI sunucusu üstlenir
  • Bu yapı sayesinde FastAPI’nin kendisini yamalamadan veya değiştirmeden Cloudflare Workers üzerinde çalışması mümkün
  • Workers içinde çalışabilen bir ASGI sunucusuyla uvicorn’u değiştirmek yeterli
  • İlk uygulama workerd’in asgi.py dosyasında yer alıyor ve Cloudflare’ın bakımını yaptığı Pyodide fork’una dahil
  • Cloudflare, özelliği daha da tamamlayıp test kapsamı ekledikten sonra Pyodide’a upstream etmeyi planlıyor

Python paketlerini içe aktarma

  • Python Workers, Pyodide’ın doğrudan sağladığı bazı Python paketlerini destekliyor
  • Desteklenen paketler arasında numpy, httpx, FastAPI, Langchain gibi paketler bulunuyor
  • Bir paketi içe aktarmak için requirements.txt dosyasına sürüm numarası olmadan paket adını eklemek gerekiyor
  • Belirli paket sürümünü Pyodide doğrudan sağlıyor
  • Şu anda paketler yerel geliştirme sırasında kullanılabiliyor; birkaç hafta içinde requirements.txt bağımlılıkları tanımlanmış Workers dağıtımı mümkün olacak
  • Cloudflare, Workers çalışma zamanına özel yamalar sağlamak için kendi Pyodide fork’unu sürdüreceğini ve değişiklikleri Pyodide upstream’e yansıtacağını söylüyor

Cold start ve bellek snapshot’ları

  • Pyodide’ın kendi boyutu 6.4MB ve Python paketleri de büyük olabiliyor
  • Pyodide doğrudan bir Worker’a konup Cloudflare’a yüklendiğinde yeni isolate yükleme maliyeti büyüyor ve cold start yavaşlıyor
  • Hızlı bir bilgisayar ve iyi bir ağda Pyodide’ın tarayıcıda başlatılması yaklaşık 2 saniye sürüyor; bunun 1 saniyesi ağ, 1 saniyesi CPU süresi
  • npx wrangler@latest deploy sırasında dağıtım süreci şöyle işliyor
    • Wrangler, Python kodunu ve requirements.txt dosyasını Workers API’ye yüklüyor
    • Workers çalışma zamanı Python kodunu ve bağımlılıkları doğruluyor
    • Yeni bir isolate oluşturup Pyodide’ı ve belirtilen paketleri otomatik olarak enjekte ediyor
    • Worker kodundaki import ifadelerini tarayıp çalıştırdıktan sonra Worker’ın WebAssembly lineer belleğinin snapshot’ını oluşturuyor
    • Bu snapshot’ı ve Python kodunu Cloudflare ağına dağıtıyor
    • JavaScript Worker’da olduğu gibi top-level scope’u çalıştırıyor
  • Bir istek geldiğinde bu snapshot yüklenip isolate içinde Worker bootstrap edildiği için pahalı başlatma maliyetinden kaçınılıyor
  • Temel bir Python Worker’ın cold start süresi 1 saniyenin altına iniyor

  • Snapshot yeniden kullanımı

    • Şu anda Python Worker yüklendiğinde oluşturulan bellek snapshot’ı yalnızca ilgili Worker’a özel; diğer Python Workers ile büyük ölçüde aynı olsa bile paylaşılamıyor
    • Cloudflare, önceden tek bir ortak snapshot oluşturup Pyodide çalışma zamanı zaten yüklenmiş pre-warmed isolate havuzuna önceden yükleyebileceğini düşünüyor
    • Bu yöntemle Python Worker da JavaScript Worker gibi çalışma zamanının on-demand sağlandığı modele yaklaşır
    • Cloudflare, 2024’ün kalan kısmında cold start sürelerini daha da düşürmenin en büyük yolu olarak snapshot yeniden kullanımını görüyor

Compatibility Dates ile Python sürüm yönetimi

  • Cloudflare Workers, bir kez dağıtılmış Worker’ın güncelleme yapılmadan da çalışmaya devam etmesinin beklendiği bir modele sahip
  • Bu kararlılık Compatibility Dates ve Compatibility Flags üzerinden sağlanıyor
  • Python tarafında Pyodide ve CPython’ın ayrı ayrı sürümleri var ve yeni sürümler breaking change içerebiliyor
  • Yeni Python sürümü her yıl ağustosta yayımlanıyor, yeni Pyodide sürümü ise bundan 6 ay sonra yayımlanıyor
  • Yeni Pyodide sürümü Workers’a eklendiğinde bir Compatibility Flag arkasına konuyor ve yalnızca belirtilen Compatibility Date’ten sonra etkinleşiyor
  • Python sürümleri 5 yıllık destek süresine sahip; destek süresi dolan Python sürümlerine güvenlik yamaları uygulanmıyor
  • 5 yıl geçmesine rağmen eski bir Python sürümünde kalan Python Worker, otomatik olarak bir sonraki en eski Python sürümüne taşınıyor
  • Cloudflare çoğu durumda Python Worker’ın sorunsuz şekilde çalışmaya devam etmesini bekliyor, ancak destek süresi içinde kalmak için compatibility date’in düzenli olarak güncellenmesini öneriyor
  • Python sürümleri arasında da paketler aynı opt-in modeliyle güncellenecek ve eklenecek; örnek flag biçimi python_3.17_packages_2025_03_01 şeklinde

Python Workers’ta binding’ler

  • Pyodide FFI sayesinde Python’dan JavaScript nesnelerine, metotlarına ve fonksiyonlarına doğrudan erişilebilir
  • Bu yapı sayesinde Cloudflare kaynaklarına yönelik tüm binding API’leri ilk günden itibaren Python Workers’ta desteklenir
  • Python handler’ındaki env nesnesi bir JavaScript nesnesidir; Pyodide, diller arası tip dönüşümünü yöneten bir proxy API sağlar
  • Bir KV namespace’i için Python’da env.FOO.put() ve env.FOO.get() çağrılarını await ederek değer yazıp okuyabilirsiniz
  • Web API de aynı şekilde kullanılabilir; Response gibi JavaScript global’leri js modülünden import edilebilir

Daha Python’a özgü API planı

  • Cloudflare, from js import Response gibi bir biçimin Python’a özgü hissettirmediğinin farkında ve Python Workers’a daha idiomatic bir API sunmayı planlıyor
  • 2021’de yayımlanan workers-rs, Workers’ın her JavaScript API’si için Rust’a özgü binding’ler sağlamıştı
  • Python Workers’ta da aynı yön planlanıyor; ilk olarak Workers AI ve Vectorize binding’leriyle başlanıyor
  • Rust’taki workers-rs dış bağımlılıklar kullanıp güncellenmeyi gerektirirken, Python Workers’ın API’sinin doğrudan Workers runtime’ına yerleşik olması planlanıyor
  • compatibility date güncellendiğinde en yeni Python’a özgü API’ler kullanılabilir
  • Workers’ın JavaScript connect() API’sini temel alarak Python standart kütüphanesindeki raw socket API’nin bir kısmını sunma olasılığı da var
  • Cloudflare, JavaScript ile aynı yetenekleri sunarken Python geliştiricilerinin kolayca kullanabileceği standartlaştırılmış bir serverless API oluşturma çabasını başlatmayı umuyor

Bundan sonraki yön

  • Yeni bir programlama dilini düzgün desteklemek için “hello world”ün ötesinde büyük bir yatırım gerekir
  • Stack Overflow 2023 anketine göre Python, JavaScript’ten sonra en çok kullanılan dil olarak görünüyor
  • Cloudflare, Python Workers’ın performansını sürekli iyileştireceğini ve Python paket desteğinin kapsamını genişleteceğini söylüyor
  • Geri bildirim kanalları, Cloudflare Developers Discord’daki Python Workers kanalı ve workerd GitHub discussion sayfasıdır

İlgili okumalar

1 yorum

 
GN⁺ 2024-04-03
Hacker News yorumları

  • Cloudflare’ın Edge’de WebAssembly ile Python çalıştırmaya daha fazla önem vermesi sevindirici
    Wasmer’da Edge üzerinde WebAssembly tabanlı Python çalıştırma üzerine çalışmış biri olarak özetlersem, Cloudflare Workers Python’u Edge’de etkinleştirmek için Emscripten ile WebAssembly’ye derlenmiş Python olan Pyodide’ı kullanıyor
    Yapı, Pyodide’ı Workerd’e bağlayıp V8 snapshot’larıyla başlangıç süresini azaltmaya çalışıyor; en iyi durumda Python cold start süresi yaklaşık 1 saniye
    Ancak mevcut yöntem Workerd’ün içerdiği Python/Pyodide sürümüne bağlı ve paket çözümleme de Workerd’e sıkı şekilde bağlandığı için çalışma zamanında yalnızca önceden derlenmiş native paketlere izin verilmesi olası. Örneğin belirli bir numpy sürümünü kullanmak zahmetli olabilir
    Yapısal olarak JS/V8 dünyasına bağlı olduğundan, mevcut mimariyle 100 ms’nin altında başlangıç süresi elde etmek zor görünüyor
    Yine de bu sürümü memnuniyetle karşılıyorum ve insanların harika uygulamalar geliştirmesini umuyorum
    https://pyodide.org/
    https://github.com/cloudflare/workerd/blob/main/docs/pyodide...
    https://github.com/cloudflare/workerd/pull/1875
    Düzenleme: Cloudflare ekibinin açıklamasını yansıtmak için “kavram kanıtı” ifadesini “sürüm” olarak değiştirdim

    • Sürüm yönetimi biçimine ilişkin özetinizde bir yanlış anlama var gibi. Pyodide/paket sürümleri uyumluluk tarihiyle kontrol ediliyor ve production’da aynı anda birden çok sürüm desteklenebiliyor
      langchain veya bahsettiğiniz numpy gibi paketleri oldukça sık güncellemeyi planlıyoruz
      V8’in neden sınırlayıcı faktör olduğunu düşündüğünüzü biraz daha açıklarsanız iyi olur. V8 güçlü bir WebAssembly runtime’ı ve planlanan optimizasyonların çoğu alttaki motora çok fazla bağlı değil
      Ayrıca bu bir kavram kanıtı değil; sürekli iyileştirilerek GA’ya taşınacak bir beta
    • Not olarak, Wasmer Cloudflare Workers’ta Python çalıştırırken bahsedilen dezavantajlara sahip olmayan ve çok hızlı cold start sağlayan bir Edge ürünü sunuyor
      https://wasmer.io/templates?language=python
    • “Mevcut mimariyle 100 ms’nin altında başlangıç süresi zor olur” demişsiniz; 100 ms’nin altında gecikme gerektiren Python iş yüklerini kimin çalıştırdığını merak ediyorum
    • Bu mimarinin uvloop’u destekleyip desteklemediğini merak ediyorum

  • Cloudflare’ın hosting ve veritabanı tarafında iyi pek çok şeyi var, ama bir geliştirici platformu olarak pazarlamasını iyi yapamadığı için Vercel veya Netlify epey bir zihin payı kapmış gibi görünüyor
    Ayrı olarak, Cloudflare’ın Google Cloud Run gibi dilden bağımsız bir container hosting hizmeti sunup sunmadığını merak ediyorum

    • Pazarlama tarafında bir sorun olduğu fikrine katılıyorum. Başta Vercel ve Netlify beni cezbetmişti ama uzun süre kullanıp ikisinden de memnun kalmayınca Cloudflare’ı denedim ve sonunda sevdim
      Fiyatlandırma ve ürünler harika
    • Sorun yalnızca pazarlama değil. Başta Cloudflare ürün ailesi konusunda iyimserdim, ancak Next.js ve Astro gibi web sitesi üreticileriyle uyumlulukta büyük sorunlar yaşadım
      Bazı özellikler hiç çalışmadı, bazıları ise yalnızca kısmen desteklendi
      Değerli geliştirme zamanınızı bu tür sorunları çözmeye harcamanız gerekiyorsa, Vercel, Netlify, Deno Deploy gibi alternatif platformlar ekibin ihtiyaçları için daha sorunsuzdu ve altyapı sorunlarından çok geliştirmeye odaklanmayı kolaylaştırıyordu
    • Vercel ve Netlify geliştiricileri hedefliyor gibi gelmiyor. Bir geliştiriciyseniz Vercel ve Netlify kullanmak pratikte kazıklanmakla aynı şey
      Bant genişliği maliyetleri Vercel ve Netlify’da çoğu bulut sağlayıcısından 40-50 kat daha pahalı; Cloudflare’da ise bant genişliği neredeyse maliyet kalemi değil
      Edge function çağrıları da Vercel ve Netlify’da Cloudflare’a göre 6 kat pahalı. Cloudflare’da ücretsiz olan compute süresi maliyetleri bu rakama dahil değil
      Vercel’in popüler olmasının neredeyse tek nedeni NextJS’i barındırmak için en iyi yer olması; bu yüzden NextJS’i başka yerlere dağıtmayı zorlaştırıyor da olabilirler
    • Yakın zamana kadar CloudFlare ücretsiz katmanının oldukça sınırlı olduğunu biliyorum. SQLite implementasyonu olan D1 dün genel kullanıma açıldı ve read replica’lar da duyuruldu
    • Google Cloud Run gibi bir şey yok, ama olsa gerçekten harika olurdu
      Workers’ı production’da yaklaşık 4 yıldır kullanıyorum ve seviyorum, ancak uygulamaların çoğunu hâlâ container üzerinde çalıştırıyorum

  • Cloudflare’ın önüne koyduğum bir sitede JS Workers kullandım; kullanımı kolaydı ve çok hızlıydı. Sitenin arkasındaki Django uygulamasının tamamını D1 veritabanını da kullanarak taşımak istiyorum

    • Bende de benzer. Cloudflare Workers ve KV/D1 kullanan birkaç mobil uygulamam var ve çok iyi çalıştı
      Trafik düşük olduğu için ücretsiz katmanda kalıyorum, ama geliştirmesi o kadar kolay ki para ödemeye de razıyım
    • Katılıyorum, gerçekten harika görünüyor. Şu anda Django/DRF desteği yok, ancak ileride paket sayısını artıracaklarını söylüyorlar
    • Sitenin arkasındaki Django uygulamasının tamamını D1’e kadar taşımanın akıllıca olduğundan emin misiniz? Tek bir DDoS saldırısı bütçenizi altüst edebilir

  • JS Worker ile performans karşılaştırması olsa faydalı olurdu. İlginç, ama işin içine birden fazla katman girdiği için potansiyel olarak yavaş olabilecek gibi görünüyor
    Eşdeğer performans beklemiyorum, ama kabaca hangi ödünleşimler olduğunu bilmek iyi olurdu

    • Performansın üç yönü var: cold start performansı, cold start sonrası performans, JS ile WebAssembly arasındaki köprü maliyeti ve WebAssembly üzerinde çalışan Python yorumlayıcısının hızı
      Şu anda Python cold start’ı, aynı boyuttaki JavaScript Worker’dan daha yavaş. JavaScript ile yazılmış temel bir “Hello World” Worker’ın cold start süresi neredeyse 0’a yakınken, Python Worker 1 saniyenin altında
      Bunun nedeni, istek geldiğinde Pyodide’ın Worker’a talep üzerine yüklenmesi gerekmesi; blog yazısında bunu azaltmak için Pyodide’ı önceden kullanılabilir hale getirme çalışması anlatılıyor
      Ancak Python Worker cold start’ı tamamladıktan sonra fark kenara yakın hale geliyor ve istek sırasında ne olduğuna bağlı olarak birkaç milisaniye düzeyinde olabilir
      JavaScript ile WebAssembly arasındaki “köprüden” geçerken, örneğin giriş/çıkış ya da asenkron işler yapılırken küçük bir maliyet var. Ama bunu milisaniye değil mikrosaniye düzeyinde düşünmek gerekir ve genellikle çok küçük
      Performansa duyarlı Worker kullananlar zaten Rust ile de yazıyor: https://github.com/cloudflare/workers-rs bu da JavaScript ile WebAssembly arasındaki köprüye dayanıyor
      Pyodide’ın sağladığı WebAssembly tabanlı Python yorumlayıcısı, V8’de JavaScript’i hızlandırmak için yıllar içinde biriken optimizasyonlar kadar hızlı değil. Yine de Pyodide, V8’in JS motoruna kıyasla hâlâ erken aşamada ve büyük performans artışı mümkün görünen alanlar var. Performans iyileştirmelerini upstream’e yansıtmak istiyoruz ve yardımcı olabilecek WebAssembly önerileri de var
    • Hissedilen performans olarak çok hızlı görünüyor

  • İzolasyonu göstermek için lzma seçiminin kasıtlı mı olduğunu, yoksa geçen haftaki teknoloji haberleri nedeniyle tesadüfen mi böyle denk geldiğini merak ediyorum
    https://news.ycombinator.com/item?id=39865810

    • Standart kütüphanede olduğu için dahil ettim. Zamanlama tamamen tesadüf, ama Wasm kullanınca izolasyon garantisi gelmesi güzel :-)

  • Cloudflare üzerinde yapay zeka ile ilgili işler çalıştırmak için epey oyunu değiştiren bir şey olacak gibi. Uzun süredir bunu bekliyordum

  • Bugün denedim, güzeldi ve çok hızlı şekilde çalışır hale gelebildim
    Ancak yerel geliştirme ortamının CFW’nin Python implementasyonuna gömülü kütüphaneleri anlamasını nasıl sağlayacağımı merak ediyorum
    Örneğin asgi kütüphanesi var; linter’ın bunu bilinmiyor diye işaretlememesini istiyorum. Ama bu kütüphane yalnızca on_fetch handler’ının runtime’ında var ve yerel geliştirme makinesinde fiilen olmadığı için bir çözüm bulamadım

  • Statik sitelerde CF Pages kullanıp iyi sonuçlar aldım; açık kaynak LLM’leri servis gibi sunan Cloudflare ürünleri de ilginç
    Cloudflare’da daha fazla şey geliştirmemi engelleyen ana neden Python desteğinin olmamasıydı ve bu özelliği denemeyi dört gözle bekliyorum

    • Ben de CF Pages ve birkaç Worker fonksiyonu kullanıyorum; Cloudflare ekosistemi gerçekten iyi
      Bir şeyi hızlıca çalıştırmak kolay ve altyapıyla pek uğraşmanız gerekmiyor
      Python eklenmesi çok sevindirici; Go da birinci sınıf destek olarak gelse güzel olurdu

  • Yalnızca Pyodide paketlerini kullanma kısıtının önemsiz olmayan build’lerde nasıl işleyeceğini merak ediyorum
    Saf Python olmayan çok kod var; pratikte production uygulamalarını desteklemek için elle yeniden build edilmesi gerekecek çok şey olacak gibi
    Cloudflare’ın benimsemesi daha fazla paketi çekmeye yardımcı olabilir ve burada 80/20 kuralı geçerliyse yeterince iyi olabilir

    • Burada kesinlikle 80/20 kuralı olduğunu düşünüyorum. Paketlerin çoğunu port etmek çok zor değil; build’i zor olanlar genelde thread ve multiprocessing, grafik kartı, raw socket, green thread gibi WebAssembly runtime’ında net karşılığı olmayan özellikleri kullanıyor
      Blog yazısında da belirtildiği gibi en büyük sorun sunucu ve istekle ilgili paket desteği. Cloudflare Workers’ta kesinlikle yararlı olur, ama raw socket ve bir tür eşzamanlılığı sık kullandıkları için port etmek zor

  • CloudFlare’in, JS Workers’a bağlı olmayan genel amaçlı bir API ile birlikte WASM’ı birinci sınıf hedef olarak alan Workers implementasyonu yapmasını isterdim
    Şu anda da WASM kodu dağıtabiliyorsunuz, yani fiilen herhangi bir dili kullanabilirsiniz; ama native değil, JS bağlamı içinde çalışıyor
    Dağıtımda biraz overhead ve tuhaflık var
    Sonunda tüm servislerin konteynerlara değil, doğrudan güvenli hale getirilmiş WASM runtime’larına dağıtılacağını düşünüyorum. İmajlardan konteynerlara geçiş akışına benzer şekilde
    Şu anda Cloudflare Edge’de Rust gibi bir şey kullanmanın avantajı büyük değil. Çünkü performans avantajlarının önemli bir kısmı overhead ve başlangıç süresiyle dengeleniyor
    Örnek: https://github.com/WasmEdge/WasmEdge