Rust/WASM Edge Functions مقابل Cloudflare و Vercel Edge

تم إنشاء هذا النص الإنجليزي تلقائيًا من النص الأصلي الفرنسي ولم تتم مراجعته بعد.

تمت ترجمة هذه الصفحة تلقائيًا. النسخة الإنجليزية موثوقة.

ومع ذلك، يظل الوضع الافتراضي لـ Aurabase هو Deno (V8 المعزولة أيضًا)، كما هو موثق في نواة Rust لـ Aurabase. تغطي "وظائف الحافة في Rust" ثلاث حقائق مختلفة اعتمادًا على النظام الأساسي: مجموعة SDK مجتمعية على جانب Cloudflare، ولا يوجد طريق رسمي على جانب Vercel، ووضع تنفيذ أصلي مع واجهة سطر الأوامر (CLI) الخاصة به على جانب Aurabase. توضح هذه المقارنة تفاصيل البنى الثلاثة دون خلط ما تم التحقق منه وما يبقى هدفًا للنظام الأساسي.

الأساسيات

تقدم Aurabase وقتي تشغيل لوظائف Edge: deno (V8 المعزولة، الخدمة المخصصة، الوضع الافتراضي) وwasm (تجميع Rust، وتشغيلها محليًا عبر Wasmtime).
يعمل Cloudflare Workers على معزولات V8 ويمكنه تشغيل WebAssembly بالإضافة إلى ذلك، لا سيما عبر SDK لمجتمع workers-rs. إنه ليس وقت تشغيل أصلي مخصصًا لـ Rust مثل وضع wasm الخاص بـ Aurabase.
تعتمد Vercel Edge Functions على Edge Runtime، وهي مجموعة فرعية من Node.js API على V8 المعزول: لا يوجد SDK أو CLI رسمي لكتابة الوظيفة نفسها في Rust.
يعزل وضع wasm الخاص بـ Aurabase كل عملية تنفيذ باستخدام ميزانية وحدة المعالجة المركزية الخاصة بوقود Wasmtime، وحد ذاكرة مخصص ومهلة لكل حقبة، ولكنه لا يعرض حاليًا أي وصول للشبكة الصادرة إلى وحدة الضيف.
ثلاث بنيات مختلفة لنفس الهدف: البدء بسرعة وعزل كل عملية تنفيذ، دون تكلفة حاوية كاملة.

السياق

عزل V8 ووحدات WASM: ميكانيكا وضع الحماية

يعد V8 المعزول سياق تنفيذ JavaScript خفيف الوزن داخل نفس محرك V8: لا توجد عمليات نظام جديدة، ولا توجد نواة جديدة للبدء. هذه هي الآلية التي أعلنتها Cloudflare لأول مرة للعاملين، والتي أعادت Vercel استخدامها في Edge Runtime. الهدف هو نفسه على كلا الجانبين: تجنب تكلفة الحاوية أو الجهاز الافتراضي لكل طلب.

تلبي وحدة WebAssembly نفس الحاجة من خلال آلية مختلفة. يعمل كود WASM الثانوي في ذاكرة خطية محددة، تحددها المواصفات نفسها. لا يمكن لوحدة الضيف أن تعالج خارج هذه المنطقة، بغض النظر عن لغة المصدر (Rust، C، Go…) التي أنتجت الثنائي. هذا هو النموذج الذي يطبقه Wasmtime في وضع wasm الخاص بـ Aurabase، المفصل أدناه. للحصول على قياسات بدء التشغيل بين الآليتين، راجع ملف الخاص بنا على معايير البداية الباردة لـ WebAssembly.

وقت تشغيل WASM

ما هو وضع Aurabase Wasm الذي يتم تشغيله في الإنتاج

تحمل كل وظيفة Aurabase حقل runtime بقيمة "wasm" أو "deno". يختار محرك الاستدعاء مسار التنفيذ وفقًا لذلك:

runtime/dispatch.rsrust

