Next.js مقابل Express: واحدٌ منهما فقط يعرض
Express خادم تبنون عليه، و Next.js إطار عرضٍ معه خادم. والاختيار بينهما في حقيقته اختيارٌ لمقدار ما تريدون كتابته بأنفسكم.
يُقارَن هذان لأن كليهما Node وكليهما يخدم HTTP، وعند هذا الحدّ ينتهي التشابه تقريبًا. Express إطار HTTP بسيط تركّبونه أنتم. و Next.js إطار عرض يصادف أن فيه خادمًا.
والقرار ليس مقارنةً في حقيقته، بل سؤال عمّا تبنونه.
إن كنتم تبنون واجهة برمجية فقط
استخدموا Express أو Fastify أو Hono. معالِجات مسارات Next.js موجودة وتعمل، لكنكم ستتحمّلون إطار عرض وخطوة بناء وموجّه مبنيًّا على نظام الملفات واعتمادية على React، من أجل خدمة لا تعرض شيئًا.
وتحديدًا، يبقى Express أفضل حين تكون لواجهتكم:
- مستهلكون خارجيون. مسارات ذات إصدارات، ومفاتيح واجهة، وعقود موثَّقة.
- سلسلة وسطاء خاصة بها. تحديد معدّل، والتحقّق من الطلبات، ومصادقة مخصّصة، وسجلّات تخصّكم.
- أي شيء طويل العمر. WebSockets، والأحداث المُرسَلة من الخادم، واتصالات تتجاوز عمر الطلب.
- قيود نشر. عملية Node بسيطة أسهل تشغيلًا على بنية تحتية لها آراؤها.
وإن كنتم تعرضون صفحات، فلا تبنوه بأنفسكم
الاتجاه المعاكس أقوى وأقلّ وضوحًا.
الفرق التي تبدأ بـ Express وتضيف React فوقه تنتهي إلى أن تكتب بيدها ما حسمه Next.js أصلًا: التوجيه، وتقسيم الشيفرة، وجلب البيانات على الخادم، والبثّ، وحدّ حزمة العميل، ومعالجة الصور، والتخزين المؤقّت. كل واحد منها أسبوع. ومجتمعةً هي إطار عمل، وسيكون إطارًا أسوأ، لأنه مشروع جانبي لا المنتج نفسه.
إن كان لتطبيقكم صفحات، فالحجّة لصالح Express هي الحجّة لصالح كتابة إطار عمل خاص بكم. وهذا صحيح أحيانًا، وغير صحيح غالبًا.
أين تكفي معالِجات المسارات فعلًا
لواجهة برمجية لا يستهلكها إلا واجهتكم الأمامية، تؤدّي معالِجات مسارات Next.js الغرض:
// app/api/products/route.ts
export async function GET(request: Request) {
const products = await db.product.findMany();
return Response.json(products);
}نشرٌ واحد، وقاعدة شيفرة واحدة، وأنواع مشتركة بين الواجهة البرمجية والمكوّنات التي تستدعيها. ولمعظم تطبيقات المنتجات، هذا هو القدر الصحيح من الآلية.
ومن المفيد معرفته: بالنسبة للبيانات التي تحتاجها صفحاتكم أنتم، لا تحتاجون مسارًا في الغالب. فـ Server Component يستطيع الاستعلام مباشرةً، و Server Action يستطيع التعديل - والالتفاف عبر واجهتكم البرمجية عادةٌ موروثة من بنية معروضة على العميل.
الترتيب الذي تنتهي إليه معظم الفرق
Express - أو Fastify، أو خدمة بـ Go، أو Laravel - يحمل منطق العمل والمهام. و Next.js يحمل الواجهة الأمامية. ويتحادثان عبر HTTP.
هذه هي الخلاصة نفسها التي في Next.js مقابل Laravel، وللسبب نفسه: مسار العرض ومنطق العمل مشكلتان مختلفتان، وأطر العمل تجيد واحدةً منهما لكلٍّ.
ما ينبغي تجنّبه
خادم Express مخصّص أمام Next.js. مدعوم، ويعطّل التحسين الثابت التلقائي للمسارات التي يخدمها - أي معظم ما جئتم من أجله. إن احتجتم وكيلًا، ضعوه أمام العمليتين بدل وضعه داخل إحداهما.
نقل سلسلة وسطاء Express إلى proxy.ts. الاصطلاح الذي حلّ محلّ الـ
middleware في الإصدار 16 يعمل على Node، و
بيئة تشغيله غير قابلة للضبط، ويعمل على طلبات لم
تقصدوها. هو لقرارات التوجيه، لا لخطّ معالجة طلبات.
