العربية
  • nextjs
  • app-router
  • server-actions
  • edge

تنفيذ جلسة بدون حالة لـ Next.js باستخدام Server Actions

استخدام خاصية Next.js الجديدة Server Actions لتنفيذ جلسة بدون حالة قائمة على ملفات تعريف الارتباط، وتجربة فوائد Server Actions.

Sijie
Sijie
Developer

المقدمة

بعد الإصدار الذي حاز على الكثير من الاحتفاء لـ App Router، قدمت Next.js ميزة أخرى، Server Actions. هذه الابتكار الجديد يسهل التلاعب بالبيانات على الجانب الخادم، يقلل من الاعتماد على JavaScript على الجانب العميل، ويعزز بشكل تدريجي النماذج - وذلك كله باستخدام JavaScript وReact لإنشاء تطبيقات ويب قوية دون الحاجة إلى واجهات برمجة التطبيقات التقليدية REST.

في هذه المقالة، نستفيد من الثروة من المزايا التي يقدمها هذا الابتكار ونرى ذلك في العمل عندما نقوم بتنفيذ جلسة بدون حالة قائمة على ملفات تعريف الارتباط لـ Next.js. هذا المقال يقدم كدليل خطوة بخطوة سيقودك خلال كل مرحلة من مراحل إنشاء مشروع تجريبي باستخدام App Router.

يمكن نشر عرضنا العملي على Vercel باستخدام Edge Runtime. ويمكنك تحميل الكود المصدري الكامل من GitHub.

الابتعاد عن واجهات REST APIs

تقليديًا، إذا أردنا إنشاء تطبيق ويب Next.js يستعلم عن قاعدة البيانات في الخلفية، قد ننشئ بعض واجهات REST APIs للتحقق من حالة المصادقة واستعلام قاعدة البيانات، ثم يستدعي تطبيق React على الواجهة الأمامية هذه الواجهات. ولكن إذا لم يكن هناك حاجة لفتح واجهة API للجمهور وكان هذا التطبيق React هو العميل الوحيد، يبدو من الغير ضروري استخدام واجهات REST APIs لأنها سيتم استدعاؤها فقط من قبلنا.

مع Server Actions، يمكن لمكون React الآن تشغيل كود على جانب الخادم. بدلاً من الحاجة إلى إنشاء نقطة نهاية API يدويًا، تقوم Server Actions بإنشاء نقطة نهاية تلقائيًا لـ Next.js لاستخدامها وراء الكواليس. عند استدعاء Server Action، يرسل Next.js طلب POST إلى الصفحة التي تتواجد عليها مع معلومات التعريف لأي إجراء يتم تشغيله.

الحاجة إلى جلسة بدون حالة

باعتباره إطار عمل مفضل لإنشاء تطبيقات بدون حالة، غالبًا ما يعني Next.js أن التطبيقات تكون خوادم غير موجودة، حيث لا يمكننا استخدام الذاكرة لتخزين بيانات الجلسة. تتطلب الجلسات التقليدية استخدام خدمة تخزين خارجية، مثل Redis أو قاعدة بيانات.

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

لذلك، هدفنا هو جلسة بدون حالة خفيفة الوزن وفعالة تستفيد من قدرة التخزين على الجانب العميل بينما تضمن الأمان من خلال تشفير منفذ بشكل جيد.

تنفيذ الجلسة الأساسية

أولاً، نحتاج إلى بدء مشروع جديد:

للحصول على مزيد من التفاصيل حول التثبيت، يرجى الرجوع إلى الدليل الرسمي.

إنشاء مكتبة الجلسة

لجعل فهم Server Actions أسهل، سنقوم بإنشاء نسخة مبسطة من الجلسة أولاً. في هذه النسخة، سنستخدم JSON لتخزين بيانات الجلسة في ملفات تعريف الارتباط.

قم بإنشاء ملف يسمى session/index.ts وقم بتضمين الكود التالي:

السطر الأول "use server" يحدد دوال هذا الملف كـ Server Actions.

نظرًا لأننا لا يمكننا الوصول مباشرة إلى request وresponse، نستخدم next/headers لقراءة وكتابة ملفات تعريف الارتباط. هذا متاح فقط في Server Actions.

القادم: دوال Server Actions إضافية

مع مكتبة الجلسة في مكانها، حان الوقت لتنفيذ ميزة تسجيل الدخول وتسجيل الخروج لإظهار فائدة الجلسة.

أضف الكود التالي إلى user/index.ts:

هنا، نحن نستخدم عملية تسجيل دخول 'مفترضة' التي لا تتطلب سوى اسم مستخدم.

بناء الصفحة

في App Router، تكون الصفحة عادة مكون غير متزامن، ولا يمكن استدعاء Server Actions مباشرة من مثل هذا المكون. نحتاج إلى إنشاء مكونات باستخدام "use client":

components/sign-in.tsx

components/sign-out.tsx

أخيرًا، لنقم ببناء app/page.tsx

تنفيذ التشفير

تم عمل Server Actions. الآن، الجزء الأخير يتضمن تنفيذ التشفير الذي يمكن تحقيقه من خلال crypto.

بعد ذلك، قم بتعديل مكتبة الجلسة لتنفيذ ما يلي:

الخاتمة

تهانينا! لقد نجحت في تنفيذ جلسة بدون حالة لـ Next.js. هنا معاينة على الإنترنت preview على Vercel، ويمكنك تحميل الكود المصدري الكامل هنا. نأمل أن يكون هذا الدليل قد ساعدك في فهم Server Actions الجديدة.

بعد ذلك، سنستكشف كيفية استخدام Server Actions لدمج Logto لـ Next.js. تابعونا!