WebAssembly مهم‌ترین کاربردش را بیرون از مرورگر پیدا کرد

وقتی WebAssembly در سال ۲۰۱۷ به مرورگرهای اصلی آمد، قولش ساده بود: کد native را در مرورگر بدون JavaScript اجرا کن. اولی‌ها موتورهای بازی C++، مفسرهای Python و کتابخانه‌های پردازش تصویر را به وب آوردند. کار کرد، اما استفاده‌اش محدود بود — بیشتر برنامه‌های وب نیاز به سرعت C نداشتند و اکوسیستم JavaScript آنقدر عمیق بود که WASM به‌ندرت جایگزینش می‌شد.

اما کاربرد واقعی‌اش بیرون از مرورگر بود. دو سال گذشته، WebAssembly به یک Runtime قابل اعتماد برای سه زمینه سمت سرور تبدیل شده: توابع Serverless، سیستم‌های Plugin و Edge Computing. جایی که مدل امنیتی و قابلیت حملش از عملکرد خام مهم‌ترند.

ویژگی‌ای که WASM را روی سرور متفاوت می‌کند

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

مقایسه کنید با مشکل سنتی Plugin. وقتی می‌خواهید کد شخص ثالث را در برنامه‌تان اجرا کنید — یک Plugin، Extension یا تابع تعریف‌شده توسط کاربر — گزینه‌ها همیشه دردسرساز بوده‌اند. یا باید به توسعه‌دهنده Plugin اعتماد کنید و پروسه را در معرض باگ یا کد مخرب قرار دهید، یا Plugin را در یک زیرپروسه با سربار IPC کامل اجرا کنید، یا یک Whitelisting پیچیده برای قابلیت‌ها پیاده کنید که خاص Runtime و سخت برای ممیزی است. WASM این را با یک primitve ساده حل می‌کند: ماژول‌ها در Sandbox خودشان اجرا می‌شوند و شما دقیقاً تعیین می‌کنید از طریق یک رابط تایپ‌شده به چه توابع میزبان دسترسی داشته باشند.

توابع Serverless: مزیت Cold-Start

Cloudflare Workers یکی از اولین شرط‌بندی‌های تولیدی روی WASM برای Serverless بود. Workers در V8 isolateهای شبکه لبه Cloudflare، JavaScript و WASM را اجرا می‌کنند و ادعای اصلی‌شان این است که زمان Cold-Start به شدت کاهش می‌یابد چون ماژول‌های WASM نیازی به بوت کردن سیستم عامل ندارند. Cloudflare گزارش می‌دهد median Cold-Start زیر ۵ میلی‌ثانیه برای فراخوانی Workerها، در مقابل ۱۰۰ تا ۵۰۰ میلی‌ثانیه برای توابع Lambda مبتنی بر Container.

Fastly هم با پلتفرم Computeاش رویکرد مشابهی گرفت که exclusively WASM اجرا می‌کند و آن را جایگزین VCL (Varnish Configuration Language) می‌داند. توسعه‌دهندگان به Rust، Go، JavaScript یا هر زبان WASM-target بنویسند، به ماژول کامپایل کنند و به عنوان سرویس Fastly مستقر کنند — بدون Container، بدون ظرفیت Provisioned، بدون مدیریت Cold-Start.

Framework Spin از Fermyon این رویکرد را به توسعه اپلیکیشن عمومی گسترش می‌دهد. Spin به شما اجازه می‌دهد میکروسرویس‌هایی بسازید که به WASM کامپایل می‌شوند و بدون Container یا Kubernetes اجرا می‌شوند. هر تابع یک ماژول است که در میلی‌ثانیه شروع می‌شود، درخواست را پردازش می‌کند و خاتمه می‌یابد. خبری از Warm Container Pool، Sidecar Infrastructure یا Container Image Registry نیست.

سیستم‌های Plugin: جایی که مدل امنیتی جواب می‌دهد

Extism یک Plugin Development Kit متن‌باز است که با WASM به توسعه‌دهندگان اجازه می‌دهد کد شخص ثالث را ایمن جاسازی کنند. به جای اینکه Pluginها به زبان میزبان نوشته شوند، Extism اجازه می‌دهد از هر زبانی که WASM را هدف قرار می‌دهد — Go، Rust، Python، JavaScript — کامپایل شوند. میزبان یک رابط تایپ‌شده کوچک تعریف می‌کند؛ Plugin فقط از طریق آن رابط ارتباط برقرار می‌کند. یک Plugin باگ‌دار یا مخرب نمی‌تواند از Sandbox خارج شود.

