Cloudflare Workers, अब Python में भी लिखे जा सकते हैं

 (blog.cloudflare.com)
3 पॉइंट द्वारा GN⁺ 2024-04-03 | 1 टिप्पणियां | WhatsApp पर शेयर करें
  • Cloudflare Workers अब open beta में Python लेखन को सपोर्ट करता है, और Pyodide को open source Workers runtime workerd में सीधे इंटीग्रेट करके JavaScript-केंद्रित मॉडल का विस्तार करता है
  • Python Workers पहले दिन से Vectorize, Workers AI, R2, Durable Objects जैसी मौजूदा bindings को सपोर्ट करते हैं, और FastAPI, Langchain, Numpy जैसे कुछ Python पैकेज import कर सकते हैं
  • इम्प्लीमेंटेशन का आधार CPython का WebAssembly पोर्ट Pyodide है, और JavaScript तथा Python के बीच FFI के जरिए Request, Response, Fetch API, Cloudflare resource bindings को Python कोड में संभाला जाता है
  • Cloudflare deploy के समय import चलाकर WebAssembly linear memory snapshot बनाता है, जिससे Pyodide और पैकेज initialization की लागत कम होती है, और बेसिक Python Worker का cold start 1 सेकंड से नीचे लाया जाता है
  • Python version तथा Pyodide और पैकेज updates को Compatibility Dates और Compatibility Flags से मैनेज किया जाता है, और 5 साल की support अवधि खत्म होने वाले Python release पर रुका Worker अपने-आप अगले सबसे पुराने Python release पर शिफ्ट हो जाता है

Python Workers open beta

  • Cloudflare Workers में Python Workers अब open beta में उपलब्ध हैं
  • JavaScript के अलावा दूसरी भाषाओं के पुराने समर्थन से अलग, इसमें Python implementation को सीधे workerd runtime में इंटीग्रेट किया गया है
  • पहले दिन से सपोर्ट होने वाले Cloudflare bindings में ये शामिल हैं
  • Python Workers FastAPI, Langchain, Numpy जैसे कुछ लोकप्रिय Python पैकेज import कर सकते हैं
  • किसी अलग build step या बाहरी toolchain की जरूरत नहीं है

जहां सिर्फ WebAssembly compilation काफी नहीं थी

  • Workers 2018 से WebAssembly को सपोर्ट करता है, और हर Worker V8 isolate में चलता है, जो Chrome जैसा JavaScript engine है
  • सिद्धांत रूप में Python सहित कई भाषाएं पहले WebAssembly या JavaScript में compile होने पर Workers में चल सकती थीं
  • लेकिन असली application के लिए सिर्फ “hello world” चलना काफी नहीं होता, डेवलपर्स के लिए परिचित package ecosystem का समर्थन भी जरूरी है
  • Python Workers, Workers में JavaScript के अलावा दूसरी भाषाओं को first-class support देने की शुरुआती रूपरेखा हैं

Python Worker execution flow

  • Pyodide के workerd में built-in होने से Python Worker on_fetch handler के जरिए request प्रोसेस कर सकता है
  • wrangler.toml में .py फ़ाइल को main के रूप में सेट किया जाता है और compatibility_flags = ["python_workers"] कॉन्फ़िगर किया जाता है
  • npx wrangler@latest dev चलाने पर Workers runtime ये काम करता है
    • compatibility date के आधार पर जरूरी Pyodide version तय करता है
    • Worker के लिए isolate बनाता है और Pyodide को अपने-आप inject करता है
    • Pyodide को Python कोड उपलब्ध कराता है
  • Python execution environment अंदरूनी रूप से मैनेज होता है, और JavaScript Workers की तरह platform इसे उपलब्ध कराता है

