معالجات المسارات مقابل إجراءات الخادم في Next.js: متى نستخدم كلًّا منهما
جدول المحتويات
عن الكاتب
Ahmed Mahmoud
كاتب ومطوّر
مهندس برمجيات شغوف بتطوير الويب وتصميم تجربة المستخدم.
مؤسّس ديفيا · eng-ahmed.com ↗أبرز النقاط
إجراء الخادم (Server Action) دالة غير متزامنة موسومة بـ `'use server'` يكشفها Next.js كنقطة نهاية POST داخلية نستدعيها مباشرة من مكوّن خادم أو عميل — غالبًا كـ action لنموذج.
معالج المسار (Route Handler) دالة تُصدَّر من `app/api/**/route.ts` تحمل اسم طريقة HTTP (GET وPOST وغيرهما)، تستقبل كائن Request قياسيًا وتُرجع كائن Response.
نستخدم إجراء الخادم لعمليات التعديل القادمة من واجهتنا — فهو يوفّر التحسين التدريجي ويتيح استدعاء `revalidatePath`/`revalidateTag` في نفس الرحلة.
نستخدم معالج المسار لواجهات البرمجة العامة وخطافات الويب واستدعاءات OAuth ونقاط GET القابلة للتخزين المؤقت والبث — أي شيء يستهلكه عميل غير React عبر رابط ثابت.
كلاهما نقطة نهاية عامة. إجراء الخادم ليس خاصًا لمجرد أنه بلا رابط ظاهر؛ نتحقق من الهوية والصلاحيات ونتحقق من المدخلات داخل كل إجراء ومعالج.
لا حاجة لأيٍّ منهما لقراءة البيانات داخل مكوّن خادم — نستعلم من مصدر البيانات مباشرة ونتجنّب قفزة HTTP إضافية.
ما الفرق بين إجراء الخادم ومعالج المسار في Next.js؟
إجراء الخادم دالة غير متزامنة موسومة بالتوجيه `'use server'` يحوّلها Next.js إلى نقطة نهاية بأسلوب RPC. نستوردها ونستدعيها كدالة عادية — غالبًا كـ action لنموذج — ويتولى Next.js تسلسل الاستدعاء عبر طلب POST خلف الكواليس.
معالج المسار دالة تُصدَّر من ملف `route.ts` داخل `app/`، تحمل اسم طريقة HTTP التي تخدمها (GET وPOST وPUT وPATCH وDELETE). تستقبل كائن Request قياسيًا وتُرجع Response قياسيًا، فنتحكم في رمز الحالة والترويسات والجسم مباشرة. وهو بديل App Router لـ `pages/api`.
متى نستخدم إجراء الخادم بدلًا من معالج المسار؟
نستخدم إجراء الخادم حين ينطلق التعديل من واجهتنا في React دون مستهلك خارجي. نموذج يحدّث ملفًا شخصيًا، زر يحذف صفًا، مفتاح إعجاب — كلها تنتمي لإجراءات الخادم لأن الإجراء يقع بجوار المكوّن الذي يستدعيه ولا يحتاج عقدًا عامًا.
يمنحنا إجراء الخادم أمرين لا يوفّرهما معالج المسار: التحسين التدريجي، فالنموذج يُرسَل ويعمل حتى قبل ترطيب JavaScript؛ وإعادة التحقق من الذاكرة المؤقتة في مكانها، إذ يؤدي استدعاء `revalidateTag('profile')` في نهاية الإجراء إلى إعادة عرض مكوّنات الخادم المتأثرة في نفس الرحلة دون إعادة جلب يدوي من العميل.
متى نستخدم معالج المسار بدلًا من إجراء الخادم؟
نستخدم معالج المسار حين يحتاج شيء خارج شجرة React لدينا لاستدعاء النقطة عبر رابط ثابت. مستقبِلات خطافات الويب مثل Stripe وGitHub، واستدعاءات OAuth، ومستهلكو واجهات البرمجة من تطبيقات الجوال أو الأطراف الثالثة، ومهام cron، وأي نقطة GET نريد تخزينها مؤقتًا على شبكة التوزيع — كلها تتطلب عقد HTTP الصريح الذي يوفّره معالج المسار وحده.
معالجات المسار أيضًا الخيار الوحيد حين نحتاج وصولًا خامًا للطلب أو بثًا. يحتاج خطاف Stripe الجسم غير المُحلَّل للتحقق من التوقيع؛ ويحتاج بثّ الأحداث المُرسَلة من الخادم أو بثّ رموز نموذج لغوي إرجاع ReadableStream. تُرجع إجراءات الخادم قيمة مُسلسلة واحدة ولا تقدر على أيٍّ منهما.
كيف يتقارن معالج المسار مع إجراء الخادم؟
طريقة الاستدعاء: يُستورد إجراء الخادم ويُستدعى كدالة؛ بينما يُستدعى معالج المسار بطلب HTTP إلى رابط.
طريقة HTTP: يعمل إجراء الخادم دائمًا كـ POST داخليًا؛ بينما يخدم معالج المسار أي طريقة (GET وPOST وPUT وPATCH وDELETE).
العملاء الخارجيون: لا يملك إجراء الخادم عقدًا عامًا ثابتًا؛ بينما يكشف معالج المسار رابطًا وطريقة ثابتين للعملاء غير React.
التحسين التدريجي: يعمل نموذج إجراء الخادم دون JavaScript؛ ولا يوفّره معالج المسار.
البث ونقاط GET القابلة للتخزين: يدعم معالج المسار كليهما (ReadableStream وCache-Control)؛ ولا يدعم إجراء الخادم أيًّا منهما.
الأنسب لـ: تناسب إجراءات الخادم عمليات التعديل من واجهتنا؛ وتناسب معالجات المسار واجهات البرمجة العامة وخطافات الويب والبث.
هل نحتاج معالج مسار لجلب بيانات صفحتنا؟
لا. داخل مكوّن الخادم نستعلم من قاعدة البيانات أو نستدعي الخدمة مباشرة — دون حاجة لمعالج مسار. تغليف الاستعلام في `app/api` وجلبه من نفس الخادم يضيف رحلة HTTP وطبقة تخزين ثانية دون فائدة.
نحتفظ بنقاط GET في معالجات المسار للبيانات التي يحتاجها عميل مختلف: واجهة برمجة JSON عامة، أو استجابة نريد تخزينها على الحافة عبر Cache-Control، أو نقطة يستدعيها تطبيق جوال.
هل كلٌّ من إجراءات الخادم ومعالجات المسار نقاط نهاية عامة؟
نعم — كلاهما نقطة نهاية POST يمكن الوصول إليها علنًا، وهذا أكثر خطأ نراه. إجراء الخادم ليس خاصًا لمجرد أنه يُستدعى من مكوّن ولا يُظهر رابطه أبدًا. يحوّل Next.js كل إجراء إلى نقطة نهاية بمعرّف يصعب تخمينه، لكن يمكن استدعاء هذا المعرّف مباشرة بطلب مُصمَّم. المعرّف تعمية لا تفويض.
نتعامل مع كل إجراء خادم وكل معالج مسار كنقطة دخول غير موثوقة: نتحقق من هوية المستدعي، ونتأكد من سماحه بتنفيذ العملية، ونتحقق من كل مدخل داخل جسم الدالة. واجهة العميل لا تفرض شيئًا — حقل نموذج مخفي أو زر معطّل لا يوقف أحدًا.
أسئلة شائعة
س: هل يمكن لإجراء الخادم معالجة طلب GET؟
ج: لا. تُنفَّذ إجراءات الخادم دائمًا كـ POST. لنقطة GET قابلة للتخزين المؤقت، استخدم معالج مسار يُصدّر دالة GET.
س: هل نستخدم معالج مسار لجلب بيانات صفحتنا؟
ج: لا. داخل مكوّن الخادم، استعلم من مصدر البيانات مباشرة. يضيف معالج المسار رحلة HTTP إضافية وطبقة تخزين خاصة به دون فائدة حين تكون الصفحة معروضة على الخادم أصلًا.
س: هل إجراءات الخادم آمنة افتراضيًا لأنها بلا رابط ظاهر؟
ج: لا. يتحوّل كل إجراء خادم إلى نقطة نهاية POST قابلة للاستدعاء. تحقّق من الهوية والصلاحيات والمدخلات داخل الإجراء نفسه؛ فالمعرّف المُولَّد ليس حدًّا أمنيًا.
س: أيّهما يدعم استجابات البث؟
ج: معالجات المسار. أرجِع ReadableStream للأحداث المُرسَلة من الخادم أو بثّ رموز نموذج لغوي. يُرجِع إجراء الخادم نتيجة مُسلسلة واحدة ولا يبثّ.
س: هل يمكن لتطبيق جوال أو خدمة طرف ثالث استدعاء إجراءات الخادم لدينا؟
ج: ليس بموثوقية. تُولَّد معرّفات إجراءات الخادم وقت البناء وليست عقدًا عامًا ثابتًا. اكشف معالج مسار برابط مُرقَّم لأي مستهلك خارجي.
قراءات إضافية
هندسة الواجهات الأمامية
ترحيل المشاريع من Edge Runtime في Vercel: ملاحظات ميدانية
بيئة Edge Runtime في Vercel أصبحت قيد الإيقاف التدريجي لصالح Node.js على Fluid Compute — إليكم ما وجدناه أثناء ترحيل مسارات Next.js، ولماذا استمر البث بالعمل دون أي تغيير.
هندسة الواجهات الأمامية
مُحوِّل React في 2026: ما الذي يحفظه في الذاكرة المؤقتة (وما الذي لا يحفظه)
مُحوِّل React أُطلق بشكل مستقر مع React 19 ويُدرج الحفظ في الذاكرة المؤقتة تلقائياً للمكوِّنات والخطافات وردود الفعل. بعد تفعيله في مشاريع متعددة، هذا ما يُعالجه وما يتجاوزه وما إذا كان يجب حذف استدعاءات useMemo.