تطوير تطبيقات AI باستخدام Server Actions في Next.js 15: استبدال API Routes

تطوير تطبيقات AI باستخدام Server Actions في Next.js 15: استبدال API Routes

45 دقيقة
١٥ يناير ٢٠٢٦
المرحلة 1 من 4

مقدمة إلى Server Actions: فلسفة Next.js الجديدة

الفصل الأول: مقدمة إلى Server Actions - فلسفة Next.js الجديدة

الانتقال من واجهات برمجة التطبيقات المعقدة إلى دوال الخادم المباشرة.

مرحبًا بك في رحلة إعادة تعريف كيفية بناء تطبيقات الويب الحديثة، وخاصة تطبيقات الذكاء الاصطناعي. لسنوات، كان نموذج إنشاء واجهة برمجة تطبيقات (API) منفصلة ثم استدعاؤها من واجهة المستخدم هو النهج السائد. لكن مع Next.js 15، تقدم لنا Server Actions فلسفة جديدة جذرية: "لماذا لا نكتب منطق الخادم مباشرة داخل مكونات React الخاصة بنا؟". هذا الفصل ليس مجرد مقدمة تقنية؛ إنه شرح لفلسفة تطوير أكثر اتحادًا وكفاءة.

العصر القديم: تعقيد مسارات API

لنفهم قيمة Server Actions، يجب أن نعود خطوة للوراء. في التطبيقات التقليدية (حتى إصدارات Next.js السابقة)، كان تدفق العمل يشبه هذا:

  • تنشئ ملفًا في /app/api/chat/route.js.
  • تكتب دالة معالجة (handler) مثل POST للتعامل مع الطلبات.
  • في مكون React (على العميل)، تستخدم fetch() أو مكتبة مثل axios لإرسال طلب إلى هذا المسار.
  • تدير الحالة، ومعالجة الأخطاء، والحمل، والتحديثات يدويًا.

هذا النموذج يخلق انفصالًا بين مكان تعريف المنطق (ملف API) ومكان استخدامه (المكون). كما يضيف عبئًا في كتابة الكود وإدارته.

تحذير: في تطبيقات الذكاء الاصطناعي، حيث تكون الاستدعاءات غالبًا متتابعة وتحتاج معالجة تدفق (streaming)، يصبح هذا النموذج أكثر تعقيدًا. تخيل كتابة منطق لاستقبال تدفق من نموذج لغة كبير (LLM) في مسار API، ثم إعادة إرساله إلى العميل، ثم معالجته في حالة React. إنه سلسلة طويلة من النقاط التي قد تتعطل.

الفلسفة الجديدة: Server Actions

تأتي Server Actions في Next.js 15 كحل جذري. الفلسفة بسيطة: "اكتب دالة. ضعها في مكون الخادم. استدعها مباشرة من الكود الخاص بك.". لا حاجة لملفات route.js منفصلة، ولا لـ fetch، ولا لإدارة نقاط النهاية يدويًا.

المبادئ الأساسية

  • الاتحاد الكامل: يقع منطق الخادم والعميل في نفس المكان المنطقي (المكون)، مما يحسن قابلية الصيانة والقراءة.
  • الأمان التلقائي: يتم تنفيذ Server Actions بشكل افتراضي في بيئة الخادم الآمنة. بيانات الاعتماد والمفاتيح السرية لا تتعرض أبدًا للعميل.
  • التكامل مع نظام Next.js: تعمل بشكل سلس مع التخزين المؤقت (Caching)، وإعادة التحقق (Revalidation)، وإعادة التوجيه (Redirects)، ومعالجة النماذج.
  • نموذج برمجة مألوف: مجرد استدعاء دالة. هذا يقلل من الحواجز المعرفية.
ملاحظة: لا تخلط بين Server Actions ووظائف الخادم العادية في مكونات الخادم. مكون الخادم (Server Component) يُصّرح مرة واحدة عند التقديم. أما Server Action فهي دالة يمكن استدعاؤها عند حدوث تفاعل (نقرة زر، إرسال نموذج) من العميل أو من خادم آخر.

مقارنة عملية: API Route مقابل Server Action

لنرى الفرق بأنفسنا. تخيل أننا نريد إنشاء نقطة نهاية لإنشاء مشاركة جديدة في مدونة.

الطريقة القديمة: مسار API


// ملف: /app/api/posts/route.js
import { NextResponse } from 'next/server';
import { connectToDatabase } from '@/lib/mongodb';

export async function POST(request) {
  try {
    const body = await request.json(); // 1. تحليل الجسم
    const { title, content } = body;

    // 2. التحقق من الصحة (يجب كتابته يدويًا)
    if (!title || !content) {
      return NextResponse.json(
        { error: 'العنوان والمحتوى مطلوبان' },
        { status: 400 }
      );
    }

    // 3. الاتصال بقاعدة البيانات (يتم في كل طلب)
    const { db } = await connectToDatabase();

    // 4. الإدراج
    const result = await db.collection('posts').insertOne({
      title,
      content,
      createdAt: new Date(),
    });

    // 5. إرجاع الرد
    return NextResponse.json(
      { success: true, postId: result.insertedId },
      { status: 201 }
    );
  } catch (error) {
    // 6. معالجة الخطأ
    return NextResponse.json(
      { error: 'فشل في إنشاء المشاركة' },
      { status: 500 }
    );
  }
}

ثم في المكون، ستقوم باستدعاء هذا المسار باستخدام

جاري تحميل التقييمات...