Pyodide Workers के लिए उपयुक्त क्यों है

  • Pyodide CPython का WebAssembly पोर्ट है, और Python कोड को किसी दूसरे फ़ॉर्मैट में पहले से compile किए बिना interpret करता है
  • यह Python standard library का अधिकांश हिस्सा देता है, और Python से JavaScript API कॉल करने के लिए foreign function interface (FFI) उपलब्ध कराता है
  • इसे इस तरह डिजाइन किया गया है कि core interpreter और हर native Python module को अलग WebAssembly module के रूप में build किया जाए, और runtime पर dynamic linking किया जा सके
  • एक ही मशीन पर चलने वाले कई Workers मॉड्यूल का code footprint साझा कर सकते हैं, जो प्रति मशीन हजारों Workers चलाने वाले Cloudflare environment में महत्वपूर्ण है
  • अधिकतर WebAssembly target भाषाएं अभी dynamic linking सपोर्ट नहीं करतीं, इसलिए कई application अपने language runtime की कॉपी खुद शामिल करती हैं

Pyodide और WebAssembly dynamic linking

  • WebAssembly host runtime से अलग एक sandbox environment है, इसलिए फ़ाइल पढ़ने जैसे pure computation के बाहर के काम runtime environment को उपलब्ध कराने होते हैं और module उन्हें import करता है
  • LLVM के WebAssembly target तीन प्रकार के हैं
    • wasm32-unknown-unknown: C standard library या system call interface उपलब्ध नहीं कराता
    • wasm32-wasi: WASI runtime द्वारा implement किए गए standard system interface का उपयोग करता है
    • wasm32-unknown-emscripten: जरूरी imports को define करता है और उन्हें implement करने वाली JavaScript library भी साथ में output करता है
  • Pyodide Emscripten का उपयोग करके CPython interpreter, Python-JavaScript FFI, और WebAssembly में compile किए गए third-party Python packages उपलब्ध कराता है
  • इन targets में फिलहाल सिर्फ Emscripten dynamic linking को सपोर्ट करता है
  • WASI अभी CPython द्वारा उपयोग किए जाने वाले dlopen/dlsym dynamic linking abstraction को सपोर्ट नहीं करता

Python और JavaScript को जोड़ने वाला FFI

  • Python Worker उदाहरण में from js import Response के जरिए JavaScript का Response लाया जाता है
  • Pyodide का FFI Python को JavaScript की सभी सुविधाओं तक पहुंच देता है, जिससे Python Workers फीचर के मामले में JavaScript Workers से पीछे न रहें
  • string और number जैसे immutable type दोनों भाषाओं के बीच पारदर्शी रूप से convert हो जाते हैं, जबकि mutable object उपयुक्त proxy में wrap किए जाते हैं
  • जब JavaScript object Python में पास होता है, तो Pyodide यह जांचता है कि वह कौन-कौन से JavaScript protocol सपोर्ट करता है, और फिर उसी के अनुरूप Python protocol लागू करने वाली class को dynamic रूप से बनाता है
    • अगर वह JavaScript iteration protocol सपोर्ट करता है, तो Python iteration protocol भी सपोर्ट करेगा
    • अगर वह Promise या thenable है, तो Python में वह awaitable object बन जाता है
  • request processing flow में आने वाला JavaScript Request object Python कोड में सुलभ JsProxy में wrap होता है, और Python handler का return value JavaScript Response object में convert हो जाता है

Dynamic linking और Python packages

  • कई Python packages C FFI के जरिए native library लाते हैं, और Workers runtime में चलने के लिए इन libraries का WebAssembly में compile होना जरूरी है
  • Pyodide, Emscripten से build होने के कारण Python के C FFI को override करता है, और जब कोई package native library load करना चाहता है, तब Workers runtime द्वारा उपलब्ध WebAssembly module लोड करता है
  • dynamic linking की वजह से Pyodide native library dependency वाले कई Python packages को सपोर्ट कर सकता है
  • static linking में binary चलने से पहले जरूरी सारा code लोड करना पड़ता है, जबकि dynamic linking में जरूरत पड़ने पर ही उसकी लागत चुकानी होती है
  • Workers हर Worker के लिए runtime पर ऐसा filesystem बनाता है जो Python distribution जैसा दिखता है, लेकिन उसकी base files Workers के बीच साझा होती हैं
  • अभी files को Workers के बीच साझा किया जाता है, लेकिन हर नए isolate पर कॉपी किया जाता है; आगे चलकर copy-on-write तकनीक से underlying resource को और अधिक साझा किया जा सकता है

