تطبيقات ويب مبنية بـ Next.js.

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

ما يدخل في النطاق عادةً ونادرًا ما يُذكر في الطلب

• الحسابات: التسجيل، وتسجيل الدخول، واستعادة كلمة المرور، وتأكيد البريد، والدعوات، والأدوار التي تحدّد ما يصل إليه كل مستخدم.
• نموذج بيانات يصمد أمام الواقع — الكيانات، والعلاقات بينها، والحالات التي يمر بها كل سجل.
• واجهة إدارية لفريقك أنت: البحث عن سجل، وتصحيح بيانات خاطئة، وإرجاع مبلغ، وتعليق حساب، والتصدير. أحدهم يحتاجها دائمًا في اليوم الثاني.
• العمل في الخلفية: المهام المجدولة، والاستيراد والتصدير، وتوليد المستندات — كل ما هو أبطأ من أن يجري داخل طلب واحد.
• البريد المعاملاتي والإشعارات، مُرسَلة من نطاق موثَّق بما يكفي لكي تصل الرسائل فعلًا.
• رفع الملفات وتخزينها، بحدود للحجم وفحص للنوع وقواعد وصول تنطبق على الملف نفسه، لا على الصفحة التي تشير إليه فقط.
• المدفوعات، إن كان هناك مال يتحرك: عمليات كتابة لا يتكرر أثرها (idempotent)، ومعالجة webhooks، واسترجاع المبالغ، وسجل قابل للمطابقة.
• البيئات وعمليات النشر والنسخ الاحتياطية والسجلات وتتبّع الأخطاء — الأجزاء التي لا يعرضها أحد ويحتاجها الجميع في الثانية صباحًا.

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

يمكن لـ React أن يُعرَض على الخادم عند الطلب، أو وقت البناء، أو داخل المتصفح. ويتيح App Router في Next.js اختيار ذلك لكل مسار على حدة، وهذا الاختيار يحدّد سرعة التحميل الأول، وما إذا كانت محركات البحث ترى محتواك، وجودة التخزين المؤقت للصفحة، وما تدفعه مقابل تقديمها.

الخيارات الأربعة، ومتى يصح كل منها

• ثابت: يُعرَض وقت البناء ويُقدَّم من CDN. الأسرع والأرخص. مناسب للصفحات التسويقية والتوثيق والمقالات — كل ما هو واحد لدى كل زائر.
• توليد ثابت تدريجي: صفحات ثابتة يُعاد توليدها في الخلفية وفق جدول أو عند الطلب. مناسب لصفحات الكتالوج والمحتوى التي تتغيّر كثيرًا لكن ليس لكل مستخدم.
• عرض من الخادم لكل طلب: HTML يُبنى على الخادم وفيه بيانات المستخدم نفسه. مناسب للوحات المعلومات ولكل ما هو مخصّص ويجب أن يصل مع ذلك كـ HTML حقيقي.
• عرض في المتصفح: المتصفح يجلب المحتوى ويرسمه. مناسب خلف تسجيل الدخول، في الشاشات كثيفة التفاعل حيث لا يهم الظهور في البحث وتكون حداثة البيانات أهم من أول رسم.

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

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

المصادقة

جلسات في كوكي من نوع HTTP-only لمعظم التطبيقات، ورموز (tokens) حين يحتاج عميل جوّال منفصل أو طرف ثالث إلى الوصول. وتسجيل دخول اجتماعي أو مؤسسي عبر OAuth أو SAML حين يعمل مشتروك في شركات تشترط ذلك. واستعادة كلمة المرور وتأكيد البريد والدعوات والعامل الثاني ميزات فيها عمل حقيقي، لذلك تُحدَّد في النطاق بدل أن تُفترَض. أما التخويل فهو النصف الأصعب: تُفحَص الصلاحية على الخادم مع كل إجراء، لا بإخفاء زر.

البيانات

PostgreSQL افتراضيًا. يتعامل مع البيانات العلائقية وJSON والبحث النصي الكامل وطوابير المهام بكفاءة تكفي لئلا يحتاج معظم المنتجات إلى قاعدة بيانات ثانية. وتُشحن تغييرات المخطط على هيئة ترحيلات مُرقَّمة تعمل أثناء النشر، فتحصل كل بيئة على البنية نفسها بالترتيب نفسه، ويصير التراجع خطوة معروفة لا ارتجالًا. والقيود تعيش في قاعدة البيانات — not null وunique والمفاتيح الأجنبية — لأن شيفرة التطبيق ليست خط الدفاع الأخير.

المكتب الخلفي

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

ثلاثة مقاييس ميدانية تحدّد النتيجة التي تستخدمها Google فعلًا: Largest Contentful Paint للتحميل، وInteraction to Next Paint للاستجابة، وCumulative Layout Shift لثبات العرض. والعتبات المنشورة هي 2.5 ثانية و200 ميلي ثانية و0.1، تُقاس عند المئين الخامس والسبعين من الزيارات الحقيقية. نتيجة المختبر من حاسوب مطوّر أداة تشخيص. أما بيانات الميدان من أجهزة حقيقية على شبكات حقيقية فهي الرقم الذي يُحتسب.

