WebAssembly بزرگ شد: WASI 0.2، Component Model و WASM سمت سرور در تولید

WebAssembly اول برای اجرای C++ در مرورگر سریع‌تر از JavaScript ساخته شد. تا ۲۰۲۶، این کم‌اهمیت‌ترین نکته درباره‌اش است. WASI 0.2، Component Model و یک اکوسیستم رو به رشد از runtimeهای سمت سرور، WASM را به یک هدف محاسباتی معتبر تبدیل کرده‌اند — زبان‌ناشناس، به‌طور پیش‌فرض sandboxed و در حال به چالش کشیدن deploymentهای مبتنی بر کانتینر در edge computing.

WASI 0.2 دقیقاً چه چیزی را تغییر داد

WebAssembly System Interface (WASI) مشخصه‌ای است که به ماژول‌های WASM اجازه می‌دهد با دنیای خارج ارتباط برقرار کنند — فایل‌سیستم، سوکت‌های شبکه، کلاک‌ها، تولید اعداد تصادفی. قبل از WASI، WASM در مرورگر می‌توانست محاسبات انجام دهد اما به سیستم‌عامل دسترسی نداشت. WASI همان چیزی است که WebAssembly سمت سرور را ممکن می‌کند.

WASI 0.2 که در فوریه ۲۰۲۴ توسط Bytecode Alliance نهایی شد، دو تغییر اساسی ایجاد کرد. اول، Component Model را استاندارد کرد — که نحوه نمایش interfaceهای تایپ‌دار توسط ماژول‌های WASM با استفاده از WIT (WebAssembly Interface Types) و ترکیب آن‌ها با یکدیگر را تعریف می‌کند. دوم، wasi:http را معرفی کرد، یک interface HTTP استاندارد که به برنامه‌های WASM اجازه می‌دهد درخواست‌های وب را بدون shimهای مختص پلتفرم مدیریت کنند.

اثر عملی: یک کامپوننت WASM نوشته شده در Rust، Go، Python یا C می‌تواند یک interface تایپ‌دار را ارائه دهد که کامپوننت دیگر — احتمالاً نوشته شده در یک زبان کاملاً متفاوت — می‌تواند آن را فراخوانی کند. هم‌کنش زبانی بدون پیچیدگی FFI.

Component Model: ماژول‌هایی که ترکیب می‌شوند

قبل از Component Model، تنها نوع داده‌ای که از مرز ماژول عبور می‌کرد بایت‌های خام (linear memory) بود. فراخوانی یک ماژول WASM ریستی از یک ماژول WASM پایتون نیازمند serialization سفارشی در هر دو طرف بود. Component Model یک سیستم نوع غنی‌تر در مرز ماژول معرفی می‌کند — رشته‌ها، لیست‌ها، recordها، variantها — که در فایل‌های interface WIT تعریف می‌شوند.

این کار WASM چندزبانه را عملی می‌کند. یک Pipeline پردازش داده ممکن است از یک کامپوننت Rust برای پارسینگ (عملکرد)، یک کامپوننت Python برای inference Machine Learning (سازگاری اکوسیستم) و یک کامپوننت JavaScript برای تبدیل JSON (کتابخانه‌های موجود) استفاده کند، همه در یک برنامه WASM واحد با handoffهای تایپ‌دار بین آن‌ها ترکیب شوند. CLI wasm-tools compose و زنجیره ابزار cargo component ابزارهای فعلی توسعه‌دهنده هستند. اکوسیستم اولیه اما کاربردی است — runtimeهای اصلی WASM روی این مشخصه هم‌راستا هستند.

Runtimeهای سمت سرور: Wasmtime، WasmEdge، Wasmer

Wasmtime (Bytecode Alliance) runtime مرجع برای انطباق با WASI است. نوشته شده در Rust، با استفاده از Cranelift برای JIT compilation، اولویت آن انطباق با مشخصه و ایزولاسیون امنیتی است. پلتفرم Compute فستلی روی Wasmtime اجرا می‌شود و ترافیک تولیدی را در مقیاس پردازش می‌کند.

WasmEdge (پروژه CNCF) برای استقرار cloud-native و edge بهینه شده است. با Kubernetes از طریق containerd-wasm-shims یکپارچه می‌شود، از inference LLM مبتنی بر GGML در WASM پشتیبانی می‌کند و در Envoy proxy برای قابلیت گسترش پلاگین مبتنی بر WASM استفاده می‌شود — یک مورد استفاده تولیدی بزرگ.

Wasmer تجربه توسعه‌دهنده را با گسترده‌ترین پشتیبانی SDK زبان اولویت می‌دهد: bindingهای Python، JavaScript، Go، PHP، Ruby. Wasmer همچنین Wasmer.io را اداره می‌کند، یک رجیستری بسته WASM مشابه npm اما برای توزیع ماژول‌های WASM مستقل از پلتفرم.

جایی که WASM برنده است

سه الگوی استقرار ظهور کرده‌اند که در آن‌ها WASM واقعاً از جایگزین‌ها بهتر عمل می‌کند:

Edge compute: Cloudflare Workers JavaScript و WASM را در بیش از ۳۰۰ موقعیت edge در سراسر جهان اجرا می‌کند. Fastly Compute به‌طور مستقیم WASM را اجرا می‌کند. مزیت cold start تعیین‌کننده است — یک ماژول WASM در میکروثانیه شروع به کار می‌کند در مقابل صدها میلی‌ثانیه برای یک کانتینر. برای توابع edge حساس به تأخیر، این تفاوت بین یک تأخیر قابل‌درک و هیچ است.