// الإرسال وفقًا لوقت التشغيل: WASM (wasmtime) أو Deno (V8 المعزول عبر وقت تشغيل الحافة)
let resp = if func.runtime == "wasm" {
    state.runtime.invoke(&wasm_bytes, &func.code_hash, req).await?
} else {
    // وكيل لوقت تشغيل Aura-Edge-V8 المعزول (supabase/edge-runtime، MIT)
    proxy_to_edge_runtime(&state.config.edge_runtime_url, …).await?
};

يعتمد وضع الحماية على ثلاث آليات Wasmtime مجتمعة. ميزانية وحدة المعالجة المركزية تُحسب في "الوقود": تستهلكها كل تعليمات WASM. يتم تطبيق المهلة بزيادات العصر: يزيد مؤشر الترابط المخصص من ساعة Wasmtime بعد التأخير الذي تم تكوينه، مما يقاطع التنفيذ الحالي. تم ضبط حد الذاكرة عبر StoreLimits. يتم تكوين المحطات الثلاث عند إنشاء مثيل للمحرك:

runtime/wasm.rsrust

let mut cfg = Config::new();
cfg.consume_fuel(true);
cfg.epoch_interruption(true);

// الذاكرة يحدها StoreLimits، الوقود الأولي = max_fuel،
// المهلة = زيادة العصر بعد timeout_secs (موضوع مخصص)

يتم تخزين الوحدة المترجمة مؤقتًا بواسطة code_hash: لا تتم إعادة ترجمة نفس الثنائي المنشور في كل مكالمة. مع ذلك، يقوم كل استدعاء بإنشاء مثيل Store ومثيل جديد. لا توجد حالة تتسرب من مكالمة إلى أخرى. تظل مساحة السطح المعرضة لوحدة الضيف ضئيلة بشكل متعمد، وإجمالي خمس وظائف مضيفة: aura.logو aura.get_inputو aura.set_outputو aura.get_env وكعب env.abort لتوافق AssemblyScript. لا توجد وظائف مضيفة تكشف عن مكالمات الشبكة الصادرة في هذا الوقت.

تم التحقق منه مقابل هدف المنتج

أصبح الوضع wasm مناسبًا الآن للحسابات النقية: التحقق من الصحة، وتحويل البيانات، والتسجيل، والتحليل. الوظيفة التي يجب أن تستدعي واجهة برمجة تطبيقات تابعة لجهة خارجية (الدفع، البريد الإلكتروني، الخدمة الخارجية) يجب أن تمر عبر وضع deno. هذا هو الوضع الافتراضي لـ Aurabase، والوضع الموصى به لترحيل كود Deno الموجود.

من ناحية النشر، تقوم واجهة سطر الأوامر (CLI) بتجميع الصندوق الخاص بك محليًا قبل الإرسال: aura functions new يقوم بتركيب الصندوق cdylib، ويجمعه aura functions deploy ثم يرسله.

terminalbash

# السقالات: إنشاء aurabase/functions/<name>/ (Cargo.toml crate-type = cdylib)
aura functions new my-fn

# بناء البضائع --target Wasm32-unknown-unknown --release، ثم التحميل
# POST /v1/functions/:project_id { وقت التشغيل: "wasm"، الكود: <wasm in base64> }
aura functions deploy my-fn

كلاودفلير

عمال Cloudflare: يعزلون V8، بالإضافة إلى WebAssembly

يقوم عمال Cloudflare بتشغيل JavaScript وTypeScript في V8 المعزولة الموزعة عبر شبكة Cloudflare العالمية. لقد كان WebAssembly مواطنًا من الدرجة الأولى منذ بداية النظام الأساسي: يمكن استيراد وحدة .wasm مباشرة إلى العامل مثل أي وحدة نمطية أخرى.

لكتابة عامل بالكامل في Rust، فإن المسار الأكثر استخدامًا هو مجتمع SDK workers-rs، الذي يجمع التعليمات البرمجية إلى wasm32-unknown-unknown وينفذها في وقت تشغيل العمال. الفرق مع وضع wasm الخاص بـ Aurabase هو مساحة السطح المتاحة. يعمل العامل المكتوب بلغة Rust عبر SDK هذا في بيئة العمال الكاملة، وبالتالي يمكنه الاتصال بـ fetch أو روابط النظام الأساسي الأخرى. يبدأ وضع wasm الخاص بـ Aurabase من سطح مضيف مصغر عمدًا (القسم السابق).