HTTP क्लाइंट और सर्वर लाइब्रेरी सपोर्ट

  • Python में httpx, urllib3, requests जैसी कई HTTP क्लाइंट लाइब्रेरी हैं, लेकिन ये Pyodide में डिफ़ॉल्ट रूप से काम नहीं करतीं
  • ये लाइब्रेरी raw sockets का उपयोग करती हैं, और browser security model तथा CORS इसकी अनुमति नहीं देते, इसलिए Workers runtime में अलग तरीका चाहिए

  • Async क्लाइंट

    • aiohttp और httpx जैसी लाइब्रेरी, जो async requests कर सकती हैं, Workers के Fetch API का उपयोग कर सकती हैं
    • Cloudflare, Pyodide FFI के ज़रिए लाइब्रेरी को patch करके JavaScript के Fetch API का उपयोग करवाता है
    • httpx patch 100 लाइनों से कम कोड का है

  • Sync क्लाइंट और सीमाएँ

    • कई Python APIs synchronous हैं, और इस स्थिति में async Fetch API को सीधे इस्तेमाल नहीं किया जा सकता
    • urllib3 में Pyodide browser support के लिए Atomics.wait() और fetch worker thread, या synchronous XMLHttpRequest का उपयोग करने वाले योगदान जोड़े गए हैं
    • Cloudflare Workers अभी worker threads और synchronous XMLHttpRequest को support नहीं करता, इसलिए ये दोनों तरीके Python Workers में काम नहीं करते
    • फिलहाल synchronous requests supported नहीं हैं

  • WebAssembly Stack Switching

    • WebAssembly में stack switching जोड़ने का stage 3 proposal है, और V8 में इसका implementation मौजूद है
    • Pyodide contributors सितंबर 2022 से stack switching support जोड़ रहे हैं, और यह लगभग तैयार है
    • यह support आने पर Pyodide का run_sync, awaitable के पूरा होने तक block कर सकेगा, जिससे synchronous requests support का रास्ता खुलेगा

FastAPI और ASGI

  • FastAPI Python server definitions के लिए व्यापक रूप से इस्तेमाल होने वाली लाइब्रेरी है, और यह ASGI protocol का उपयोग करती है
  • FastAPI application सीधे sockets को read या write नहीं करती; आमतौर पर uvicorn जैसा ASGI server raw socket handling संभालता है
  • इसी architecture की वजह से FastAPI खुद को patch या modify किए बिना Cloudflare Workers पर चल सकती है
  • बस uvicorn को ऐसे ASGI server से बदलना होगा जो Workers के अंदर चल सके
  • शुरुआती implementation workerd ka asgi.py में है, और यह Cloudflare द्वारा maintain किए गए Pyodide fork में शामिल है
  • Cloudflare का योजना है कि और features जोड़ने और test coverage बढ़ाने के बाद इसे Pyodide में upstream किया जाए

Python पैकेज import करना

  • Python Workers, Pyodide द्वारा सीधे उपलब्ध कराए गए कुछ Python packages को support करते हैं
  • supported packages में numpy, httpx, FastAPI, Langchain आदि शामिल हैं
  • पैकेज import करने के लिए requirements.txt में version number के बिना package name जोड़ें
  • specific package versions सीधे Pyodide द्वारा उपलब्ध कराए जाते हैं
  • अभी local development में packages का उपयोग किया जा सकता है, और कुछ हफ्तों में requirements.txt dependencies के साथ Workers deploy करना संभव होगा
  • Cloudflare अपना Pyodide fork maintain करता है ताकि Workers runtime के लिए विशेष patches दिए जा सकें, और बदलावों को Pyodide upstream में वापस भेजने की बात कहता है

