WebAssembly يخرج من المتصفح: الآن يعمل داخل Shopify وCloudflare وفي Kubernetes

أُطلق WebAssembly في 2017 كحل لمشكلة المتصفح: كان JavaScript بطيئاً جداً للتعليمات الحساسة للأداء، والإضافات الأصلية خطيرة جداً. الجواب كان صيغة ثنائية مضغوطة تعمل ككود شبه أصلي ضمن بيئة متصفح معزولة — بأمان وبسرعة. نجح ذلك. انتقل محررو الفيديو، وأدوات CAD، والمحاكيات العلمية إلى الويب. تحسن أداء Figma ثلاثة أضعاف بعد ترحيل محرك الرسوميات إلى C++ وتجميعه إلى WASM.

ثم حدث شيء غير متوقع. بدأ المهندسون يتساءلون: هل يمكن لصيغة ثنائية سريعة ومعزولة ومستقلة عن اللغة أن تفيد خارج المتصفح؟ الإجابة كانت نعم، والنظام البيئي الذي نما حول هذه الإجابة ناضج الآن للاستخدام في الإنتاج.

نموذج المكونات: القطعة المفقودة التي وصلت

كان لمواصفات WebAssembly الأصلية قيد أساسي للاستخدام على الخادم: وحدتا WASM مترجمتان من لغتين مختلفتين لا تستطيعان الاتصال ببعضهما دون كود ربط يدوي مكلف وعرضة للأخطاء. كانت مكتبة Rust وخدمة Go تعيشان في مساحات ذاكرة منفصلة دون نظام أنواع مشترك. هذا جعل الهندسة متعددة اللغات القابلة للتجميع غير عملية.

نموذج المكونات في WebAssembly، الذي استقر في 2025، يحل هذه المشكلة بواجهة ثنائية مشتركة للتطبيقات ولغة وصف واجهة مستقلة عن اللغة اسمها WIT (أنواع واجهة WebAssembly). ملف WIT يصرح بالدوال وأنواع البيانات التي يصدرها أو يستوردها المكون، دون افتراضات ذاكرة مرتبطة بلغة معينة. سلسلة الأدوات — wit-bindgen، wasm-tools، jco — تولد كود التكامل تلقائياً. النتيجة العملية: محلل Rust عالي الأداء، خط أنابيب Machine Learning بلغة Python، وواجهة أمامية TypeScript يمكنها التأليف كمكونات WASM دون أي FFI مكتوب يدوياً. صادق معيار WASM 3.0 كمعيار W3C في سبتمبر 2025، مضيفاً جمع القمامة، ذاكرة 64 بت، SIMD مخفف، ومعالجة الاستثناءات إلى جانب نموذج المكونات.

WASI: طبقة الواجهة التي تجعل قابلية النقل حقيقية

تشغيل WASM خارج المتصفح يتطلب وسيلة للوحدة للتفاعل مع النظام المضيف — قراءة الملفات، فتح مآخذ الشبكة، الكتابة إلى الخرج القياسي. واجهة نظام WebAssembly (WASI) تعرّف هذه الواجهات البرمجية ضمن نموذج أمان قائم على الصلاحيات: الوحدة تحصل فقط على الوصول الذي يُمنح صراحة وقت التثبيت. لا شيء آخر يمكن الوصول إليه.

WASI 0.2، الصادر في يناير 2024، ثبّت خط الأساس المستقر للإنتاج — إدخال/إخراج الملفات، مآخذ الشبكة، والتكامل مع نموذج المكونات. WASI 0.3، الذي يضيف دعماً أصلياً لـ async مع Streams وFutures ذات الأنواع، كان في طور إنهاء العمل على المواصفات في أوائل 2026. الإصدار 1.0 — أول إصدار "مستقر للأبد" — متوقع في أواخر 2026 أو أوائل 2027. هذا المسار يعطي مؤلفي المكتبات واجهة ABI مستقرة يستهدفونها، والمشغلين خارطة طريق واضحة لضمانات قابلية النقل التي ستغطيها في النهاية.

أين توجد عمليات الإنتاج الفعلية

أكثر دليل ملموس على نطاق واسع هو Shopify Functions. منذ 2022، يسمح Shopify للمطورين من الغير بتخصيص منطق الدفع والخصم والشحن عن طريق نشر وحدات WASM تعمل ضمن بيئة تشغيل مخصصة داخل بنية Shopify. كل وحدة تنفذ ضمن ميزانية زمنية صارمة تبلغ 5 ملي ثانية؛ زمن الاستجابة المقاس يتراوح بين 0.8 و2.5 ملي ثانية. المطورون يكتبون بلغة Rust، JavaScript (عبر مترجم Shopify Javy الذي يحزم محرك V8 مصغراً في ملف WASM ثنائي)، Zig، أو TinyGo. حاجز الأمان مهم: كود التجار غير الموثوق يعمل في إنتاجية Shopify دون الوصول إلى موارد النظام المضيف. لم يحدث أي اختراق للعزلة. بحلول يونيو 2026، تم إيقاف نظام Scripts القديم الذي استبدلته Functions بالكامل.

