Laravel مقابل Django: ما يختلف فعلًا

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

وما يلي هو ما يختلف فعلًا عند الاستخدام.

واجهة الإدارة

تُولَّد واجهة إدارة Django من نماذجك وتوجد في اللحظة التي توجد فيها. ولأداة داخلية، أو تطبيق إدخال بيانات، أو أي شيء يشغّل فيه الموظفون النظام مباشرةً، ذلك قدر كبير من العمل لا تؤديه أبدًا.

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

إن كان منتجك في أغلبه واجهة إدارة، فـ Django يبدأ متقدمًا. وإن كان على إدارتك أن تبدو كمنتجك لا كواجهة إدارة، تُغلق الفجوة ثم تنعكس.

العمل في الخلفية

هذه أوضح ميزة لـ Laravel وأكثرها شعورًا يوميًا لدى الفرق.

الطوابير والمجدول وتجميع المهام وحدود المعدل والمهام الفريدة وإعادات المحاولة بتباعد ولوحة لكل ذلك تأتي مع الإطار وموثَّقة كشيء واحد. وفي Django يكون العمل الخلفي Celery أو بديلًا - نظام منفصل بوسيطه وإعداده وأنماط فشله التشغيلية.

Celery قوي وواسع الاستخدام. وهو أيضًا نظام إضافي تشغّله، ولفريق بلا مهندس منصة فإن "إنه موجود بالفعل" يساوي أكثر مما توحي به مقارنة الميزات.

الـ ORM

كلاهما سجل نشط وهما أقرب مما يوحي به بناؤهما اللغوي. Eloquent أكثر تساهلًا وتعبيرًا حول العلاقات؛ وORM في Django أكثر صرامة وتوليده للهجرات أفضل - ينظر في نماذجك ويحسب الفرق ويكتب الهجرة.

وهجرات Laravel تُكتب يدويًا. ذلك طباعة أكثر وهو أيضًا سبب بقاء العمليات المحرجة مرئية، وهو أهم مما يبدو حين يقفل تغيير مخطط جدولًا كبيرًا.

Async وبيئة التشغيل

لدى Django عروض غير متزامنة ومسار ASGI وORM يتلقى دعم async تدريجيًا. ولدى Laravel طوابير للعمل البطيء وبيئات تشغيل طويلة العمر حيث تكون الإنتاجية هي القيد. كلاهما في منتصف الانتقال ولم ينتهِ أيّهما.

ولأغلب التطبيقات لا يقرر هذا شيئًا. ولتطبيق سمته المميزة التزامن، ليس أيّ منهما الإطار الذي تريد.

النظام البيئي حول اللغة

هذا هو القرار الحقيقي وهو لا يتعلق بأطر الويب إطلاقًا.

إن كان المنتج يشمل علم بيانات أو تعلّم آلة أو حوسبة علمية أو استخراج بيانات، فإن Python تزيل حدًّا. النموذج والتطبيق يعيشان في مستودع واحد، بلغة واحدة، ويُنشران معًا. وتلك ميزة كبيرة فعلًا وتساوي أكثر من كل نقاط هذا المقال مجتمعة حين تنطبق.

وإن كان المنتج تطبيق أعمال - مستخدمون وأدوار وسير عمل ومدفوعات وتكاملات ومكتب خلفي - فالنظام البيئي لـ PHP وLaravel عميق في ذلك الاتجاه بالضبط، ومجتمع التوظيف له كبير.

الاستضافة والتشغيل

قصة Laravel التشغيلية أكثر توحيدًا: PHP-FPM خلف خادم ويب، وعامل طابور تحت مشرف، ومدخل cron للمجدول. وهناك منصات مُدارة مبنية له تحديدًا.

وعمليات نشر Django تتنوع أكثر - أي خادم، وأي نموذج عمّال، وأي خادم async، وأي طابور مهام - وتلك المرونة تكلّف قرارًا عند كل خطوة. لا أحدهما صعب. لكن لأحدهما مفترقات أقل.

الخلاصة الصادقة

اختر Django إن كان المنتج يمسّ عمل بيانات أو تعلّم آلة، أو إن كانت واجهة الإدارة أغلب المنتج، أو إن كان فريقك يكتب Python.

واختر Laravel إن كان المنتج تطبيق أعمال بعمل خلفي وتكاملات وعمر طويل أمامه، أو إن كان فريقك يكتب PHP، أو إن كنت تتوقع التوظيف.

وإن لم تكن أي من الفقرتين لك بوضوح، فاختر ما يعرفه فريقك وضع الجدال الموفَّر في المخطط بدلًا من ذلك. ذلك القرار سيعمّر أطول من الإطارين.

إن كانت القائمة القصيرة إطارَي عمل ذوَي رأي لا لغتين، فـ Rails هي المقارنة الأقرب. وإن كان السؤال الكامن هو هل يريد هذا المشروع إطارًا كاملًا أصلًا، فتلك الصفحة الأعم.