Django أم FastAPI على Cloudflare Workers: أيهما تختار؟

Django أم FastAPI على Cloudflare Workers: أيهما أنسب؟

اختر Django عندما يكون لديك بالفعل تطبيق Django أو تحتاج إلى خلفية متكاملة للمنتج. واختر FastAPI عندما تبدأ من الصفر في بناء API مكتوب الأنواع، أو خدمة webhooks، أو نقطة نهاية على الحافة تعتمد بكثافة على عمليات الإدخال والإخراج. أما إذا كانت حزمة أساسية أو بنية العمليات أو عبء العمل ذي الحالة لا يلائم بيئة Workers، فأبقِ التطبيق — أياً كان إطاره — على خادمه الأصلي.

غيّرت Cloudflare أساس المقارنة في 2 سبتمبر 2026. فقد أصبح بإمكان Python Workers استضافة تطبيقات WSGI وASGI مباشرة عبر المحوّلات المتاحة في وحدة workers. يمثّل WSGI العقد التقليدي المتزامن لتطبيقات الويب في Python، بينما يأتي ASGI خلفاً غير متزامن له، صُمّم لتداخل عمليات الإدخال والإخراج والبث والاتصالات طويلة الأمد. وتجمع أمثلة Cloudflare عند إطلاق الميزة بوضوح بين Django وWSGI، وبين FastAPI وASGI، مع أن Django يستطيع العمل بالبروتوكولين.

يظل Django خيار الترحيل الأكثر أماناً عندما تكون منظومته المتكاملة قد أصبحت جزءاً من القيمة التي يقدمها المنتج. توثق Cloudflare الآن نقطتي دخول لكل من WSGI وASGI، إلى جانب مسار django-cf لاستخدام D1 وDurable Objects.

أما FastAPI فهو الخيار الأنظف للمشروعات الجديدة عندما تكون النتيجة المطلوبة API لا منتج ويب يعتمد على لوحة إدارة. تتولى Cloudflare طبقة خادم ASGI، فلا يحتاج Worker إلى تشغيل Uvicorn أو إدارة socket.

تكلفة Django وFastAPI متساوية حتى يختلف زمن CPU

لا يتمتع أي من الإطارين بأفضلية سعرية. جرى التحقق من الأسعار في 5 سبتمبر 2026 بالرجوع إلى الصفحات الرسمية المنشورة: Django مجاني ومفتوح المصدر بموجب ترخيص BSD، وFastAPI يستخدم ترخيص MIT، بينما تبدأ خطة Workers Paid من $5 لكل حساب شهرياً.

يشمل مبلغ $5 حصة قدرها 10 ملايين طلب و30 مليون ملّي ثانية من زمن CPU شهرياً. وتبلغ كلفة الطلبات الإضافية $0.30 لكل مليون طلب، فيما تبلغ كلفة CPU الإضافية $0.02 لكل مليون ملّي ثانية. طلبات Static Assets مجانية وغير محدودة. وتتيح Workers Free حصة يومية قدرها 100,000 طلب، لكن سماحها البالغ 10 ms من زمن CPU لكل استدعاء يجعلها أساساً غير مناسب لمقارنة تطبيقات أطر العمل التي تنفذ عملاً فعلياً.

عند توحيد عبء العمل على الإطارين، تكون النتيجة متوقعة تماماً. عند 15 مليون طلب ديناميكي شهرياً ومتوسط 7 ms من زمن CPU لكل طلب، تبلغ كلفة أي من الإطارين $8 شهرياً: مبلغ أساسي قدره $5، ثم $1.50 لتجاوز عدد الطلبات، و$1.50 لتجاوز زمن CPU. وعند 100 مليون طلب بمتوسط 7 ms نفسه، تبلغ كلفة أي منهما $45.40 شهرياً.

حساب الحساسية أنفع من اختبار أداء مصطنع بين الإطارين. فبعد استهلاك الحصة المضمّنة من CPU، يؤدي كل فرق قدره 1 ms في المتوسط إلى تغيير الفاتورة بمقدار $0.30 عند 15 مليون طلب، وبمقدار $2 عند 100 مليون طلب. وبذلك تساوي فجوة مقاسة قدرها 5 ms مبلغ $1.50 أو $10 شهرياً عند مستويي الزيارات هذين. وهذا أقل بكثير من أن يبرر إعادة كتابة إطار العمل لمجرد خفض كلفة الحوسبة.

