لماذا تختار الفرق Next.js
يضيف Next.js ما يتركه React مفتوحًا في أي موقع إنتاجي: المسارات، والعرض، وتحميل البيانات، ومعالجة الصور والخطوط، ومكانًا لكتابة شيفرة الخادم بجانب الواجهة. هذا يوفر كثيرًا من أعمال الربط، ويعطي الفريق طريقة واحدة لكل مهمة.
- العرض على الخادم والعرض الثابت. تصل الصفحة جاهزة بصيغة HTML، فيظهر المحتوى بسرعة وتقرؤه محركات البحث دون تشغيل سكربتات. ويمكن بناء كل صفحة مسبقًا، أو تحديثها بجدول زمني، أو عرضها عند كل طلب.
- مسارات قائمة على المجلدات. تتحول المجلدات إلى عناوين، مع تخطيطات مشتركة وحالات تحميل وشاشات أخطاء في كل مستوى.
- أدوات للأداء. تقسيم تلقائي للشيفرة، وتحسين للصور، وتحميل للخطوط، وبث تدريجي للأجزاء البطيئة من الصفحة.
- صداقة محركات البحث. تُنشأ البيانات الوصفية وخرائط الموقع وروابط اللغات البديلة والبيانات المنظمة على الخادم مع الصفحة نفسها.
- قاعدة شيفرة واحدة للصفحات وواجهات API. تقع معالجات المسارات ودوال الخادم بجانب الصفحات التي تستدعيها، وتُكتب كلها بلغة TypeScript.
لا يجعل شيء من هذا منتجًا بطيئًا سريعًا بمجرده. تبقى السرعة مرهونة بأحجام الصور والسكربتات الخارجية واستعلامات قاعدة البيانات، ولهذا تهم عوامل تكلفة منصات الويب بقدر اختيار الإطار نفسه.
متى يكون Next.js هو الخيار المناسب
- مواقع التسويق والمحتوى التي يجب أن تظهر في البحث وتُحمَّل بسرعة بلغتين.
- بوابات العملاء ولوحات المتابعة التي تجمع صفحات عامة ومناطق لا تُفتح إلا بتسجيل الدخول.
- منصات SaaS والمتاجر الإلكترونية، حيث تلتقي الصفحات الموجهة لمحركات البحث وشاشات التطبيق في قاعدة شيفرة واحدة.
- الفرق التي تعمل أصلًا بـ React وTypeScript وتريد الحفاظ على مجموعة مهارات واحدة.
متى تكون أداة أخرى أنسب
- موقع تعريفي صغير يحرره شخص واحد من فريق التسويق كل أسبوع. قد يصدر بسرعة أكبر على أداة بناء مرئية مثل Webflow، وتكون صيانته أقل كلفة.
- منتج هو في الأساس تطبيق جوال. ابدأ بالتطبيق، ثم يأتي موقع Next.js لاحقًا للتسويق وتسجيل الدخول.
- أعمال خلفية ثقيلة تعمل في الزمن الفعلي أو تستغرق وقتًا طويلًا. يستطيع Next.js أن يكون واجهتها، لكن الطوابير وبروتوكولات البث والمهام الدفعية مكانها خدمات منفصلة.
- فريق بلا خبرة في React وأمامه موعد قريب. كلفة التعلم حقيقية، وتنعكس على الجدول الزمني.
قاعدة عملية: اختر Next.js حين يحتاج الموقع أن يُعثر عليه في البحث، وأن يُحمَّل بسرعة على هواتف متوسطة الأداء، وأن يحمل منطق تطبيق. وإن احتاج واحدة من هذه فقط فقد تكفي أداة أخف.
كيف نبني مشروع Next.js
يبدأ كل مشروع بمراجعة للتهديدات، والبنية أدناه نابعة منها. هذه طريقتنا في المنتجات التي نبنيها، وتتغير تفاصيلها بحسب المنتج. ويرد وصف الخدمة الأوسع في صفحة تطوير المواقع.
App Router ومكونات الخادم
نعتمد App Router. تُعرض المكونات على الخادم افتراضيًا، فتبقى عمليات الوصول إلى البيانات والأسرار والمكتبات الثقيلة بعيدة عن حزمة المتصفح. ولا نحوّل مكونًا إلى مكون عميل إلا إذا احتاج إلى حالة أو تأثيرات أو واجهات المتصفح، ونُبقي هذه المكونات في أطراف الشجرة.
البيانات والتخزين المؤقت
نقرر لكل صفحة هل هي ثابتة أم تُحدَّث دوريًا أم تُعرض عند كل طلب. وقد تغيّرت الإعدادات الافتراضية للتخزين المؤقت بين إصدارات الإطار، لذلك نكتب القصد صراحة (ما الذي يُخزَّن، ولكم من الوقت، وما الذي يمسحه) ونختبره بدل الاعتماد على الافتراضي. وتمر القراءة عبر طبقة بيانات صغيرة تتحقق من الصلاحيات أيضًا، فلا تستطيع صفحة جلب ما لا يحق للمستخدم رؤيته.
ثنائية اللغة ومن اليمين إلى اليسار
اللغة جزء من المسار، مثل /en و/ar. نضبط سمتي lang وdir على المستند، ونستخدم في التخطيطات خصائص CSS المنطقية (البداية والنهاية بدل اليمين واليسار)، ويكون لكل لغة بياناتها الوصفية وروابط اللغة البديلة. ونختبر الخطوط العربية وارتفاع الأسطر والأرقام ولا نفترض سلامتها. وفي دليل المنتجات ثنائية اللغة العربية والإنجليزية تفصيل أوسع.
الاختبار والنشر
قبل كل إصدار نشغّل فحوص الأنواع والتدقيق البرمجي واختبارات الوحدات لمنطق العمل، واختبارات شاملة للمسارات الأساسية مثل تسجيل الدخول والنماذج. وننشر على Vercel أو على استضافة أخرى مثل AWS أو Azure أو Google Cloud أو منصة حاويات، بحسب مكان بياناتك ومتطلباتك. وتتيح لك نسخ المعاينة مراجعة كل تغيير في العرض الأسبوعي.
نقاط أمان خاصة بـ Next.js
ينقل Next.js الشيفرة بين الخادم والمتصفح، وهذا يخلق أنماط فشل لم تكن في المواقع الأقدم. والإعداد الآمن افتراضيًا يغطي كلًا منها. وتجد الأساسيات الأوسع في قائمة التحقق للأمان الافتراضي في الويب.
| المجال | ما يجب فعله | الخطأ الشائع |
|---|---|---|
| الترويسات وسياسة أمان المحتوى | أرسل سياسة أمان المحتوى وHSTS وخيار نوع المحتوى وسياسة المُحيل وقيود التضمين في الإطارات. ابدأ بوضع التقرير فقط ثم فعّل الإلزام. | إضافة سياسة مرة واحدة باستثناءات واسعة وعدم تشديدها بعد ذلك. |
| إجراءات الخادم ومعالجات المسارات | عامل كل منها كنقطة وصول عامة: تحقق من الهوية والصلاحية وتحقق من المدخلات على الخادم وفق مخطط محدد. | افتراض أن النموذج في الصفحة هو الجهة الوحيدة التي تستدعيها. |
| الأسرار ومتغيرات البيئة | أبقِ الأسرار على الخادم وافصلها لكل بيئة. المتغيرات ذات البادئة العامة وحدها تُرسل إلى المتصفح. | وضع مفتاح API في متغير عام "مؤقتًا". |
| البيانات الممررة إلى مكونات العميل | مرّر الحقول التي يعرضها المكون فقط. | إرسال سجل كامل من قاعدة البيانات، فتصل حقول مخفية داخل الصفحة. |
| الصلاحيات | تحقق من الوصول في طبقة البيانات، لا في إعادة توجيه على مستوى الطلب وحدها. | حماية منطقة كاملة بقاعدة middleware واحدة. |
| الاعتماديات | استخدم ملف القفل، وافحص الاعتماديات في CI، وحدّث الإطار والحزم بانتظام. | البقاء على إصدار قديم لأنه يعمل. |
سياسة أمان المحتوى هي خط الدفاع الرئيسي في المتصفح ضد السكربتات المحقونة. والسياسة التي تعتمد قيمة nonce جديدة لكل طلب تتطلب عرض صفحاتها عند كل طلب، وهذا يؤثر في التخزين المؤقت الثابت، لذلك نحسم هذه المفاضلة مبكرًا.
أظهرت تنبيهات سابقة على مستوى الإطار أن فحوص مستوى الطلب قد يُلتف عليها، وهذا سبب إضافي للتحقق من الصلاحيات في طبقة البيانات أيضًا. وقبل الإطلاق تأتي مراجعة أمنية بقائمة إصلاحات مرتبة بالأولوية، ويرد التقييم الأعمق ضمن الأمن السيبراني.
أسئلة تطرحها على أي فريق Next.js
- أي الصفحات ثابتة، وأيها يُحدَّث دوريًا، وأيها يُعرض عند كل طلب، ولماذا؟
- أين تُفرض الصلاحيات، وهل تُختبر؟
- كيف تُدار الأسرار في بيئات التطوير والاختبار والإنتاج؟
- ما الذي يحدث للتخطيط العربي والخطوط والبيانات الوصفية والبحث في النسخة من اليمين إلى اليسار؟
- من يحدّث الإطار والاعتماديات، وكل كم مدة؟