Cold start और memory snapshots

  • Pyodide का आकार खुद 6.4MB है, और Python packages भी बड़े हो सकते हैं
  • अगर Pyodide को सीधे Worker में डालकर Cloudflare पर upload किया जाए, तो नया isolate लोड करने की लागत बढ़ जाती है और cold start धीमा हो जाता है
  • तेज़ कंप्यूटर और अच्छे network पर Pyodide को browser में initialize होने में लगभग 2 सेकंड लगते हैं, जिसमें 1 सेकंड network और 1 सेकंड CPU लगता है
  • npx wrangler@latest deploy के समय deployment process इस तरह काम करती है
    • Wrangler, Python code और requirements.txt को Workers API पर upload करता है
    • Workers runtime, Python code और dependencies को validate करता है
    • नया isolate बनाता है और Pyodide तथा चुने गए packages को अपने-आप inject करता है
    • Worker code के import statements को scan करके उन्हें run करता है, फिर Worker की WebAssembly linear memory का snapshot बनाता है
    • इस snapshot और Python code को Cloudflare network पर deploy करता है
    • JavaScript Worker की तरह top-level scope को execute करता है
  • request आने पर यही snapshot लोड करके isolate में Worker को bootstrap किया जाता है, जिससे महंगी initialization cost से बचा जाता है
  • basic Python Worker का cold start 1 सेकंड से कम तक आ जाता है

  • Snapshot reuse

    • अभी Python Worker upload करते समय बनने वाला memory snapshot उसी Worker के लिए dedicated होता है; दूसरे Python Workers के साथ, भले ही उसका बड़ा हिस्सा समान हो, इसे share नहीं किया जा सकता
    • Cloudflare का मानना है कि पहले से एक shared snapshot बनाया जा सकता है, और Pyodide runtime पहले से लोड किए गए pre-warmed isolate pool में उसे preload किया जा सकता है
    • इस तरीके से Python Worker भी JavaScript Worker की तरह उस मॉडल के करीब आ जाएगा जहाँ runtime on-demand उपलब्ध होता है
    • Cloudflare 2024 के बाकी समय में cold start को और घटाने का सबसे बड़ा तरीका snapshot reuse को मानता है

Compatibility Dates से Python version management

  • Cloudflare Workers ऐसा मॉडल रखता है जिसमें एक बार deploy किया गया Worker बिना update के भी लगातार चलता रहना चाहिए
  • यह स्थिरता Compatibility Dates और Compatibility Flags के ज़रिए दी जाती है
  • Python में Pyodide और CPython, दोनों के अपने versions होते हैं, और नए versions में breaking changes हो सकती हैं
  • नया Python version हर साल अगस्त में release होता है, और नया Pyodide version उसके 6 महीने बाद release होता है
  • नया Pyodide version जब Workers में जोड़ा जाता है, तो उसे Compatibility Flag के पीछे रखा जाता है, और वह केवल तय Compatibility Date के बाद ही enabled होता है
  • Python release की 5 साल की support period होती है, और support period खत्म हो चुके Python versions पर security patches लागू नहीं किए जाते
  • 5 साल बीत जाने पर भी पुराने Python release पर बने रहने वाले Python Workers को अपने-आप अगले पुराने Python release पर ले जाया जाएगा
  • Cloudflare को उम्मीद है कि ज़्यादातर मामलों में Python Workers बिना समस्या के चलते रहेंगे, लेकिन support period के भीतर रहने के लिए compatibility date को नियमित रूप से update करने की सलाह दी जाती है
  • Python releases के बीच भी packages को इसी opt-in तरीके से update और add किया जाएगा, और example flag का format python_3.17_packages_2025_03_01 है

Python Workers के bindings

  • Pyodide FFI की बदौलत Python से JavaScript object, method और function तक सीधे पहुंचा जा सकता है
  • इस संरचना की वजह से Cloudflare resources के लिए सभी binding API पहले ही दिन से Python Workers में supported हैं
  • Python handler का env object एक JavaScript object है, और Pyodide एक proxy API देता है जो languages के बीच type conversion संभालता है
  • KV namespace के लिए env.FOO.put() और env.FOO.get() को Python में await करके value लिखी और पढ़ी जा सकती है
  • Web API भी इसी तरह इस्तेमाल किए जा सकते हैं, और Response जैसे JavaScript global को js module से import किया जा सकता है