لا توجد نقطة يتقاطع عندها سعر المزود لصالح أحد الخيارين. يصبح أحدهما أقل كلفة فقط عندما يختلف زمن CPU المقاس أو الخدمات المساندة أو عبء الصيانة. لن ينقذ إطار سريع بنيةً تحيطه باستدعاءات بطيئة لقاعدة البيانات، وقد يكون الإطار المتكامل الذي يوفر أسابيع من أعمال الاستبدال هو النظام الأرخص حتى لو رجّح اختبار مصغر كفة الإطار الآخر.

مسار الترحيل: Django للأنظمة القائمة وFastAPI لواجهات API الجديدة

تغيير المحوّل بسيط، أما ترحيل التطبيق فليس كذلك. لا يحتاج الإطاران إلا إلى نقطة دخول رفيعة، لكن كل ما يقع خلفها يجب أن يظل متوافقاً مع نموذج Cloudflare للحزم والتخزين ونظام الملفات ودورة الحياة.

ترحيل Django إلى Cloudflare Workers: المحوّل هو الجزء السهل

يمكن لـ Django الاحتفاظ بكائن تطبيق WSGI القياسي وتسليمه إلى محوّل Cloudflare:

import os

from django.core.wsgi import get_wsgi_application
from workers import wsgi

os.environ.setdefault("DJANGO_SETTINGS_MODULE", "app.settings")
app = get_wsgi_application()
Default = wsgi.entrypoint(app)

يكفي ذلك لتمرير طلب Workers الوارد إلى callable الخاص بـ WSGI في Django. لكنه لا يرحّل قاعدة البيانات أو الملفات الدائمة أو المهام المجدولة أو استراتيجية الجلسات أو كل حزمة خارجية يستخدمها Django.

يمنح دليل حزمة Django الجديد من Cloudflare إطار العمل مسار تخزين أصلياً فعلاً. توفر حزمة django-cf خلفيات متوافقة مع SQLite لكل من D1 وDurable Objects. وتشغّل الخلفيتان ORM المتزامن في Django، لذلك توصي Cloudflare بتقديم هذا الإعداد عبر WSGI. وفي منتج CRUD يعتمد بالفعل على النماذج والاستمارات والمصادقة ولوحة الإدارة، قد يحافظ هذا المسار على طبقات توفر من العمل أكثر بكثير مما قد يوفره تبديل إطار العمل من كلفة التشغيل.

تظهر العقبة عندما يفترض النظام القائم وجود خادم تقليدي. فقد يحتاج برنامج تشغيل قاعدة البيانات إلى native wheel لا يستطيع Workers تحميله، ولا يمكن حفظ الملفات التي يرفعها المستخدمون في نظام ملفات isolate. كذلك لا يمكن نقل مجدول يعمل داخل العملية أو thread pool كما هو. دعم Django يعني أن بروتوكول الطلبات يعمل، لكنه لا يمنح شهادة توافق للتطبيق المثبت بكامله.

ترحيل FastAPI إلى Cloudflare Workers: الأنسب لخدمة محددة النطاق

المحوّل المباشر في FastAPI أصغر لأن الإطار يتحدث ASGI أصلاً:

from fastapi import FastAPI
from workers import asgi

app = FastAPI()
Default = asgi.entrypoint(app)

تتولى Cloudflare دور خادم ASGI الذي يشغله Uvicorn عادةً. ويحتفظ FastAPI بتعريفات المسارات والتحقق عبر Pydantic وحقن الاعتماديات وتوثيق OpenAPI المولّد. لذلك تبدأ خدمة جديدة لاستقبال webhooks أو API مكتوب الأنواع بتنسيق JSON أو خدمة تعتمد على bindings، بآليات تطبيق أقل مما يتطلبه Django.

لكن المقابل هو العمل المطلوب لتجميع المكونات. يتعمد FastAPI عدم فرض قاعدة بيانات أو نموذج للبيانات، كما أنه لا يضم لوحة إدارة المحتوى التي يقدمها Django. عليك اختيار هذه الأجزاء والتحقق من كل حزمة داخل بيئة Workers وتحمّل مسؤولية دمجها. وهذه ميزة في خدمة مركزة، لكنها عبء في منتج يحتاج مشغلوه إلى واجهة خلفية منذ اليوم الأول.

الفائز في الترحيل: Django لتطبيق مبني بالفعل بـ Django، وFastAPI لواجهة API جديدة. إعادة كتابة نظام Django يعمل بصورة جيدة باستخدام FastAPI لمجرد أن الإطارين أصبحا يعملان على الحافة هي المشروع الخطأ.

WSGI أم ASGI على Cloudflare: FastAPI لتزامن الطلبات وDjango يحتفظ بالخيار

