تطوير تطبيقات Next.js

معظم مشاريع Next.js تفشل ببطء. الإصدار الأول يخرج في موعده ويبدو جيدًا. ثم يتضخّم الحزمة، وينتشر use client صعودًا في الشجرة، وتتحوّل كل صفحة إلى ديناميكية في صمت، وبعد ثمانية عشر شهرًا يتجادل الفريق حول إعادة كتابة كل شيء.

هذا التآكل معماريّ بطبيعته، ويمكن تفاديه. ولا واحد من القرارات المسبّبة له صعبٌ لحظة اتّخاذه - إنما تُتّخذ دون أن ينتبه أحد إلى أن ثمّة قرارًا يُتّخذ أصلًا.

ما الذي نبنيه

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

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

كيف تُتّخذ القرارات المعمارية

تُختار استراتيجية العرض لكل مسار على حدة، لا للمشروع ككل، وتُدوَّن قبل بدء التنفيذ:

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

نتعامل مع الحدّ الفاصل بين العميل والخادم بوصفه قرارًا تصميميًا موثّقًا. فـ Server Components هي الوضع الافتراضي، وuse client قرار مقصود ومُراجَع يتوقّف عند أصغر ورقة تفاعلية بدل أن يتسلّق إلى تخطيط كامل.

يبدو ذلك تفضيلًا في الأسلوب حتى تُسعّروه. توجيه use client على تخطيط يُرسل ذلك التخطيط وأبناءه وتبعياتهم إلى كل زائر على كل مسار تحته. والتوجيه نفسه على القائمة المنسدلة الوحيدة التي تحتاج حالة يُرسل بضعة كيلوبايتات. الشيفرة واحدة؛ والموضع هو التكلفة كلّها.

طبقة البيانات تُقرَّر في الوقت نفسه

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

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

كيف يسير المشروع

على مراحل، تنتهي كل واحدة بشيء منشور تستطيعون استخدامه.

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

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

ما الذي يُحرّك التقدير

ليس إطار العمل. ما يُحدّد مدّة مشروع Next.js هو ما يُحدّد مدّة أي مشروع، ومعرفة أيّ هذه البنود ينطبق عليكم أنفع من سعر يوم عمل:

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

ما الذي يُسلَّم معه

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

هذه المذكّرة الأخيرة هي ما يهمّ في السنة الثانية. إنها الفرق بين قاعدة شيفرة يُوسّعها فريقك وقاعدة شيفرة يستبدلها.

متى تكون هذه الصيغة خاطئة

إن كان لديكم مهندسون أكفاء وكانت الفجوة معمارية لا في الطاقة الاستيعابية، فالذي تريدونه هو التطوير على App Router: نضع نحن الحدّ ونموذج التخزين المؤقت وبنية المسارات، ويبني فريقكم فوقها، وتبقى المعرفة في بيتكم.

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

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