Grafana Labs این مدل را برای Pluginهای بک‌اند پذیرفت. انواع جدید Pluginهای Grafana به عنوان ماژول WASM داخل بک‌اند Grafana اجرا می‌شوند، از هم و از پروسه Grafana ایزوله. این کار یک دسته از حملات زنجیره تأمین را حذف می‌کند که در آن یک Plugin آلوده دسترسی کامل به پروسه پیدا می‌کند — نگرانی واقعی در اکوسیستمی با صدها مشارکت شخص ثالث.

Envoy Proxy به همین دلیل پشتیبانی از Extension WASM را اضافه کرد: crash یک ماژول WASM باعث از کار افتادن پروسه Proxy یا ترافیک عبوری از Extensionهای دیگر نمی‌شود. برای زیرساخت Edge که باید همیشه بالا بماند، این ایزولاسیون خطا از عملکرد خام مهم‌تر است.

Component Model: قطعه گمشده‌ای که حالا می‌آید

مهم‌ترین توسعه اخیر اکوسیستم WASM، Component Model است که در WASI 0.2 در اوایل ۲۰۲۴ معرفی شد. قبلاً ماژول‌های WASM از طریق بافرهای حافظه مشترک ارتباط برقرار می‌کردند — سطح پایین و مستعد خطا. Component Model رابط‌های تایپ‌شده‌ای معرفی می‌کند که ماژول‌ها می‌توانند پیاده‌سازی و مصرف کنند و ترکیب بدون حافظه مشترک را ممکن می‌سازد.

به زبان ساده، می‌توانید یک رابط تایپ‌شده تعریف کنید و Pluginها فارغ از زبان مبدأشان آن را پیاده کنند. یک هاست Rust می‌تواند یک Plugin Python یا Go را از طریق همان رابط تایپ‌شده فراخوانی کند و Runtime WASM ترجمه را انجام دهد. این بزرگ‌ترین نقطه اصطکاک در سیستم‌های Plugin WASM را حل می‌کند: نیاز به FFI Binding یا Runtime مشترک.

Bytecode Alliance — متشکل از Mozilla، Intel، Fastly، Microsoft و Google — سازمان اصلی پیشبرد WASM خارج از مرورگر بوده است. Runtime Wasmtime آنها پیاده‌سازی مرجع WASI 0.2 است و بیشتر استقرارهای تولیدی روی آن ساخته شده‌اند.

محدودیت‌های فعلی که باید بدانید

WASM خارج از مرورگر برای workloadهای خاص آماده تولید است اما به طور کلی بالغ نیست. Threading نیاز به حافظه مشترک دارد که با مدل ایزولاسیون بیشتر Runtimeهای Serverless در تضاد است — بنابراین بیشتر استقرارها تک‌رشته‌ای هستند و workloadهای قابل اجرا محدود می‌شوند. WASM GC (Garbage Collection) که به Runtimeهای زبان‌های managed اجازه می‌دهد بدون بستن GC خودشان به WASM کامپایل شوند، فقط در اواخر ۲۰۲۳ در مرورگرهای اصلی ارائه شد و هنوز در Runtimeهای سرور پشتیبانی گسترده ندارد. کیفیت Toolchain متفاوت است: Rust و Go بالغ‌ترین اهداف WASM را دارند؛ Python و JavaScript کار می‌کنند اما با پیچیدگی عملیاتی بیشتر.

برای توسعه‌دهندگانی که پلتفرم‌هایی می‌سازند که کد شخص ثالث را می‌پذیرند — API Gateway، ابزارهای اتوماسیون، محصولات Observability، بازارهای توسعه‌دهنده — WASM اکنون یک گزینه معماری جدی برای لایه Plugin است. مدل امنیتی واقعی است، عملکرد برای workloadهای محدود به درخواست قابل قبول است و Component Model ترکیب بین زبانی را عملی می‌کند. موارد استفاده سمت سرور جایی است که ویژگی‌های معماری WASM به وضوح از گزینه‌های جایگزین متمایز می‌شود.