और ज़्यादा Python-जैसे API की योजना

  • Cloudflare मानता है कि from js import Response जैसी form Pythonic नहीं लगती, और Python Workers के लिए ज़्यादा idiomatic API देने की योजना है
  • 2021 में जारी workers-rs ने Workers के हर JavaScript API के लिए Rust-शैली bindings दिए थे
  • Python Workers में भी वही दिशा अपनाने की योजना है, और शुरुआत Workers AI और Vectorize bindings से की जा रही है
  • Rust का workers-rs external dependencies का उपयोग करता है और उसे update करना पड़ता है, लेकिन Python Workers के API सीधे Workers runtime में built-in होने वाले हैं
  • compatibility date update करने पर नए Python-जैसे API इस्तेमाल किए जा सकेंगे
  • Workers के JavaScript connect() API के आधार पर Python standard library के raw socket API का कुछ हिस्सा देने की भी संभावना है
  • Cloudflare को उम्मीद है कि वह JavaScript जैसी capabilities देते हुए Python developers के लिए आसानी से इस्तेमाल होने वाला standardized serverless API बनाने की शुरुआत करेगा

आगे की दिशा

  • किसी नई programming language को सही तरीके से support करने के लिए “hello world” से कहीं बड़ा investment चाहिए
  • Stack Overflow 2023 survey के अनुसार Python, JavaScript के बाद सबसे ज़्यादा इस्तेमाल की जाने वाली language है
  • Cloudflare ने कहा कि वह Python Workers की performance में लगातार सुधार करेगा और Python package support का दायरा बढ़ाएगा
  • feedback channels हैं Cloudflare Developers Discord का Python Workers channel और workerd GitHub discussion

संबंधित पढ़ाई

