متى يكون Laravel الخيار الخطأ

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

Laravel افتراض جيد جدًا لتطبيق ويب خلفه قاعدة بيانات. وهذا هو المكان الذي ليس كذلك.

١. العمل في أغلبه حساب لا انتظار

معالجة الصور والفيديو، والعمل العددي واسع النطاق، وتدريب النماذج أو الاستدلال بها، وكل ما يشغل نواة ثوانيَ.

PHP ليست لغة سيئة للحساب، لكن نموذج عملية لكل طلب يعني أن مهمة ثقيلة تشغل عاملًا طوال مدتها. ادفعها إلى طابور وستكون قد نقلتها لا حللتها - صرت الآن تحتاج أسطول عمّال بحجم أثقل مهمة.

ما ينجح هو Laravel كتطبيق، والخطوة الثقيلة تعمل حيث تناسبها ويُتحدَّث إليها كخدمة. وما لا ينجح محاولة جعل PHP طبقة الحساب.

٢. آلاف الاتصالات الدائمة

نظام محادثة، أو تحرير تشاركي حيّ، أو خادم لعبة، أو تدفق تداول - كل ما يُبقي فيه العملاء اتصالًا مفتوحًا ويتلقون دفعات.

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

وانتبه إلى الحد، فهو مهم: الإشعارات العَرَضية المدفوعة إلى متصفح جيدة ومدعومة جيدًا. أما البث المستمر بحجم كبير فلا ينتمي إلى هنا.

٣. ضمانات زمن استجابة صارمة

أقل من جزء من الألف من الثانية، باستمرار، عند المئين التاسع والتسعين. مزايدات إعلانية، وبيانات أسواق، واستقبال قياسات بمعدلات عالية جدًا.

إقلاع إطار لكل طلب - ولو سريعًا، ولو مع تخزين شيفرة مترجمة - ليس كيف تبلغ تلك الميزانية. بيئة تشغيل طويلة العمر تزيل الإقلاع، وعند تلك النقطة تطلب من PHP أن تكون شيئًا لم تُصمَّم له بينما عدة لغات أخرى هي ذلك الشيء أصلًا.

٤. لا توجد طبقة ويب أصلًا

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

لأداة كونسول، مكوّنات كونسول Laravel متاحة وحدها. ولمكتبة، مكتبة.

٥. الفريق لا يكتب PHP

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

والحالة المضادة التوظيف: إن كنت تتوقع تنمية الفريق، فمجتمع PHP وLaravel كبير والإدماج قصير. وذلك حجة حقيقية لاختياره عمدًا - لكنها حجة عن ثمانية عشر شهرًا من الآن لا عن هذا الربع.

٦. يوجد منتج بالفعل يفعل ذلك

الأشيع، والأغلى حين يُتجاهل. متجر بكتالوج بسيط، أو مدوّنة، أو صفحة حجز، أو نموذج داخلي.

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

أين تكون الإجابة نعم

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

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

هذه الصفحة تجيب عن السؤال العام. فإن كنتم قد ضيّقتم الخيار إلى مرشّحَين، فالمقارنة المحددة أنفع: Symfony حين يكون الجدل عن مقدار البنية التي تريدون أن تُسلَّم لكم جاهزة، وRails إن كانت القائمة القصيرة إطارَي عمل كاملين ذوَي رأي، وDjango حين تكون لغة الفريق الأخرى Python، وNode حين يكون ما تبنونه واجهة برمجية لا غير.

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