تتيح لك Cloudflare Workers تشغيل شيفرة الواجهة الخلفية عند الحافة، قريبًا من مستخدميك، دون إدارة خوادم. بالنسبة إلى واجهات API، فإن هذا المزيج من بدء التشغيل البارد شبه المعدوم والتوزيع العالمي والتخزين المتكامل بإحكام يجعل Workers منصة مقنعة في 2026. يشرح هذا الدليل كيف تُبنى واجهة Cloudflare Workers API وما الذي يميزها عن الواجهة الخلفية التقليدية.

باختصار

  • تُشغّل Cloudflare Workers شيفرتك على شبكة Cloudflare العالمية عند الحافة، فتُخدَم الطلبات قريبًا من المستخدمين مع بدء تشغيل بارد شبه معدوم
  • يعالج Worker الطلبات الواردة عبر معالج fetch؛ توجّه حسب الطريقة والمسار وتُرجع كائنات Response قياسية
  • ترتبط Workers مباشرة بالتخزين: D1 (SQLite) وKV (مفتاح-قيمة) وR2 (تخزين الكائنات) وQueues وDurable Objects
  • تلائم Workers واجهات API منخفضة الكمون والموزعة عالميًا؛ وتستخدم بيئة تشغيل خفيفة بدلًا من بيئة خادم كاملة، مما يشكّل طريقة البناء

ما الذي يجعل Workers مختلفة

تعمل واجهة API التقليدية على خادم (أو حاوية) في منطقة واحدة. أما Cloudflare Workers فتعمل بدلًا من ذلك على شبكة Cloudflare العالمية باستخدام V8 isolates خفيفة بدلًا من الحاويات أو الأجهزة الافتراضية. النتائج العملية:

  • بدء تشغيل بارد شبه معدوم. تبدأ isolates على الفور تقريبًا، متجنبةً تأخيرات بدء التشغيل البارد الشائعة في بعض منصات serverless.
  • عالمية افتراضيًا. تعمل شيفرتك قريبًا من كل مستخدم عبر شبكة Cloudflare، مما يقلل الكمون دون أن تنشرها في مناطق متعددة.
  • لا خوادم لإدارتها. لا توفير ولا ترقيع ولا توسيع؛ تتولى المنصة ذلك.
  • بيئة تشغيل مركّزة. توفر Workers واجهات API بمعايير الويب (Fetch وRequest/Response وWeb Crypto وstreams) بدلًا من نظام تشغيل خادم كامل، مع طبقة توافق Node.js لكثير من واجهات Node. أنت تصمم حول معايير الويب.

شكل واجهة Cloudflare Workers API

في جوهره، يُصدّر Worker معالجًا يستقبل كل طلب:

1export default {
2  async fetch(request, env, ctx) {
3    const url = new URL(request.url);
4    if (request.method === "GET" && url.pathname === "/api/health") {
5      return Response.json({ status: "ok" });
6    }
7    return new Response("Not found", { status: 404 });
8  }
9};

من هنا تبني:

  • التوجيه حسب طريقة HTTP والمسار (يدويًا لواجهات API الصغيرة، أو بموجّه خفيف للأكبر).
  • تحليل الطلبات باستخدام طرق Request القياسية لـ JSON وبيانات النماذج ومعاملات الاستعلام.
  • الاستجابات ككائنات Response قياسية، بما في ذلك Response.json().
  • الروابط (bindings) المتاحة على المعامل env للوصول إلى التخزين والموارد الأخرى.

ربط التخزين بالروابط (bindings)

القوة الحقيقية لواجهة Workers API تكمن في مدى ارتباطها المباشر بالبيانات:

  • D1 لقاعدة بيانات SQLite بلا خادم، مثالية للبيانات العلائقية. انظر Cloudflare D1 .
  • KV لبيانات مفتاح-قيمة سريعة وموزعة عالميًا مثل الإعدادات أو التخزين المؤقت.
  • R2 لتخزين الكائنات (الملفات والصور) دون رسوم خروج بيانات.
  • Queues للمعالجة الخلفية غير المتزامنة.
  • Durable Objects للتنسيق ذي الحالة والاتساق حيثما احتجت إليه.

تُعلَن الروابط في إعداداتك وتظهر على env، فتستدعيها شيفرتك مباشرة دون إدارة سلاسل اتصال أو بيانات اعتماد بالطريقة المعتادة.