يوفر ASGI نموذج طلبات أقوى لخدمة جديدة كثيفة الإدخال والإخراج، لكن WSGI هو المسار الموثّق لدمج ORM الخاص بـ Django مع Cloudflare. اختيار البروتوكول يتبع عبء العمل، لا ادعاءً عاماً بأن البرمجة غير المتزامنة أسرع دائماً.

يقدم WSGI التطبيق في صورة callable متزامن. يشغّل محوّل WSGI الحالي من Cloudflare هذا الـ callable داخل معالج fetch غير المتزامن في Worker، وينقل جسم الطلب من ReadableStream في JavaScript، ثم يبث iterable الخاص باستجابة التطبيق إلى العميل. هذا مسار توافق للتطبيقات المتزامنة الناضجة، وليس خادم ويب ثانياً يعمل داخل isolate.

يتيح ASGI للتطبيق انتظار عمليات الشبكة والتخزين دون إبقاء مسار الطلب عالقاً في استدعاء متزامن. كما يربط محوّل Cloudflare أحداث ASGI WebSocket مع Workers WebSockets. بُني FastAPI على هذا النموذج، ويستطيع Django استخدامه أيضاً؛ لذلك لا يُعد «Django» و«WSGI» مترادفين.

قد يعكس اختيار التخزين قرار البروتوكول. تقول Cloudflare إن خلفيتي D1 وDurable Objects لـ Django تشغّلان ORM المتزامن وينبغي تقديمهما عبر WSGI. فإذا كان ORM هو سبب اختيار Django، يكون اتباع مسار WSGI الموثّق أكثر اتساقاً من فرض تسمية ASGI على طبقة بيانات متزامنة.

أما في FastAPI، فلا تفيد البرمجة غير المتزامنة إلا عندما يمكن تنفيذ العمل بالتوازي. فنقطة نهاية تقضي معظم وقتها في تحقق متسلسل أو معالجة كثيفة على CPU ستظل تستهلك CPU. بينما تملك نقطة نهاية تنتظر عدة عمليات مستقلة عبر HTTP أو Cloudflare bindings سبباً أوضح لاستخدام ASGI.

سلوك بدء التشغيل: مفاجأة دورة الحياة في FastAPI

يقدم Django عبر WSGI حالياً نموذج بدء تشغيل أكثر قابلية للتوقع على Workers. يعمل FastAPI أيضاً، لكن hooks الخاصة بدورة حياته لا تتصرف كما تفعل داخل عملية Uvicorn طويلة التشغيل.

تقلل Cloudflare عبء البدء البارد في Python من خلال snapshots وقت النشر. تنشئ المنصة أثناء النشر isolate من V8، وتحقن Pyodide، وتنفذ وحدة دخول Worker وعمليات الاستيراد في النطاق العام، ثم تأخذ snapshot لذاكرة WebAssembly. وبذلك يستطيع الطلب تحميل تلك اللقطة بدلاً من إعادة بناء بيئة Python من الصفر. ومع ذلك، يجب تحليل الشيفرة في النطاق العام وتنفيذها ضمن حد بدء التشغيل البالغ 1 ثانية. وتوثق Cloudflare دورة الحياة هذه مباشرة.

العقد المعتاد لدورة حياة FastAPI مصمم على هيئة عملية: تعمل شيفرة بدء التشغيل مرة قبل أن يبدأ التطبيق في قبول الطلبات، وتعمل شيفرة الإغلاق مرة بعد انتهائه. لكن المصدر الحالي لمحوّل ASGI من Cloudflare ينفذ سلوكاً مختلفاً بصورة جوهرية. تبدأ دالة fetch فيه تطبيق ASGI، وترسل حدث بدء لدورة الحياة، وتعالج طلباً واحداً، ثم ترسل حدث الإغلاق. ويصف التعليق في المصدر دورة بدء وإغلاق واحدة قبل الطلب وبعده.

وهذا يجعل شيفرة دورة الحياة مرتبطة بكل طلب في المحوّل الحالي. فقد يتكرر تحميل نموذج أو إنشاء connection pool أو تهيئة schema أو جلب إعدادات بعيدة بدلاً من توزيع كلفته على عمر isolate. ليس هذا سبباً لرفض FastAPI، لكنه سبب لجعل عمل دورة الحياة خفيفاً وقابلاً للتكرار بأمان، ونقل التهيئة الحتمية الآمنة إلى شيفرة يمكنها الاستفادة من snapshot النشر في Cloudflare.

