يا هلا بيك يا باشمهندس في عالم تطوير الـ Web Development الواسع! لو انت شغال بـ Frontend Framework زي Nuxt 3، اكيد في مرة حسيت بوجع دماغ إنك محتاج تعمل Backend صغير، تفتح سيرفر Node.js منفصل، وتظبط الـ CORS، وتقعد تلف حوالين نفسك عشان تربط الفرونت إند بالباك إند.
زمان، كان الموضوع معقد، بس مع إطلاق Nuxt 3، الدنيا اتغيرت 180 درجة. دلوقتي بقى متاح ليك تعمل Full-Stack Application جوه نفس المشروع وبأقل مجهود ممكن من خلال حاجة اسمها Server Routes. في المقال ده، هناخد رحلة تفصيلية نعرف إزاي نبني APIs حقيقية ونربطها بقاعدة بيانات جوه مشروع نكست 3 من غير ما نحتاج سيرفر خارجي.
Table of contents [Show]
- 1 إيه هي الـ Server Routes في Nuxt 3 وليه بنحتاجها؟ (What are Nuxt 3 Server Routes)
- 2 هيكل مجلد السيرفر وتنظيم الـ APIs (Server Directory Structure)
- 3 توصيل الـ Server Routes بقاعدة البيانات (Connecting Nuxt 3 Server to Database)
- 4 استدعاء الـ APIs داخل صفحات الفرونت إند (Fetching Data in Frontend)
- 5 نصيحة من أخ: إمتى تستخدم Server Routes وإمتى تعمل Backend منفصل؟
إيه هي الـ Server Routes في Nuxt 3 وليه بنحتاجها؟ (What are Nuxt 3 Server Routes)
ببساطة شديدة، الـ Server Routes هي ميزة أساسية في Nuxt 3 بتخليك تكتب كود باكد إند (Backend Code) جوه مجلد اسمه server. النكست بيقرا المجلد ده تلقائياً وبيحوله لـ API Endpoints شغالة وجاهزة تستقبل طلبات زي GET, POST, PUT, DELETE.
الجميل في الموضوع إنك بتكتب كود السيرفر بنفس لغة الجافاسكريبت أو التايب سكريبت (TypeScript) اللي بتحبها، وتقدر تتعامل مع قاعدة البيانات (Database Connection) مباشرة من غير ما توجع دماغك بإعدادات سيرفر معقدة زي Express.js أو Fastify في مشروع لوحده، ده بيوفر وقت كبير جداً ويسهل عليك إدارة المشروع خصوصاً لو مشروعك متوسط أو صغير (MVP).
هيكل مجلد السيرفر وتنظيم الـ APIs (Server Directory Structure)
عشان تبدأ تشتغل صح، لازم تفهم إزاي نكست بيقسم مجلد السيرفر. لما تفتح مشروع Nuxt 3 جديد، هتلاقي مجلد اسمه server/ جواه مجلدين رئيسيين:
- مجلد
api/: وده مخصص للـ API Endpoints بتاعتك، وأي ملف تحطه هنا هيكون الرابط بتاعه بيبدأ بـ/api/تلقائياً. - مجلد
routes/: وده لو عايز تعمل مسارات تانية للسيرفر مش شرط تبدأ بكلمة api، زي صفحات بتعمل رندر لملفات معينة أو ويب هوكس (Webhooks).
تعال نعمل أول API حقيقي لينا. هتروح جوه مجلد server/api/ وتعمل ملف اسمه users.ts، وتكتب فيه الكود ده:
export default defineEventHandler(async (event) => {
// دي بيانات وهمية مؤقتة لحد ما نربط الداتابيز
const users = [
{ id: 1, name: 'أحمد محمد', role: 'Frontend Developer' },
{ id: 2, name: 'محمود علي', role: 'Backend Developer' }
]
return {
success: true,
message: 'تم جلب البيانات بنجاح',
data: users
}
})
بالظبط كده! بالخطوة البسيطة دي، بقى عندك API شغال على الرابط http://localhost:3000/api/users وتقدر تناديه من أي صفحة في الفرونت إند بكل سهولة باستخدام useFetch.
توصيل الـ Server Routes بقاعدة البيانات (Connecting Nuxt 3 Server to Database)
الخطوة الأهم والأمتع هي إزاي نخلي الـ Server Routes دي تكلم قاعدة بيانات حقيقية، وليكن مثلاً MongoDB أو PostgreSQL. عشان نعمل كده بطريقة نضيفة، بنستخدم ORM زي Prisma أو مكتبة زي Mongoose.
تعال نفترض إننا شغالين بـ Prisma ومظبطين اتصال الداتابيز. هنروح لنفس ملف الAPI ونكتب كود بيجيب المستخدمين من الداتابيز وبيحفظ مستخدم جديد:
import { PrismaClient } from '@prisma/client'
const prisma = new PrismaClient()
export default defineEventHandler(async (event) => {
const method = getMethod(event)
// لو الطلب GET يبقى بنجيب كل المستخدمين
if (method === 'GET') {
const users = await prisma.user.findMany()
return { success: true, data: users }
}
// لو الطلب POST يبقى بنضيف مستخدم جديد
if (method === 'POST') {
const body = await readBody(event)
const newUser = await prisma.user.create({
data: {
name: body.name,
email: body.email
}
})
return {
success: true,
message: 'تم إضافة المستخدم بنجاح',
data: newUser
}
}
})
المميز هنا إن Nuxt بتوفرلك دوال مساعدة جاهزة زي getMethod(event) عشان تعرف نوع الطلب، و readBody(event) عشان تقرأ البيانات اللي باعتها الفرونت إند في الـ Request Body بكل سهولة وبدون تعقيد.
استدعاء الـ APIs داخل صفحات الفرونت إند (Fetching Data in Frontend)
دلوقتى بعد ما عملنا الـ Backend جوه الـ Server Routes، إزاي نستخدم البيانات دي في صفحات النكست؟ الموضوع أبسط ما يمكن باستخدام Composable الشهير useFetch:
<script setup>
// استدعاء الـ API اللي عملناه
const { data: users, pending, error } = await useFetch('/api/users')
</script>
<template>
<div>
<h1>قائمة المستخدمين</h1>
<div v-if="pending">جاري التحميل...</div>
<ul v-else>
<li v-for="user in users.data" :key="user.id">
{{ user.name }} - {{ user.email }}
</li>
</ul>
</div>
</template>
الكود ده بيشتغل Server-Side Rendering (SSR)، معناه إن البيانات بتتحمل من السيرفر وتيجي جاهزة مع الصفحة، وده بيخلي الأداء خارق والـ SEO بتاع موقعك في السما!
نصيحة من أخ: إمتى تستخدم Server Routes وإمتى تعمل Backend منفصل؟
عشان تكون مبرمج ذكي وفاهم الهندسة المعمارية (Software Architecture)، لازم تعرف إن الـ Server Routes في Nuxt 3 ممتازة جداً للمشاريع المتوسطة، تطبيقات الـ SaaS، والمواقع الإخبارية أو المتاجر اللي عايز تخلصها بسرعة وبأقل تكلفة سيرفرات.
لكن، لو مشروعك ضخم جداً وفيه عمالة ومبرمجين كتير شغالين في أقسام منفصلة (Microservices)، أو عندك عمليات معالجة خلفية ثقيلة (Heavy Background Jobs)، ساعتها بيكون الأفضل تفصل الـ Backend في سيرفر مستقل بـ Node.js أو NestJS أو Laravel. لكن غير كده، Nuxt 3 هتفرملك الشغل وتوفر عليك وقت ومجهود رهيب.
اتمرن كويس على النقطة دي، وابدأ اعمل مشروعك الجاي بـ Full-Stack Nuxt 3 وهتحس بفرق كبير جداً في السرعة والإنتاجية. بالتوفيق يا باشمهندس!