سیستم‌های پلاگین: نرم‌افزاری که نیاز به گسترش‌پذیری بدون خطر امنیتی پلاگین‌های کد بومی دارد، WASM را به عنوان میزبان پلاگین sandboxed پذیرفته است. Envoy proxy از WASM برای سیستم گسترش خود استفاده می‌کند. Zellij (مدیر terminal) پلاگین‌ها را به عنوان WASM اجرا می‌کند. مدل ایزولاسیون ویژگی کلیدی است: یک پلاگین WASM نمی‌تواند بدون grantهای صریح قابلیت، به حافظه میزبان یا syscallها دسترسی داشته باشد، که اجرای کد پلاگین غیرقابل‌اعتماد را ایمن می‌کند.

ML inference در مرورگر: WebLLM مدل‌های LLM quantized شده — Llama 3، Phi-3، Mistral — را در مرورگر از طریق WASM ترکیب با WebGPU برای دسترسی به GPU اجرا می‌کند. این ترکیب امکان اجرای مدل‌های ۳B تا ۷B پارامتری را در سمت کلاینت بدون سرور فراهم می‌کند، که قابلیت آفلاین و حذف داده‌های ارسالی به APIهای خارجی را ممکن می‌سازد.

جایی که WASM همچنان بازنده است

WASM در بارهای کاری عمومی سرور برنده نیست. یک سرور HTTP Go یا Node.js که در یک کانتینر اجرا می‌شود هنوز به اندازه کافی سریع شروع به کار می‌کند، ابزارهای بالغ دارد و نیاز به پیچیدگی اهداف compilation WASM و تعاریف interface WIT ندارد. اکوسیستم هنوز اولیه است — بیشتر کتابخانه‌ها به WASM منتقل نشده‌اند و دیباگ کردن WASM کامپایل شده به طور قابل توجهی سخت‌تر از دیباگ کد بومی است.

داستان شبکه نیز ناقص است. WASI 0.2 دارای wasi:http است اما هنوز یک wasi:sockets پایدار برای TCP/UDP دلخواه ندارد. برنامه‌هایی که نیاز به دسترسی خام سوکت دارند — دیتابیس‌ها، پروتکل‌های سفارشی، شبکه‌های همتا به همتا — هنوز توسط WASM سمت سرور به خوبی پشتیبانی نمی‌شوند.

پشتیبانی زبان در ۲۰۲۶

اکوسیستم زبان در دو سال گذشته به طور قابل توجهی بالغ شده است:

• Rust: بهترین پشتیبانی. wasm-pack برای اهداف مرورگر، cargo component برای Component Model. پشتیبانی کامل WASI 0.2.
• Go: TinyGo برای WASI (Go استاندارد پشتیبانی آزمایشی WASM با برخی محدودیت‌های stdlib دارد). TinyGo باینری‌های کوچک تولید می‌کند اما از تمام ویژگی‌های کتابخانه استاندارد Go پشتیبانی نمی‌کند.
• Python: CPython از طریق Emscripten به WASM کامپایل می‌شود (Pyodide برای استفاده مرورگر). پروژه py-wasi به طور مستقیم‌تر WASM سرور را هدف قرار می‌دهد.
• JavaScript/TypeScript: SpiderMonkey کامپایل شده به WASM توسط Cloudflare برای اجرای sandboxهای JS قابل حمل استفاده می‌شود. ComponentizeJS جاوااسکریپت را به کامپوننت‌های WASM تبدیل می‌کند.
• C/C++: Emscripten مسیر بالغ باقی مانده است. wasi-sdk یک زنجیره ابزار مینیمال‌تر متمرکز بر WASI ارائه می‌دهد.
• Swift: هدف WASM آزمایشی در Swift 5.9 اضافه شد و تا ۲۰۲۵ به سرعت در حال بهبود است.

مقایسه با کانتینر

استدلال Bytecode Alliance برای WASM به جای کانتینر سه بعدی است: آرتیفکت‌های کوچک‌تر (یک ماژول WASM معمولاً کیلوبایت است، نه صدها مگابایت لایه کانتینر)، cold start سریع‌تر (میکروثانیه در مقابل صدها میلی‌ثانیه) و یک مدل ایزولاسیون قوی‌تر (امنیت مبتنی بر قابلیت WASM در مقابل بردارهای فرار کانتینر که به طور منظم در CVEها ظاهر می‌شوند).

برای سرویس‌های طولانی‌مدت که cold start مهم نیست و ابزارهای کانتینری موجود دارید، کانتینرها پاسخ درست هستند. برای function-as-a-service، edge compute و قابلیت گسترش پلاگین، مدل WASM واقعاً جذاب است — و به طور فزاینده، استقرارهای تولیدی آن را ثابت می‌کنند.

مسیر به WASI 0.3

WASI 0.3 در حال توسعه فعال است، با افزوده‌های اصلی wasi:sockets برای TCP/UDP، پشتیبانی I/O ناهمزمان و interfaceهای اضافی منابع سیستم. مشخصه Component Model نیز همچنان در حال تکامل است — سیستم نوع و ابزارهای ترکیب هنوز لبه‌های زبری دارند که Bytecode Alliance به طور فعال در حال صاف کردن آن‌هاست.

مسیر مشخص است: WASM دیگر یک کنجکاوی مرورگر یا یک پروژه تحقیقاتی نیست. در Cloudflare، Fastly و ده‌ها شرکت که از آن برای سیستم‌های پلاگین و بارهای کاری edge استفاده می‌کنند، در تولید است. انحصار runtime جاوااسکریپت در مرورگر در ۲۰۱۷ با عرضه WASM پایان یافت. انحصار کانتینر در محاسبات سرور دیواری است که WASM اکنون در حال بالا رفتن از آن است — و WASI 0.2 کلنگ است.