نموذج المكوّنات (Component Model) في WebAssembly يتحول إلى معيار الإضافات الذي لم يصوّت له أحد

لعقد كامل، كانت WebAssembly هي التقنية التي كانت دائمًا "على بُعد عام واحد" من أن تصبح ذات أهمية خارج المتصفح. ذلك العام قد حان أخيرًا. وفقًا لاستطلاع CNCF السنوي لعام 2026، تُشغّل الآن 38% من المؤسسات السحابية الأصلية أحمال عمل WebAssembly في بيئة الإنتاج، ارتفاعًا من 4% فقط في عام 2022. والسبب ليس تطبيقًا واحدًا حاسمًا. بل إن Component Model الخاص بـWebAssembly حلّ بهدوء مشكلة لم تستطع الحاويات، ولا الإضافات على شكل مكتبات مشتركة، ولا أي نهج عزل (sandboxing) سابق حلّها بشكل كامل: تشغيل كود غير موثوق ومتعدد اللغات بأمان، دون مخاطر الذاكرة المشتركة ودون العبء المرتبط بمستوى الحاويات.

ما الذي يحله Component Model فعليًا

كانت وحدات WebAssembly العادية قادرة بالفعل على تشغيل كود مكتوب بأي لغة تُترجم إلى WASM، معزولة عن المضيف (host). لكن تمرير بيانات معقدة بين الوحدات - نصوص (strings)، وstructs، وvariants - كان يتطلب إدارة يدوية للذاكرة عبر حدود الذاكرة الخطية (linear memory) في WASM، وهو أمر عرضة للأخطاء بقدر ما يبدو عليه. يستبدل Component Model ذلك بواجهة Canonical ABI: طريقة موحدة لوصف وتمرير أنواع بيانات غنية عبر حدود المكوّنات (components) دون أن يحتاج أي طرف لمعرفة لغة تنفيذ الطرف الآخر.

عمليًا، هذا يعني أن تطبيق مضيف مكتوب بلغة C# يمكنه تشغيل إضافة مكتوبة بلغة Rust، والتي تستدعي مكوّنًا مكتوبًا بلغة Python، والذي يبث بيانات إلى مكوّن مكتوب بلغة Go - مع فحص الأنواع (type-checked) وعزل الذاكرة في كل خطوة، دون أن تحتاج أي من هذه اللغات لمشاركة بيئة تشغيل (runtime) أو حتى معرفة اللغة التي كُتبت بها المكوّنات الأخرى. لغة WIT (اختصار WebAssembly Interface Type) هي المخطط الذي يجعل هذا ممكنًا: تُعرّف الواجهة مرة واحدة، وأي مكوّن يطبقها يصبح قابلًا للتبديل بغض النظر عن لغة المصدر.

من يستخدم هذا فعليًا في بيئة الإنتاج

هذا ليس فضولًا معمليًا. بنت American Express منصة داخلية للدوال كخدمة (function-as-a-service) فوق wasmCloud، مستخدمةً مكوّنات WASM التي يحافظ عليها المجتمع لدعم دوال مستقلة عن البنية الطوبولوجية عبر بنيتها التحتية بأكملها. واستحوذت Akamai على Fermyon (الشركة التي تقف خلف إطار عمل WASM المسمى Spin) ونشرت Spin عبر شبكة الحافة (edge) الخاصة بها بالكامل - ما يعني أن مكوّنات WASM، وليس الحاويات، هي الآن ما يقدّم حوسبة الحافة في بيئة الإنتاج لدى أحد أكبر مشغّلي شبكات CDN على الإنترنت. وانضم SpinKube، الطريقة الأصيلة الخاصة بـKubernetes لتشغيل أحمال عمل WASM، إلى CNCF Sandbox هذا العام، ما يُرسّخ نقطة الدخول للفرق التي تعمل بالفعل على Kubernetes وتريد إضافة WASM دون بناء حزمة بنية تحتية موازية.