التطوير والنشر

  • تتولى Wrangler، أداة سطر الأوامر من Cloudflare، التطوير المحلي والإعداد والأسرار والنشر.
  • تطوّر مقابل بيئة تشغيل محلية تحاكي الإنتاج، ثم تنشر عالميًا بأمر واحد.
  • تُدار الأسرار عبر Wrangler بدلًا من إدراجها في الشيفرة.

متى تكون Workers الخيار الصحيح

تُعد Workers خيارًا ممتازًا لواجهات API منخفضة الكمون والموزعة عالميًا، وwebhooks، وطبقات edge middleware، والخدمات التي تستفيد من التشغيل قريبًا من المستخدمين. وهي أقل ملاءمة لأعباء العمل التي تحتاج إلى عمليات طويلة الأمد، أو حوسبة مكثفة على المعالج تتجاوز نموذج الطلب، أو بيئة تشغيل لغة محددة لا تستهدفها المنصة. لمقارنة أوسع للحوسبة، انظر Cloudflare Workers مقابل AWS Lambda .

مثال واقعي: واجهة AI Code Review API مبنية على Cloudflare Workers، وتعمل عند الحافة حول العالم دون بدء تشغيل بارد لإرجاع نتائج سريعة ومنظمة، وهي بالضبط نوع واجهات API منخفضة الكمون التي تتفوق فيها Workers.

النقاط الرئيسية

  • تعمل واجهة Cloudflare Workers API عند الحافة مع بدء تشغيل بارد شبه معدوم وتوزيع عالمي، دون خوادم لإدارتها.
  • يعالج Worker الطلبات عبر معالج fetch؛ توجّه حسب الطريقة والمسار وتُرجع كائنات Response قياسية.
  • تربط الروابط واجهة API الخاصة بك مباشرة بـ D1 وKV وR2 وQueues وDurable Objects.
  • تلائم Workers واجهات API منخفضة الكمون والموزعة عالميًا؛ وبيئة تشغيلها المركّزة بمعايير الويب تشكّل طريقة البناء.

ابنِ واجهة API عند الحافة مع الخبراء

تصميم واجهة serverless API تستخدم الحافة جيدًا (التوجيه وروابط التخزين وبيئة التشغيل بمعايير الويب) يستفيد من الخبرة بالمنصة. استكشف منتجات وأدوات Mecanik لأمثلة مبنية على Cloudflare، وشاهد كيف تساعدك مقارنة Cloudflare Pages مقابل Workers على اختيار خدمة Cloudflare المناسبة لمشروعك.

الأسئلة الشائعة (FAQ)

ما هي واجهة Cloudflare Workers API؟ هي واجهة API خلفية تعمل كشيفرة على شبكة Cloudflare العالمية عند الحافة بدلًا من خادم تقليدي. يعالج Worker طلبات HTTP عبر معالج fetch ويمكنه الاتصال مباشرة بالتخزين مثل D1 وKV وR2، مع خدمة الطلبات قريبًا من المستخدمين ببدء تشغيل بارد شبه معدوم.

هل لدى Cloudflare Workers بدء تشغيل بارد؟ لديها بدء تشغيل بارد شبه معدوم لأنها تعمل على V8 isolates خفيفة تبدأ على الفور تقريبًا، بدلًا من تشغيل الحاويات أو الأجهزة الافتراضية. وهذه إحدى المزايا الرئيسية لـ Workers لواجهات API الحساسة للكمون.

هل يمكنني استخدام قاعدة بيانات مع Cloudflare Workers؟ نعم. ترتبط Workers مباشرة بـ D1 (SQLite بلا خادم) للبيانات العلائقية، وKV لبيانات مفتاح-قيمة، وR2 لتخزين الكائنات، إضافة إلى Queues وDurable Objects. تظهر الروابط على المعامل env فتصل إليها شيفرتك مباشرة.

ما اللغة التي تستخدمها Cloudflare Workers؟ بشكل أساسي JavaScript وTypeScript، وWebAssembly للغات الأخرى. توفر Workers واجهات API بمعايير الويب (Fetch وRequest/Response وWeb Crypto) مع طبقة توافق Node.js لكثير من واجهات Node، فتبني حول معايير الويب بدلًا من بيئة تشغيل خادم كاملة.

متى ينبغي أن أستخدم Cloudflare Workers لواجهة API؟ استخدم Workers لواجهات API منخفضة الكمون والموزعة عالميًا، وwebhooks، وedge middleware التي تستفيد من التشغيل قريبًا من المستخدمين مع توسيع فوري. وهي أقل ملاءمة للعمليات طويلة الأمد أو العمل المكثف على المعالج خارج نموذج الطلب.