ما العرض عند الحافة ولماذا يهم؟

يُستضاف خادم الويب التقليدي في منطقة جغرافية واحدة. يختبر المستخدمون القريبون من تلك المنطقة استجابات سريعة، بينما يعاني المستخدمون البعيدون زمن استجابة ملحوظًا؛ فطلب مستخدم في طوكيو محتوى من خادم US-East يضيف أكثر من 200 ملي ثانية إلى زمن الرحلة ذهابًا وإيابًا قبل وصول أول بايت.

تخزّن شبكة توصيل المحتوى (CDN) الملفات الثابتة مثل الصور وCSS وJavaScript في عشرات نقاط الحضور (PoPs) حول العالم، وتقدّمها من أقرب موقع. لكن CDN التقليدية لا تستطيع تنفيذ التعليمات البرمجية؛ إذ لا يمكنها سوى تقديم محتوى ثابت مُعد مسبقًا.

تنفّذ بيئة تشغيل Edge JavaScript في نقاط حضور CDN حول العالم، فتُلغي الرحلة ذهابًا وإيابًا إلى الخادم الأصلي عند معالجة الطلبات الديناميكية. فبدلًا من توجيه الطلب إلى خادم واحد، تتم معالجته في نقطة الحضور الأقرب إلى المستخدم، وغالبًا داخل المدينة نفسها، مما يقلّل زمن الاستجابة بدرجة كبيرة.

تشغّل Cloudflare Workers لغة JavaScript باستخدام عوازل V8 في أكثر من 300 موقع حول العالم. وعلى خلاف الدوال عديمة الخوادم مثل Lambda وCloud Run، تتميز Workers ببدء تشغيل بارد يقترب من الصفر، يُقاس بالميكروثانية بدلًا من أكثر من 100 ملي ثانية المعتادة في Lambda، لأنها تعيد استخدام عوازل V8 بدلًا من تشغيل حاويات جديدة.

يعني التصيير عند Edge تصيير تطبيق React على الخادم في نقطة حضور Edge الأقرب إلى كل مستخدم، ثم تقديم HTML الناتج فورًا. ويحصل المستخدم في طوكيو على صفحة HTML مصيّرة بالكامل من نقطة حضور في سنغافورة، لا من خادم في فرجينيا.

قد يستغرق وصول تطبيق SSR تقليدي يُقدَّم من US-East إلى طوكيو 400 ملي ثانية، منها 200 ملي ثانية للشبكة و200 ملي ثانية لتصيير الخادم. أما مع التصيير عند Edge، فيحدث التصيير في سنغافورة، فينخفض زمن استجابة الشبكة إلى 30 ملي ثانية، ويصل HTML في أقل من 100 ملي ثانية إجمالًا، أي بتحسّن قدره أربعة أضعاف في زمن التحميل الذي يلاحظه المستخدم.

بيئات تشغيل Edge ليست بيئات Node.js كاملة. إذ تحظر Cloudflare Workers واجهات Node.js الأساسية مثل fs وnet وcrypto، وتحدّ زمن المعالجة على وحدة المعالجة المركزية إلى 50 ملي ثانية لكل طلب، مع إتاحة وقت أطول في الخطط المدفوعة، كما تقيّد الذاكرة ولا توفر وصولًا إلى نظام الملفات. وتتطلب هذه القيود هندسة مدروسة.

توفر عدة منصات بيئات تشغيل Edge: ‏Vercel Edge Functions المبنية على نموذج عوازل V8 نفسه، وDeno Deploy التي تستخدم بيئة Deno عند Edge، وFastly Compute التي تستخدم WebAssembly. وتختلف هذه المنصات في توافق الواجهات البرمجية، والتغطية العالمية، ونماذج التسعير.

يكون التصيير عند Edge مفيدًا أكثر للمحتوى الثابت في معظمه، لكنه يحتاج إلى قدر من التخصيص، مثل صفحات التسويق التي تتضمن نسخًا لاختبارات A/B، والصفحات المقصودة ذات المحتوى المستهدف جغرافيًا، ومنشورات المدونات التي تتضمن عناصر خاصة بالمستخدم، مثل حالة تسجيل الدخول واللغة. أما الصفحات الديناميكية بدرجة كبيرة والكثيفة الاعتماد على قواعد البيانات، فتستفيد منه بدرجة أقل.

تُشغّل دوال Lambda وCloud Run الحاويات، وتنزّل التعليمات البرمجية الخاصة بك، وتهيّئ بيئة التشغيل، ثم تنفّذها، مما يؤدي إلى بدء تشغيل بارد يستغرق من 100 إلى 1000 ملي ثانية. أما Workers فتعيد استخدام عوازل V8 المشغّلة أصلًا، مما يجعل بدء التشغيل البارد غير ملحوظ عمليًا، إذ يستغرق أقل من 5 ملي ثوانٍ.

تستخدم معظم تطبيقات الإنتاج التصيير عند Edge بشكل انتقائي: إذ تصيّر Edge الصفحات السريعة والثابتة في معظمها، بينما يتولى خادم إقليمي العمليات التي تتطلب المصادقة وتستخدم قواعد البيانات بكثافة. ويستفيد هذا النهج الهجين من مزايا زمن الاستجابة المنخفض للتصيير عند Edge دون الاصطدام بقيوده.

لماذا تتميز Cloudflare Workers ببدء تشغيل بارد يقترب من الصفر مقارنةً بـ AWS Lambda؟

ينفّذ التصيير عند Edge لغة JavaScript في نقاط حضور CDN حول العالم، فيلغي الرحلات ذهابًا وإيابًا إلى الخادم الأصلي ويقلّل زمن الاستجابة بدرجة كبيرة. وتتصدر Cloudflare Workers بفضل بدء التشغيل البارد القائم على عوازل V8، والذي يستغرق ميكروثوانٍ في أكثر من 300 موقع. لكن المقايضات حقيقية، مثل غياب واجهات Node.js ومحدودية وقت المعالجة، ولذلك يلائم التصيير عند Edge صفحات التسويق والمحتوى المخصص لكنه الثابت في معظمه، أكثر من الصفحات الثقيلة المعتمدة على قواعد البيانات.