ما الذي يُفسد كلًّا منها فعلًا

• LCP: صورة رئيسية غير محسّنة، أو استجابة بطيئة من الخادم، أو CSS يحجب العرض، أو خط ويب يحبس النص. قدّم الصورة بالمقاس الصحيح وبصيغة حديثة، وحمّل مسبقًا الصورة المهمة، ودع النص يظهر ريثما يُحمَّل الخط.
• INP: JavaScript كثير يعمل على الخيط الرئيسي في اللحظة التي ينقر فيها المستخدم. والعلاج عادةً JavaScript أقل لا JavaScript أسرع — مكوّنات عميل أقل، وحالة أقل محفوظة في أعلى الشجرة، واعتماديات أصغر.
• CLS: صور وعناصر مضمّنة بلا مساحة محجوزة، ولافتات تُحقن فوق المحتوى، وخطوط تتبدّل إلى مقاسات مختلفة. وكل ذلك يمكن منعه في الترميز.

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

التطبيق الذي لا يمكن تشغيله بلوحة المفاتيح يستبعد من لا يستطيعون استعمال الفأرة، وهو عادةً معطوب قليلًا لدى الجميع أيضًا. وهي كذلك مطلب قانوني متزايد لا تفضيل: يسري قانون إتاحة الوصول الأوروبي منذ يونيو 2025 على كثير من الخدمات الرقمية الموجّهة للمستهلك والمباعة في الاتحاد الأوروبي، والمعيار الذي يستند إليه، EN 301 549، يحيل إلى WCAG.

ما نفعله بحكم العادة

• HTML دلالي أولًا — أزرار حقيقية وروابط حقيقية وعناوين وقوائم حقيقية — لأنه يحمل السلوك والمعنى بلا كلفة.
• كل عنصر تفاعلي يمكن بلوغه بلوحة المفاتيح، بترتيب معقول، مع نمط تركيز مرئي لا يحذفه أحد لأنه يبدو غير مرتب.
• حقول نماذج لها تسميات، وأخطاء مرتبطة بالحقل الذي تخصّه ومُعلَنة لقارئ الشاشة، ونص خطأ يقول ما العمل التالي.
• تباين مفحوص وفق WCAG AA، بما في ذلك حالات التحويم والتركيز والتعطيل.
• نص بديل يحمل المعلومة، أو نص بديل فارغ حين تكون الصورة زخرفية.
• الحوارات والقوائم وعناصر التحكم المخصّصة مبنية على أسس مختبَرة، مع حصر التركيز ومعالجة مفتاح الهروب، بدل div عليه معالج نقر.

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

تطبيق الويب لا يُسلَّم عند كتابة الشيفرة. عليه أن يعمل في مكان ما، وأن يبقى متاحًا، وأن يكون قابلًا للاستعادة. وهناك شكلان معقولان، والاختيار بينهما يتعلق أساسًا بمن يتحمّل العمل التشغيلي.

• منصة مُدارة: نشر عند كل دفعة، وبيئة معاينة لكل فرع، وCDN عالمي، وتوسّع لا تضبطه بنفسك. أقل عبء تشغيلي، وتسعير بحسب الاستهلاك، وأسرع طريقة لتشغيل تطبيق Next.js كما ينبغي.
• حاويات على سحابة أو على خادم افتراضي أوروبي: إعداد أكثر ومراقبة تتولاها بنفسك، لكن بتسعير يمكن التنبؤ به — وهو الجواب الصحيح حين تفرضه إقامة البيانات، أو تكامل داخل المؤسسة، أو وجود فريق منصات قائم.

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

يُجهَّز في كل مشروع

• بيئتا إنتاج وتجهيز منفصلتان، وبيئة التجهيز موصولة ببيئة الاختبار لدى كل طرف ثالث.
• نسخ احتياطية آلية، واستعادة جُرِّبت مرة واحدة على الأقل — النسخة التي لم تُختبَر اعتقاد لا نسخة احتياطية.
• تتبّع أخطاء مع وسم الإصدارات، ليُنسَب أي استثناء جديد إلى عملية النشر التي أحدثته.
• نشر من الفرع الرئيسي عبر CI، مع طريق للعودة، لأن التراجع مسألة وقت لا احتمال.

المستودع وحسابات السحابة والنطاقات لك منذ أول commit. ولا يُحفَظ شيء مهم في حساب نملكه نحن.

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

النظام هو القرار الصحيح حين

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

وهو القرار الخاطئ حين

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

وحين يكون القرار صحيحًا نبنيه headless: المحتوى يعيش في خدمة خاصة به خلف API موصوف الأنواع، وتبقى الواجهة تطبيق Next.js يخزّن مؤقتًا ويعيد التحقق. هذا الموقع يعمل بهذه الطريقة — كل نص فيه قابل للتحرير دون نشر — وهو أيضًا سبب معرفتنا بمواضع الحواف الحادة: نمذجة المحتوى كصفحات بدل نمذجته كبيانات، ونسيان أن المعاينة تحتاج مسارها الخاص عبر التخزين المؤقت.