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

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

هذا التآكل معماريّ بطبيعته، ويمكن تفاديه.

ما الذي نبنيه

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

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

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

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

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

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

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

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