تبدأ منصات وقت التشغيل في التنافس على دخول سلسلة الأدوات الكاملة

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

التغيير الأكثر وضوحًا في سلسلة الأدوات خلال العامين الماضيين هو أن النظام الأساسي لم يعد راضيًا عن “الخطوة الأخيرة للنشر”. لقد بدأوا في المضي قدمًا، حيث جلبوا التطوير المحلي ومحاكاة وقت التشغيل واختبار التعليقات وإصدار الأوامر في نفس الرابط. مع الدمج الأخير لـ VoidZero في Cloudflare، فإن ما يستحق المشاهدة حقًا ليس أخبار الاستحواذ نفسها، بل إشارة أكثر وضوحًا: بدأت منصات وقت التشغيل في التنافس بشكل مباشر على الدخول إلى سلسلة الأدوات الكاملة.

بمجرد وصول أداة الإنشاء إلى وقت التشغيل، تتحرك حدود النظام الأساسي للأمام

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

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

لذا فإن التغييرات التي نراها الآن لم تعد مجرد أن النظام الأساسي يوفر محولًا لإطار عمل معين، ولكن في المقابل، يتم تحويل واجهة سطر الأوامر (CLI) الخاصة بالنظام الأساسي والمكونات الإضافية لوقت التشغيل والبيئة المحلية بشكل استباقي إلى شكل سلسلة أدوات يعرفها المطورون بالفعل. بهذه الطريقة يتغير المدخل. لم يعد النظام الأساسي ينتظر ظهور خطوة deploy. لقد دخلت السوق بالفعل بدءًا من dev وbuild وtest وحتى تنسيق المطالبة بالخطأ.

قام الوكيل بتضخيم جميع الاحتكاكات الصغيرة في سلسلة الأدوات التي يمكن تحملها.

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

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

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

ما يهم حقًا ليس محاذاة إطار العمل، ولكن من يزيل سير العمل الافتراضي.

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

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

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

هذا المسار مناسب فقط للفرق التي أعاقتها تعقيدات التسليم

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

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

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