فيرسل

وظائف Vercel Edge: مجموعة فرعية من Node.js، ولا يوجد مسار Rust رسمي

يقوم Vercel's Edge Runtime أيضًا بتشغيل التعليمات البرمجية في V8 المعزولة، مع مجموعة فرعية من واجهات برمجة تطبيقات الويب القياسية (fetch, Request/Response, crypto.subtle...) بدلاً من بيئة Node.js الكاملة. وحدات العقدة الأصلية وسلاسل أدوات الترجمة التعسفية ليس لها مكان هناك.

يعد كائن WebAssembly جزءًا من هذه المجموعة الفرعية: لا شيء يمنعك من تحميل ملف ثنائي .wasm وإنشاء مثيل له يدويًا من وظيفة JavaScript أو TypeScript. لكن على حد علمنا، لا تنشر Vercel أي SDK أو واجهة سطر أوامر (CLI) رسمية لكتابة وظيفة Edge مباشرة في Rust، على عكس workers-rs على جانب Cloudflare أو aura functions deploy على جانب Aurabase. يظل المسار ممكنًا، ولكن يدويًا بالكامل، بدون أدوات مخصصة.

الأمن

Sandbox: الذاكرة الخطية WASM مقابل عزل V8

يفصل عزل V8 التعليمات البرمجية التي يتم تنفيذها بواسطة كومة مخصصة وسياقها الخاص، ضمن نفس عملية المحرك. إنها آلية مجربة، على نطاق ملايين الطلبات في الثانية في Cloudflare وVercel، ولكنها تظل آلية عزل البرامج داخل محرك JavaScript واحد.

يتم عزل نموذج WASM بشكل مختلف: كل مثيل يحصل على ذاكرته الخطية الخاصة، وهو مخزن مؤقت متجاور لا يمكن الوصول خارجه عن طريق إنشاء التنسيق الثنائي نفسه، بشكل مستقل عن المحرك الذي ينفذه. في وقت تشغيل Aurabase، تقوم كل وظيفة مضيفة تعالج مؤشرًا توفره الوحدة الضيف (aura.log, aura.get_env…) بإعادة التحقق بشكل صريح من الحدود قبل أي وصول إلى الذاكرة. يعد هذا دفاعًا إضافيًا متعمقًا ضد الوحدة النمطية الضارة أو التي تجرها الدواب.

نظرة عامة

المباني الثلاثة، جنبا إلى جنب

	أوراباسي (وسم)	عمال كلاودفلير	وظائف حافة Vercel
نموذج التنفيذ	وحدة WASM الأصلية، Wasmtime	عزل V8 + WASM كوحدة اختيارية	عزل V8، مجموعة Node.js الفرعية
الصدأ في المقدمة	نعم، الوضع المخصص + CLI	عبر مجتمع SDK (العمال-RS)	لا، لا يوجد طريق رسمي
الوصول إلى الشبكة الخروج من الوحدة النمطية	لا، تم التحقق من الرمز (لا توجد وظيفة مضيف الشبكة)	نعم، عبر بيئة العمال الكاملة	نعم، واجهة برمجة تطبيقات الجلب القياسية
ميزانية وحدة المعالجة المركزية	الوقود Wasmtime، شكلي	الحد الزمني لوحدة المعالجة المركزية لكل طلب (Cloudflare doc)	الحد الأقصى للمدة لكل استدعاء (doc. Vercel)
نشر الصدأ مخصص	نشر وظائف الهالة (بناء الحمولة محليًا)	رانجلر + العمال-RS	لا توجد أداة رسمية مكافئة

مواصفات وقت تشغيل Aurabase. تم وصف أعمدة Cloudflare وVercel من البنية العامة الموثقة لكل نظام أساسي (يتم عزل V8 وWebAssembly كهدف بناء).

القرار

أي وقت تشغيل تختاره وفقًا لوظيفتك