يُنشأ تطبيق WSGI الخاص بـ Django في النطاق العام ضمن مثال Cloudflare، ولا يمر بدورة حياة ASGI. لذلك تصبح تهيئته جزءاً من مسار بدء التشغيل العام، ويكون سقف 1 ثانية هو القيد. وإذا اخترت نقطة دخول ASGI لـ Django واستخدمت مكونات تدرك دورة الحياة، فدقق فيها وفق سلوك المحوّل نفسه.

أطر Python على Workers تصطدم جميعها بحاجز الحزم نفسه

هذه الفئة متعادلة، وقد تستبعد الإطارين معاً. يعمل Django وFastAPI عبر بيئة Pyodide نفسها داخل V8، لذلك لا يستطيع أي منهما تجاوز قيود الحزم أو الذاكرة أو نظام الملفات أو بدء التشغيل.

توضح وثائق الحزم لدى Cloudflare أن pywrangler يجمع الاعتماديات المعلنة في pyproject.toml. وتشمل المصادر المدعومة حزم Python الخالصة وحزم PyEmscripten من PyPI، إلى جانب الحزم المرفقة مع Pyodide. وPyEmscripten هو تنسيق wheel مخصص لـ WebAssembly. لا تزال Cloudflare تصف هذه المنظومة بأنها في مرحلة مبكرة، ولا تتوفر لبعض الحزم حزمة wheel متوافقة.

فحوص المنصة الحاسمة واضحة:

• يجب ألا يتجاوز حجم حزمة Worker بعد فك الضغط 64 MiB في Free أو Paid.
• تبلغ ذاكرة كل isolate مقدار 128 MB.
• يجب أن يكتمل بدء التشغيل في النطاق العام خلال 1 ثانية.
• نظام ملفات Python مؤقت وخاص بكل isolate.
• يمكن استيراد threading وmultiprocessing، لكنهما لا يعملان داخل WebAssembly VM.

تعطل نقطة نظام الملفات عمليات ترحيل أكثر مما توحي به صيغة المحوّل. لا مشكلة في الملفات المؤقتة، أما ملفات المستخدمين المرفوعة والتقارير المولّدة وملفات SQLite المستخدمة كحالة دائمة وذاكرات التخزين المؤقت المشتركة على القرص، فلا تصلح هنا. ضع البيانات الدائمة في D1 أو Durable Objects أو KV أو R2 وفق نمط الوصول، لا في مجلد يختفي مع isolate. وترد الحدود الدقيقة في دليل مكتبة Python القياسية من Cloudflare.

توافق الحزم قرار ثنائي يسبق الاهتمام بالأداء. ابنِ شجرة الاعتماديات الفعلية، لا نسخة hello world مختصرة. نجاح الاستيراد في CPython على جهاز مكتبي لا يثبت شيئاً عن توفر الامتدادات الأصلية داخل Pyodide.

الملاءمة التشغيلية: Django للمنتجات وFastAPI للخدمات

يتفوق Django عندما تكون وحدة العمل منتجاً، ويتفوق FastAPI عندما تكون خدمة. هذا الفارق أكثر ثباتاً من معدل معالجة إطار العمل على مسار اختباري مصطنع.

الفائز لمنتج يعتمد على لوحة إدارة: Django

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

على Workers، تمنح django-cf هذا النموذج المتكامل مساراً إلى D1 أو Durable Objects. والمقابل هو ارتباط أوثق بـ ORM متزامن، ومنظومة إطار عمل أكبر يجب أن تنسجم مع حدود بيئة التشغيل.

الفائز لخدمة API مكتوبة الأنواع: FastAPI

يرتكز FastAPI على OpenAPI وJSON Schema والتحقق عبر Pydantic وحقن الاعتماديات. كما توضح وثائق ميزاته المقابل بجلاء: تظل خيارات قاعدة البيانات ونموذج البيانات مفتوحة. وهذا هو الشكل المناسب لـ API gateway أو مستقبل webhooks أو نقطة نهاية لنموذج أو خدمة صغيرة تتواصل مع bindings وواجهات API بعيدة.

عدم وجود لوحة إدارة وORM مدمجين ليس عيباً عندما لا تحتاج إليهما الخدمة، لكنه يتحول إلى كلفة تسليم لحظة احتياج موظف غير تقني إلى واجهة خلفية.

الفائز في السرعة الخام: لم يُثبت على Workers