على صعيد الحوسبة الطرفية، منصة Compute@Edge من Fastly هي بيئة تشغيل WASM خالصة تقدم بدء بارد بالمايكروثانية لمعالجة الطلبات على حافة الشبكة. Cloudflare Workers تدعم وحدات WASM وأضافت دعم الحاويات في يونيو 2025 للمهام المختلطة. أقوى إشارة من الصناعة جاءت في أواخر 2025 عندما استحوذت Akamai على Fermyon — الشركة وراء إطار Spin لخدمات WASM الصغيرة دون خادم — وأطلقت Fermyon Wasm Functions بحالة التوفر العام على شبكة Akamai الموزعة عالمياً في نوفمبر 2025. عندما تستحوذ أكبر شبكة CDN على الكوكب على شركة WASM لاخدمات دون خادم، يصبح الرهان على مستقبل التقنية مؤسسياً وليس تجريبياً.

مشهد بيئات التشغيل

أربع بيئات تشغيل تهيمن حسب حالات الاستخدام. Wasmtime، مرجع التنفيذ من Bytecode Alliance، حصل على وضع المشروع الأساسي في أبريل 2025 ويحقق حوالي 82% من الأداء الأصلي في معايير الحوسبة. وهو الخيار الافتراضي لـ WASM العام على جانب الخادم. Wasmer 6.0، الصادر في أبريل 2025، يدّعي 95% أداءً أصلياً وقدم Edge.js الذي يشغل تطبيقات Node.js داخل حاضنة WASM — جسر مثير للفرق التي لديها بنية Node موجودة. WAMR (بيئة تشغيل WebAssembly الصغيرة) يستهدف الأجهزة المضمنة وإنترنت الأشياء، ويعمل على أجهزة بذاكرة صغيرة تصل إلى 256 كيلوبايت مع أداء يتراوح بين 80 و90% من الأصلي باستخدام التجميع المسبق. WasmEdge محسّن لأعباء العمل AI ويتكامل مع Docker Engine كحاجز حاويات إلى جانب Wasmtime.

تأطير Docker مقصود: "WASM والحاويات"، لا "WASM مقابل الحاويات". محرك Docker يأتي مع حواجز أصلية لـ Wasmtime وWasmEdge، لذا يمكن نشر وحدات WASM باستخدام أوامر docker run القياسية من ملف Dockerfile من الصفر. سلسلة الأدوات تتقارب بدلاً من التنافس. SpinKube، مشروع CNCF مبني على إطار Spin من Fermyon، يجعل WASM نوع عبء عمل من الدرجة الأولى في Kubernetes — يمكن نشره جنباً إلى جنب مع حاويات Pods بنفس أدوات التنسيق.

حجة الأمان

نموذج أمان WASM هو "منع افتراضياً" على المستوى الثنائي. الوحدة لا تملك أي وصول إلى النظام المضيف إلا إذا منحها المضيف صلاحية محددة صراحة وقت التثبيت. هذا يختلف معمارياً عن الحاويات، التي تشارك نواة المضيف وتعتمد على عزل Namespaces وCgroups لتحديد ما يمكن لعبء العمل الوصول إليه. في WASM، تُفرض الحاضنة في بيئة التشغيل، بغض النظر عن اللغة التي صدر منها المكون.

بالنسبة للمنصات متعددة المستأجرين — نموذج Shopify، حيث ينشر مئات آلاف التجار كوداً مخصصاً — هذه هي الميزة التي تجعل البنية قابلة للاستمرار. البديل هو فحص كل قطعة كود من الغير قبل النشر، وهذا غير ممكن على نطاق واسع. حاضنة WASM تقضي على فئة المخاطر بدلاً من إدارتها.

الصورة الصادقة للأداء

WASM على بيئات تشغيل الخادم يعمل بحوالي 75 إلى 95% من السرعة الأصلية في أعباء العمل كثيفة الحوسبة — أرقام مقبولة لمعظم حالات الاستخدام، مع تحفظات. العمليات التي تتضمن أعداداً صحيحة 128 بت وبعض الأساسيات التشفيرية أبطأ بمقدار 2 إلى 7 مرات من الأصلية. أعباء العمل التي تعتمد على الإدخال/الإخراج لا ترى فائدة كبيرة؛ الميزة هي في الحوسبة. البداية الباردة تتراوح من 1 إلى 5 ملي ثانية، مقارنة بـ 50 إلى 500 ملي ثانية للحاويات — هذا هو الرقم الذي يجعل WASM جذاباً للنشر دون خادم والحوسبة الطرفية حيث يؤثر زمن البدء البارد مباشرة على تجربة المستخدم.

وقت التطوير أطول بالتأكيد. البناء بلغة Rust لـ WASM يتطلب فهم إدارة الذاكرة وسير عمل تصحيح مختلف عن معظم مطوري الويب. تحسن نموذج المكونات وسلسلة أدوات WASI بشكل ملحوظ لكن تصحيح الأخطاء عبر حدود اللغات يظل أصعب من التصحيح ضمن كومة بلغة واحدة. النظام البيئي تقريباً في المكان الذي كانت فيه JavaScript في سنوات Node.js المبكرة: قوي ومنتج ويتطلب استثماراً لاستخدامه جيداً.

سؤال "هل يجب أن أستخدم WASM بدلاً من الحاويات؟" له إجابة أوضح في 2026 مما كانت عليه قبل عامين: استخدم WASM عندما يكون زمن البدء البارد مهماً (الحافة وبدون خادم)، وعندما تحتاج إلى تنفيذ آمن لكود غير موثوق، أو عندما تريد تركيب مكونات مستقلة عن اللغة. استخدم الحاويات عندما تحتاج إلى بيئة Linux كاملة، وتوافق مكتبات واسع، أو وصول GPU. استخدم كليهما عندما يحتوي عبء العمل على طبقات تستفيد من كل منهما — وهذا ما تصمم أدوات البنية التحتية لدعمه بشكل متزايد.