1 टिप्पणियां

 
GN⁺ 2024-04-03
Hacker News की राय

  • खुशी है कि Cloudflare Edge पर WebAssembly के जरिए Python चलाने पर ज़्यादा ध्यान दे रहा है
    Wasmer में Edge पर WebAssembly-आधारित Python execution पर काम करने के अनुभव से संक्षेप में कहूं, तो Cloudflare Workers Edge पर Python सक्षम करने के लिए Pyodide का इस्तेमाल करता है, जो Emscripten के जरिए WebAssembly में compile किया गया Python है
    इसकी संरचना Pyodide को Workerd के साथ bundle करने और V8 snapshots से startup time घटाने की है; सबसे अच्छी स्थिति में Python cold start करीब 1 सेकंड है
    हालांकि मौजूदा तरीका Workerd में embedded Python/Pyodide version से बंधा है, और package resolution भी Workerd से कसकर coupled है, इसलिए runtime पर संभवतः केवल पहले से compiled native packages ही allow होंगे। उदाहरण के लिए, numpy के किसी खास version का इस्तेमाल मुश्किल हो सकता है
    संरचनात्मक रूप से यह JS/V8 world से बंधा है, इसलिए मौजूदा architecture के साथ 100ms से कम startup time हासिल करना मुश्किल लगता है
    फिर भी इस release का स्वागत है, और उम्मीद है कि लोग शानदार apps बनाएंगे
    https://pyodide.org/
    https://github.com/cloudflare/workerd/blob/main/docs/pyodide...
    https://github.com/cloudflare/workerd/pull/1875
    संपादन: Cloudflare टीम की व्याख्या को ध्यान में रखते हुए “proof of concept” को “release” में बदला

    • version management के तरीके पर आपका सारांश शायद गलतफहमी पर आधारित है। Pyodide/package versions compatibility date से नियंत्रित होते हैं, और production में कई versions को साथ-साथ support किया जा सकता है
      langchain या आपने जिस numpy का ज़िक्र किया, जैसे packages को हम काफी नियमित रूप से update करने की योजना रखते हैं
      अगर आप और समझा सकें कि V8 को limiting factor क्यों मानते हैं, तो अच्छा होगा। V8 एक शक्तिशाली WebAssembly runtime है, और planned optimizations में से ज़्यादातर underlying engine पर बहुत निर्भर नहीं हैं
      साथ ही, यह proof of concept नहीं बल्कि एक beta है जिसे लगातार बेहतर करते हुए GA तक ले जाया जाएगा
    • संदर्भ के लिए, Wasmer एक Edge product देता है जिसमें Cloudflare Workers पर Python चलाते समय बताए गए drawbacks नहीं हैं, और जो बहुत तेज़ cold start देता है
      https://wasmer.io/templates?language=python
    • आपने कहा कि “मौजूदा architecture के साथ 100ms से कम startup time मुश्किल होगा”; मुझे जिज्ञासा है कि 100ms से कम latency की ज़रूरत वाले Python workloads कौन चला रहा है
    • जानना चाहूंगा कि क्या यह architecture uvloop को support करता है

  • Cloudflare के पास hosting और database side पर बहुत अच्छी चीज़ें हैं, लेकिन developer platform के तौर पर इसकी marketing उतनी अच्छी नहीं रही, शायद इसलिए Vercel या Netlify ने काफी mindshare ले लिया
    अलग बात यह है कि मैं जानना चाहूंगा कि क्या Cloudflare Google Cloud Run जैसी language-agnostic container hosting service देता है

    • सहमत हूं कि marketing में कुछ दिक्कत है। शुरुआत में मैं Vercel और Netlify की ओर आकर्षित हुआ था, लेकिन लंबे समय तक इस्तेमाल करने के बाद दोनों से संतुष्ट नहीं रहा, फिर Cloudflare आज़माया और आखिरकार पसंद करने लगा
      pricing और product शानदार हैं
    • यह सिर्फ marketing की समस्या नहीं है। शुरुआत में मैं Cloudflare product line को लेकर optimistic था, लेकिन Next.js और Astro जैसे website generators के साथ compatibility में बड़ी समस्याएं आईं
      कुछ features बिल्कुल काम नहीं करते थे, और कुछ केवल आंशिक रूप से supported थे
      अगर कीमती developer time ऐसी समस्याएं सुलझाने में लगाना पड़े, तो Vercel, Netlify, Deno Deploy जैसे alternative platforms टीम की जरूरतों के लिए ज़्यादा smooth लगे, और infrastructure problems की बजाय development पर focus करना आसान था
    • Vercel और Netlify शायद developers को target नहीं करते। अगर आप developer हैं, तो Vercel और Netlify इस्तेमाल करना असल में overpriced service लेने जैसा है
      bandwidth cost ज़्यादातर cloud providers की तुलना में Vercel और Netlify पर 40–50 गुना महंगी है, और Cloudflare पर bandwidth लगभग cost नहीं बनती
      Edge function invocations भी Cloudflare की तुलना में Vercel और Netlify पर 6 गुना महंगे हैं। इसमें compute time cost शामिल नहीं है, जो Cloudflare पर free है
      Vercel के popular होने की लगभग इकलौती वजह यह है कि NextJS host करने के लिए वह सबसे अच्छी जगह है, और इसी वजह से शायद NextJS को दूसरी जगह deploy करना मुश्किल बनाया जाता है
    • मेरी जानकारी में हाल तक CloudFlare free tier काफी limited था। SQLite implementation D1 कल ही generally available हुआ, और read replicas भी announce हुए
    • Google Cloud Run जैसा कुछ नहीं है, लेकिन अगर हो तो वाकई अच्छा होगा
      मैं Workers को production में करीब 4 साल से इस्तेमाल कर रहा हूं और पसंद करता हूं, लेकिन मेरी ज़्यादातर apps अभी भी containers में चलती हैं

  • मैंने Cloudflare के सामने रखी site पर JS Workers इस्तेमाल किए हैं, और वे use करने में आसान और बहुत तेज़ थे। मैं site के पीछे की पूरी Django app को D1 database के साथ migrate करना चाहूंगा

    • मेरे साथ भी कुछ ऐसा ही है। मेरी कुछ mobile apps Cloudflare Workers और KV/D1 का इस्तेमाल करती हैं, और अनुभव बहुत अच्छा रहा
      traffic कम है इसलिए free tier पर ही हूं, लेकिन बनाना इतना आसान था कि मैं खुशी से पैसे देने को भी तैयार हूं
    • सहमत हूं, यह सच में शानदार दिखता है। अभी Django/DRF support नहीं है, लेकिन कहा गया है कि आगे packages की संख्या बढ़ाई जाएगी
    • site के पीछे की पूरी Django app को D1 तक इस्तेमाल करके migrate करना क्या समझदारी है? एक DDoS attack ही आपका budget बिगाड़ सकता है

  • JS Worker के साथ performance comparison हो तो मदद मिलेगी। दिलचस्प है, लेकिन कई layers जुड़ी हुई हैं, इसलिए संभावित रूप से धीमा भी लग सकता है
    बराबर performance की उम्मीद नहीं है, लेकिन roughly trade-offs पता चलें तो अच्छा होगा

    • Performance के तीन पहलू हैं: cold start performance, cold start के बाद की performance, JS और WebAssembly के बीच bridge cost, और WebAssembly में चलने वाले Python interpreter की speed
      अभी Python cold start समान size के JavaScript Worker से धीमा है। JavaScript में लिखा basic “Hello World” Worker cold start time में लगभग 0 के करीब है, जबकि Python Worker 1 second से कम है
      वजह यह है कि request आने पर Pyodide को Worker में on-demand load करना पड़ता है, और blog post में इसे कम करने के लिए Pyodide को पहले से available कराने का काम बताया गया है
      हालांकि Python Worker का cold start खत्म होने के बाद फर्क edge case जैसा हो जाता है, और request के दौरान क्या हो रहा है उस पर निर्भर करके कुछ milliseconds का हो सकता है
      JavaScript और WebAssembly के बीच “bridge” पार करते समय, जैसे input/output या async काम करते समय, थोड़ा cost होता है। लेकिन इसे milliseconds नहीं, microseconds के स्तर पर सोचना चाहिए, और आम तौर पर यह बहुत छोटा होता है
      Performance-sensitive Worker लिखने वाले लोग पहले से Rust में भी लिखते हैं: https://github.com/cloudflare/workers-rs यह भी JavaScript और WebAssembly के बीच bridge पर निर्भर करता है
      Pyodide का WebAssembly-based Python interpreter उतना तेज नहीं है जितना V8 में JavaScript को fast बनाने के लिए वर्षों में बने optimizations। फिर भी Pyodide, V8 के JS engine की तुलना में अभी शुरुआती stage में है, और कुछ जगहें हैं जहां बड़ा performance improvement संभव दिखता है। Performance improvements को upstream में शामिल करना चाहते हैं, और कुछ मददगार WebAssembly proposals भी हैं
    • Experience के हिसाब से तो यह बहुत fast लगता है

  • Isolation दिखाने के लिए lzma चुनना जानबूझकर था या पिछले हफ्ते की tech news की वजह से बस संयोग था, यह जानना चाहूंगा
    https://news.ycombinator.com/item?id=39865810

    • बस इसलिए शामिल किया क्योंकि यह standard library में है। Timing पूरी तरह संयोग है, लेकिन Wasm इस्तेमाल करने पर isolation guarantee मिलती है, यह अच्छी बात है :-)

  • Cloudflare पर AI-related workloads चलाने के लिए यह काफी game changer हो सकता है। इसका काफी समय से इंतजार था

    • निश्चित रूप से ऐसा ही intended लगता है
      अगर अभी तक नहीं देखा है तो आज की बाकी दो announcements भी देखना ठीक रहेगा
      “Leveling up Workers AI: General Availability and more new capabilities”
      https://blog.cloudflare.com/workers-ai-ga-huggingface-loras-...
      “Running fine-tuned models on Workers AI with LoRAs”
      https://blog.cloudflare.com/fine-tuned-inference-with-loras
    • जानना चाहूंगा कि Worker का maximum runtime कितना हो सकता है। AWS Lambda से इसकी तुलना कैसे होती है, या यह पूरी तरह अलग चीज है?

  • आज इस्तेमाल करके देखा, अच्छा लगा और बहुत जल्दी execution तक पहुंच गया
    हालांकि यह जानना चाहूंगा कि local development environment को CFW के Python implementation में built-in libraries समझाने के लिए क्या करना चाहिए
    उदाहरण के लिए asgi library है, और मैं चाहता हूं कि linter इसे unknown के रूप में mark न करे। लेकिन यह library सिर्फ on_fetch handler के runtime पर मौजूद होती है और local dev machine पर वास्तव में नहीं होती, इसलिए कोई workaround नहीं मिल पाया

  • Static sites के लिए CF Pages इस्तेमाल करके अच्छे results मिले हैं, और open-source LLM को service की तरह उपलब्ध कराने वाले Cloudflare products भी दिलचस्प हैं
    Cloudflare पर और ज्यादा चीजें बनाने से रोकने वाली मुख्य वजह Python support की कमी थी, और इस feature को आजमाने का इंतजार है

    • मैं भी CF Pages और कुछ Worker functions इस्तेमाल कर रहा हूं, और Cloudflare ecosystem सच में अच्छा है
      जल्दी कुछ run करना आसान है, और infrastructure की ज्यादा चिंता नहीं करनी पड़ती
      Python जोड़ना बहुत स्वागतयोग्य है, और Go भी first-class support के रूप में आ जाए तो अच्छा होगा

  • सिर्फ Pyodide packages का उपयोग करने की पाबंदी non-trivial builds में कैसे काम करेगी, यह जानना चाहूंगा
    Pure Python न होने वाला code काफी है, और real production apps support करने के लिए बहुत सी चीजों को manually rebuild करना पड़ेगा
    Cloudflare का adoption शायद ज्यादा packages को लाने में मदद कर सकता है, और अगर यहां 80/20 rule सही बैठता है तो यह काफी ठीक हो सकता है

    • यहां निश्चित रूप से 80/20 rule है, ऐसा लगता है। ज्यादातर packages को port करना इतना मुश्किल नहीं होता, और जिनका build मुश्किल होता है वे आम तौर पर threads और multiprocessing, graphics card, raw sockets, green threads जैसे features इस्तेमाल करते हैं जिनका WebAssembly runtime में कोई स्पष्ट counterpart नहीं है
      Blog post में भी कहा गया है कि सबसे बड़ी समस्या server और request-related packages support की है। Cloudflare Workers में वे निश्चित रूप से useful हैं, लेकिन raw sockets और किसी न किसी तरह की concurrency अक्सर इस्तेमाल करते हैं, इसलिए port करना मुश्किल होता है

  • अच्छा होगा अगर CloudFlare JS Workers से बंधे न होने वाले general-purpose API के साथ WASM को first-class target बनाने वाले Workers implement करे
    अभी भी WASM code deploy किया जा सकता है, इसलिए practically कोई भी language इस्तेमाल की जा सकती है, लेकिन यह native नहीं है, JS context के अंदर चलता है
    Deployment में थोड़ा overhead और awkwardness है
    मुझे लगता है कि आखिरकार सभी services containers में नहीं, बल्कि securitized WASM runtime पर सीधे deploy होंगी। यह images से containers की ओर हुए transition जैसा होगा
    फिलहाल Cloudflare Edge पर Rust जैसी चीज इस्तेमाल करने का फायदा बहुत बड़ा नहीं है। Performance advantage का काफी हिस्सा overhead और startup time से offset हो जाता है
    उदाहरण: https://github.com/WasmEdge/WasmEdge