وضعت اختبارات TechEmpower المستقلة تاريخياً FastAPI عند تشغيله تحت Uvicorn بين أسرع أطر Python، وفق صفحة اختبارات الأداء في FastAPI. قاست TechEmpower أعباء موحدة تشمل JSON وقواعد البيانات وORM والقوالب وغيرها، لكنها لم تقس محوّلات Pyodide لدى Cloudflare، كما توقف المشروع في 24 مارس 2026. لذا تمثل تلك النتائج إشارة تاريخية منسوبة إلى مصدرها، لا توقعاً لأداء نشر على Workers.

لم تنشر Cloudflare اختباراً يقارن Django وFastAPI عبر هذه المحوّلات. لذلك تظل السرعة الخام على Workers غير مثبتة إلى أن يشمل مسار ممثل التحقق والـ bindings واستدعاءات قاعدة البيانات وشكل الاستجابة وسلوك بدء التشغيل ومقاييس CPU في Workers.

ما الكلفة الفعلية للتبديل، ومن ينبغي له ألا يبدّل؟

لا تغيّر إطار العمل لمجرد الحصول على دعم Cloudflare؛ فكلاهما مدعوم الآن. لا تنتقل إلا عندما يزيل الإطار المستهدف من عمل التطبيق أكثر مما يضيفه الترحيل.

تعني إعادة كتابة تطبيق من Django إلى FastAPI استبدال النماذج والترحيلات وشاشات الإدارة ومسارات المصادقة والبرمجيات الوسيطة والقوالب، أو فصلها، فضلاً عن كل حزمة تفترض دورة طلبات Django. وقد تكون النتيجة ممتازة لـ API محدد النطاق، لكنها ليست مجرد إعداد نشر. فإذا كان الاعتماد كبيراً على لوحة الإدارة وORM، يهدم الانتقال ميزة قائمة قبل أن يبني أخرى.

لا يكون الانتقال من FastAPI إلى Django منطقياً إلا عندما يتجاوز المنتج بنيةً مصممة على هيئة خدمة ويحتاج إلى المنظومة التشغيلية المتكاملة لـ Django. وما عدا ذلك، سيضيف أعرافاً ومكونات لا تحتاج إليها API صغيرة.

يستطيع FastAPI تركيب تطبيق Django يعمل بـ WSGI تحت مسار عبر a2wsgi.WSGIMiddleware. وقد يدعم ذلك تفكيكاً مرحلياً على الخوادم التقليدية. أما على Workers، فيضيف حزمة أخرى وحداً بروتوكولياً إضافياً، بينما توثق مسارات Cloudflare الأولية كل إطار على حدة. تعامل مع Worker يجمع الإطارين بصفته تكاملاً مخصصاً يحتاج إلى إثبات، لا اختصاراً افتراضياً.

أياً كان اتجاه الانتقال، احسب كلفة هذه الجوانب:

• البيانات: توافق schema والترحيلات وسلوك المعاملات، والانتقال إلى D1 أو Durable Objects أو مخزن آخر يمكن الوصول إليه.
• الملفات: يمكن تقديم الأصول الثابتة عبر Workers Static Assets، بينما تحتاج وسائط المستخدمين الدائمة إلى تخزين كائنات دائم مثل R2.
• العمل في الخلفية: استبدل المجدولات المحلية للعملية وthread pools والعمليات الفرعية بعمل غير متزامن أصلي في المنصة.
• الاعتماديات: اختبر lockfile كاملاً على Python Workers، ثم افحص حجم الحزمة البالغ 64 MiB ونتيجة بدء التشغيل خلال 1 ثانية.
• العمليات: أعد بناء السجلات وتنبيهات الأخطاء والتراجع عن النشر والأسرار وخط أساس للأداء على مستوى المسارات.

من الذي ينبغي له ألا ينتقل؟ لا ينبغي تحويل تطبيق Django أحادي البنية ومستقر، بقاعدة بيانات تعمل ومسار إدارة واسع، إلى FastAPI لمجرد مسايرة الرائج. ولا ينبغي نقل خدمة FastAPI تعتمد على native wheels غير متاحة إلى Workers لمجرد ظهور صفحة توثيق للإطار. وعلى الفريق الذي تهيمن قاعدة بيانات بعيدة على زمن استجابته أن يصلح موضع البيانات قبل تغيير إطار معالجة الطلب.

الخطوة العملية للأسبوع المقبل

اختبر مساراً ممثلاً واحداً في الأسبوع المقبل، لا التطبيق بأكمله. اختر المسار الذي يجسد خصائص الحزم والحالة وزمن الاستجابة في نظام الإنتاج، ثم استخدمه لاستبعاد الخيارات الخاطئة بسرعة.

أسئلة شائعة عن Django وFastAPI على Cloudflare Workers