بلغت wasmCloud نفسها مرتبة الحاضنة (incubator) في CNCF وأطلقت الإصدار 2.5 مع تفعيل دعم WASI Preview 3 افتراضيًا - وهو إنجاز مهم لأن Preview 3 يُدخل أنواع Future وStream الأصيلة مباشرة إلى مواصفات WIT، ما يتيح لأول مرة إدخال/إخراج (I/O) غير متزامن وغير حاجب عبر حدود المكوّنات. وقبل ذلك، كان الكود غير المتزامن العابر لحدود المكوّن يتطلب أنماط callback مرهقة؛ أما الآن فقد أصبح جزءًا أصيلًا من تعريف الواجهة.

لماذا تُعد أنظمة الإضافات تحديدًا حالة الاستخدام الرابحة

يوضّح Extism، وهو إطار عمل مصمم خصيصًا لأنظمة الإضافات، سبب انتشار هذا النمط بسرعة أكبر في سيناريوهات قابلية التوسيع مقارنة بالخدمات المصغّرة (microservices) العامة. إذا كنت تبني منتجًا يحتاج لتشغيل كود غير موثوق من طرف ثالث - نظام إضافات لمنصة CMS، أو خط أنابيب بيانات بخطوات تحويل مخصصة، أو طبقة برمجة نصية في محرك ألعاب - فأنت تحتاج إلى ثلاثة أمور في آن واحد: عزل (sandboxing) بحيث لا تستطيع إضافة معطوبة تعطيل المضيف أو اختراقه، ومرونة لغوية بحيث لا يكون مطورو الإضافات مقيّدين بلغة المضيف لديك، وأداء قريب من الأداء الأصلي (near-native) بحيث لا يُثقل العزل كل استدعاء. توفر الحاويات العزل، لكن بعبء على مستوى العملية (process) لا يناسب استدعاءات الإضافات الدقيقة. وتوفر لغات البرمجة النصية المدمجة (مثل Lua أو JavaScript-in-a-box) الأداء، لكنها تقيّد مطوري الإضافات بلغة واحدة. مكوّنات WASM هي أول نهج يحقق الأمور الثلاثة معًا بشكل حقيقي.

التحفظات الصادقة

أصبح WASM من جانب الخادم جاهزًا لبيئة الإنتاج لفئة محددة من أحمال العمل - دوال الحافة (edge functions)، وFaaS، وأنظمة الإضافات - لكنه ليس بعد بديلًا عامًا للخدمات المصغّرة. مزايا بدء التشغيل البارد (cold-start) مقارنة بالحاويات حقيقية، لكنها أضيق مما أوحى به التسويق المبكر بمجرد احتساب عبء إنشاء نسخ المكوّنات (instantiation) على نطاق واسع. أما الأدوات، ورغم تحسّنها الكبير مقارنة بما كانت عليه قبل عامين، فلا تزال تحمل بعض الخشونة: تصحيح أخطاء سلسلة مكوّنات متعددة اللغات أصعب من تصحيح أخطاء خدمة بلغة واحدة، وأدوات المراقبة (observability) المصممة لأحمال عمل الحاويات لا تنتقل دائمًا بسلاسة إلى هذا السياق.

ما الذي ينبغي فعله فعليًا بهذا

إذا كنت تبني أي نوع من أنظمة الإضافات أو الامتدادات في عام 2026 وما زلت تلجأ افتراضيًا إلى لغات البرمجة النصية المدمجة أو معماريات "حاوية لكل إضافة"، فمن المفيد بناء نموذج أولي باستخدام Component Model أولًا - ابدأ بـExtism إذا كنت تريد أسرع طريق لبناء مضيف إضافات عامل، أو بـwasmCloud/Spin إذا كنت بالفعل ضمن سياق Kubernetes أو حوسبة الحافة. أما إذا لم تكن تبني أنظمة إضافات، فالإشارة الأكثر أهمية هي دعم WASI Preview 3 غير المتزامن: فهو العنصر الذي يفتح الباب أمام WASM لأحمال العمل الكثيفة الاعتماد على الإدخال/الإخراج والتي كانت في السابق خيارًا غير مناسب، ويستحق الأمر إعادة النظر في WASM كخيار لحوسبة الحافة التي استبعدتها سابقًا لأسباب تتعلق بالأداء.