Laravel أم Node لواجهة برمجية: اختر بشكل العمل

الإطار الذهني الذي ينتج قرارات سيئة هنا هو "أيهما أفضل". كلاهما يخدم JSON باقتدار، ولكليهما نظام بيئي ناضج، وكلاهما يشغّل أنظمة كبيرة الآن.

والسؤال المفيد هو فيمَ تقضي طلباتك وقتها فعلًا.

ماذا تعني نماذج التشغيل عمليًا

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

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

لا أحدهما أفضل. هما جيدان لأشكال مختلفة.

اختر بشكل العمل

في أغلبه انتظار لخدمات أخرى. الواجهة التي تتوزّع على خمسة أنظمة وتجمّع النتائج تقضي حياتها في الانتظار. وحلقة الأحداث تعالج ذلك بجزء من الموارد. تلك هي موطن Node الحقيقي.

في أغلبه قاعدة بيانات واحدة وقواعد عمل. تحقق، وخوِّل، واستعلم، وأعد. كلاهما يتعامل معها، وهنا تقرر المنظومة المحيطة - وهي القسم التالي.

اتصالات طويلة العمر بحجم كبير. websockets، وأحداث من الخادم، وتدفق اشتراك. Node، أو شيء مبني لذلك. وLaravel يبث إلى خادم اتصالات منفصل بدل أن يحملها، وهو الترتيب الصحيح للإشعارات والخطأ إن كانت الاتصالات هي المنتج.

حساب ثقيل. ولا أحدهما في الحقيقة. كلاهما يريد ذلك العمل في خدمة مصمَّمة له.

الجزء الذي يُستهان به: ماذا يأتي معه

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

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

وNestJS يضيّق هذه الفجوة كثيرًا وهو المقارنة الأعدل إن كان البديل "Node ببنية" لا "Express بوسائط". ومع ذلك لا يجلب ORM وطابورًا ومجدولًا كقرار واحد.

مشكلة واجهة الإدارة، التي تقرر أكثر مما ينبغي

أغلب واجهات الأعمال تحتاج مكتبًا خلفيًا: موظفو دعم يبحثون في السجلات، ويصدرون استردادات، ويصحّحون بيانات. وفي Laravel ذلك لوحة إدارة تُثبَّت وتُضبط في أيام. وفي Node غالبًا واجهة يبنيها أحد، وهي تطبيق ثانٍ لم يقدّر أحد حجمه.

وإن كان لمنتجك بشر يشغّلونه - ولأغلبها ذلك - فهذا عامل أكبر من مقارنة بيئات التشغيل ويُترك خارج القرار روتينيًا.

حجة اللغة الواحدة

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

وتساوي أقل بكثير حين تكون الخلفية فريقًا منفصلًا، أو حين تستهلك الواجهة البرمجية عملاء محمولون أيضًا، أو حين يتبين أن الشيفرة المشتركة حفنة واجهات كان يمكن توليدها من وثيقة OpenAPI على أي حال.

ما نراه أكثر

Laravel يملك المجال - قاعدة البيانات والقواعد والطابور والإدارة - وخدمة Node صغيرة تتولى ما هو كثيف الاتصالات أو يتقاسم شيفرة مع المتصفح. ويتحدثان عبر HTTP بعقد صريح.

تلك القسمة تتبع العمل لا التفضيل، وتنجو من تغيّر الفريق. وما لا ينجو هو الترتيب الذي رُسم حدّه بحسب من كان في الغرفة.

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