حساب خالص، بدون مكالمات الشبكة: التحقق من صحة المخطط، وتحويل البيانات، والتسجيل، وإنشاء صور خفيفة الوزن. يعد وضع wasm الخاص بـ Aurabase مناسبًا بشكل مباشر، مع وضع حماية صارم للذاكرة، وميزانية واضحة لوحدة المعالجة المركزية، ودون الاعتماد على خدمة خارجية.

الوظيفة التي تستدعي واجهة برمجة تطبيقات الطرف الثالث (الدفع، البريد الإلكتروني، خطاف الويب الصادر). يظل وضع deno الخاص بـ Aurabase هو الخيار الافتراضي اليوم، بنفس الطريقة التي يعتمد بها Cloudflare Worker الكلاسيكي أو وظيفة Vercel Edge على fetch محليًا.

استثمر الفريق بالفعل في النظام البيئي Cloudflare (KV، Permanent Objects، R2). البقاء على العمال أمر منطقي. workers-rs يسمح لك بتقديم Rust تدريجيًا، دون تغيير الأنظمة الأساسية.

تحتاج إلى وقت تشغيل أصلي مُدار من طرف إلى طرف لـ Rust، مع واجهة سطر أوامر (CLI) مخصصة ونفس لغة بقية الواجهة الخلفية. هذه هي الزاوية التي يوثقها في مقارنة Wasmtime vs Wasmer، حول اختيار محرك WebAssembly نفسه.

الأسئلة المتداولة

الأسئلة الشائعة

هل يمكنك كتابة وظائف Aurabase Edge في الصدأ؟+

نعم عن طريق وضع WASM. سيكون لـ CLI وظائف سقالة جديدة وهي صندوق الصدأ (cdylib من نوع الصندوق). يقوم أمر نشر وظائف aura بتجميعه محليًا باستخدام cargo build --target Wasm32-unknown-unknown --release، ثم يرسل الملف الثنائي إلى خدمة aura-functions، التي تقوم بتشغيله أصلاً مع وقت تشغيل Wasmtime. هذا ليس الوضع الافتراضي: افتراضيًا، يتم تشغيل وظيفة Aurabase Edge في JavaScript/TypeScript (Deno runtime، V8 Isolates).

هل يسمح لك Cloudflare Workers حقًا بكتابة الوظائف في Rust؟+

نعم، ولكن بشكل غير مباشر: يقوم Cloudflare Workers أصلاً بتنفيذ JavaScript/TypeScript في V8 المعزولة. يسمح لك مجتمع العمال-RS SDK بتجميع عامل كامل في Rust إلى WebAssembly، ولكن هذا ليس المسار الأكثر توثيقًا رسميًا. يكمل WASM العامل هناك بدلاً من استبدال نموذج JS بالكامل.

هل تدعم Vercel Edge Functions WebAssembly أو Rust محليًا؟+

يعرض Vercel Edge Runtime واجهات برمجة تطبيقات الويب القياسية، بما في ذلك كائن WebAssembly، لذلك يمكن تحميل وحدة .wasm وإنشاء مثيل لها يدويًا من وظيفة JavaScript/TypeScript. لكن على حد علمنا، لا تنشر Vercel أي SDK أو واجهة سطر أوامر (CLI) رسمية لكتابة وظيفة Edge مباشرة في Rust، على عكس العمال على جانب Cloudflare أو وظائف الهالة المنتشرة على جانب Aurabase.

هل يمكن لوضع Aurabase Wasm استدعاء واجهة برمجة تطبيقات تابعة لجهة خارجية (الدفع، البريد الإلكتروني، وما إلى ذلك)؟+

ليس اليوم: وظائف المضيف المعرضة لوحدة WASM الضيف هي السجل، وقراءة طلب الإدخال وكتابة استجابة الإخراج، بالإضافة إلى قراءة متغيرات البيئة. بالنسبة للوظيفة التي تحتاج إلى استدعاء واجهة برمجة تطبيقات خارجية (جلب الشبكة)، فإن وقت تشغيل Deno (الافتراضي) هو المسار الموصى به.