في المقال اللي فات قعدنا نكتب كونفيج Nginx بإيدينا: reverse proxy، وشهادة SSL، وتوجيه الطلبات يدوي. كل ده كان مهم تفهمه، بس مش لازم تعمله بإيدك في كل مشروع. فيه طريقة تانية للنشر بتاخد كل الشغل ده وتعمله نيابة عنك تلقائيًا، ومجانية كمان لحد حجم معين. في المقال ده هنشرح الفرق بين الطريقتين، وننشر مشروع الميرن ستاك بتاعنا فعليًا بلينك حقيقي يشتغل على الإنترنت.
المحتويات
- أولاً: VPS ولا PaaS؟ الفرق الجوهري
- ثانياً: ليه Vercel وRailway بالذات للمبتدئين
- ثالثاً: نشر الفرونت إند على Vercel
- رابعاً: نشر الباك إند على Railway
- خامساً: متغيرات البيئة على المنصتين
- سادساً: تحديث عنوان الـ API والـ CORS
- سابعاً: تأكد إن كل حاجة شغالة فعليًا
- ثامناً: أخطاء شائعة هتقابلك
- تاسعاً: خطوة قبل الـ CI/CD
أولاً: VPS ولا PaaS؟ الفرق الجوهري
VPS (Virtual Private Server) هو سيرفر افتراضي بتستأجره فاضي تمامًا، وإنت المسؤول عن كل حاجة فيه: تثبيت Docker، ضبط Nginx، تجديد شهادة الـ SSL، حتى تحديثات الأمان بتاعة نظام التشغيل نفسه. ده بالظبط اللي اتكلمنا عنه في المقال اللي فات. الميزة إنك متحكم في كل حاجة، والعيب إنك مسؤول عن كل حاجة.
PaaS (Platform as a Service) زي Vercel وRailway بتاخد منك مسؤولية الجزء ده بالكامل. بتديلهم الكود بس، وهم بيتولوا الباقي: بناء المشروع، تشغيله، الـ reverse proxy، شهادة الـ SSL (بتتظبط تلقائيًا من غير ما تكتب سطر Certbot واحد)، وحتى التوسع البسيط لو الزيارات زادت. الفرق شبه الفرق بين إنك تشتري شقة فاضية وتفرشها بنفسك، أو تسكن في فندق كل حاجة فيه جاهزة.
مفيش طريقة “صح” مطلقة، كل واحدة ليها موقعها. مشاريعك التعليمية والصغيرة ومشاريع الـ MVP اللي بتحاول تثبت فكرة بسرعة، الـ PaaS أنسب بكتير، عشان تركز وقتك في الكود مش في إدارة السيرفرات. المشاريع اللي كبرت واحتاجت تحكم دقيق أو تكلفة أقل على نطاق واسع، هنا الـ VPS بيرجع يكسب. المعرفة اللي أخدناها في مقال Nginx مش هتضيع، هي اللي هتفهمك إيه اللي بيحصل فعليًا ورا الكواليس لما تستخدم PaaS.
ثانياً: ليه Vercel وRailway بالذات للمبتدئين
Vercel متخصص في تطبيقات الفرونت إند (زي React)، وعنده باقة مجانية سخية بما فيه الكفاية لأي مشروع شخصي أو تعليمي. Railway متخصص في تشغيل الباك إند (زي Node.js)، وبيديك رصيد شهري مجاني كافي لمشروع صغير شغال باستمرار.
السبب اللي بيخليهم مناسبين للمبتدئين تحديدًا: الاتنين بيتربطوا مباشرة بحساب GitHub بتاعك، وبمجرد ما تعمل push لمشروعك، بيبدأوا ينشروه تلقائيًا من غير ما تكتب أمر واحد. لو عندك حساب GitHub منظم زي ما اتكلمنا في مقال استخدام GitHub، فأنت فعليًا جاهز تنشر من دلوقتي.
بس خد بالك من نقطة مهمة في الباقة المجانية بتاعة Railway تحديدًا: بتديك رصيد شهري محدود (بالدولار)، مش وقت تشغيل غير محدود. مشروع صغير شغال باستمرار غالبًا هياخد جزء بسيط من الرصيد ده، بس لو مشروعك كبر أو زادت زياراته، هتحتاج تتابع الاستهلاك من لوحة التحكم قبل ما ينتهي الرصيد فجأة ويوقف السيرفر. Vercel من ناحيتها كريمة أكتر مع مواقع الفرونت إند الثابتة زي بتاعتنا، ونادرًا هتحتاج تقلق منها في مشروع تعليمي.
ثالثاً: نشر الفرونت إند على Vercel
ادخل على Vercel وسجل بحساب GitHub بتاعك مباشرة. من لوحة التحكم، دوس Add New Project، واختار مستودع مشروع الـ React اللي بنيناه في مقال React. Vercel هيكتشف تلقائيًا إنه مشروع React ويقترح أوامر البناء المناسبة، مش هتحتاج تغير حاجة في الغالب.
- Build Command: npm run build (نفس الأمر اللي استخدمناه جوه Dockerfile في مقال Docker).
- Output Directory: build.
- دوس Deploy وخلاص، هتاخد رابط شغال فورًا زي your-project.vercel.app.
أي مرة بعد كده تعمل push لفرع main، Vercel هيعيد البناء والنشر تلقائيًا من غير أي تدخل منك.
لو عندك دومين حقيقي (زي yourproject.com) وعايز تستخدمه بدل رابط vercel.app الفرعي، من تبويب Domains جوه إعدادات المشروع، ضيف الدومين واتبع التعليمات لتحديث سجلات الـ DNS عند الجهة اللي شريت منها الدومين. Vercel بيتولى شهادة الـ SSL للدومين الجديد تلقائيًا كمان، بنفس الفكرة اللي عملناها يدويًا بـ Certbot في مقال Nginx، بس هنا من غير أي أمر تكتبه.
رابعاً: نشر الباك إند على Railway
نفس الفكرة، ادخل على Railway وسجل بـ GitHub. اختار New Project ثم Deploy from GitHub repo، واختار مستودع الباك إند اللي بنيناه في مقال Node.js وExpress.js. أجمل حاجة في Railway إنه بيقرا نفس الـ Dockerfile اللي كتبناه للباك إند في مقال Docker ويستخدمه مباشرة، فمفيش شغل إضافي هنا خالص، الوصفة اللي كتبناها قبل كده بتشتغل زي ما هي.
Railway هيديك رابط عام زي your-api.up.railway.app، ده اللي هيبقى عنوان الـ API بتاعك دلوقتي بدل localhost:3000.
خامساً: متغيرات البيئة على المنصتين
ملف .env اللي كان على جهازك مش بيترفع مع الكود (فاكر .gitignore اللي اتكلمنا عنه في مقال GitHub؟)، فلازم تضيف نفس المتغيرات يدويًا في كل منصة.
في Railway، من تبويب Variables بتاع مشروعك، ضيف نفس المتغيرات اللي جهزناها في مقال MongoDB Atlas ومقال JWT: MONGODB_URI وJWT_SECRET. في Vercel، من إعدادات المشروع تبويب Environment Variables، ضيف متغير باسم REACT_APP_API_URL بالظبط (الاسم ده مش اختياري، مشاريع Create React App بتتجاهل أي متغير مش بادئ بـ REACT_APP_) وقيمته عنوان الـ API الجديد بتاع Railway.
سادساً: تحديث عنوان الـ API والـ CORS
فاكر API_URL الثابت اللي كتبناه في مقال React؟ دلوقتي لازم يتغير لعنوان Railway الحقيقي بدل localhost.
const API_URL = process.env.REACT_APP_API_URL || "http://localhost:3000";وفي الباك إند، لازم تحدد الـ CORS اللي اتكلمنا عنه في مقال React عشان يسمح بس لعنوان Vercel الجديد، مش لأي عنوان زي ما كان وقت التطوير.
app.use(cors({
origin: "https://your-project.vercel.app"
}));سابعاً: تأكد إن كل حاجة شغالة فعليًا
الرابط شغال مش معناه إن كل حاجة سليمة، محتاج تتأكد بنفسك بالخطوات دي بالترتيب.
- افتح رابط Vercel وتأكد إن الصفحة بتعرض بيانات حقيقية جاية من MongoDB، مش شاشة فاضية أو رسالة تحميل عالقة.
- جرب تعمل حساب جديد من الواجهة، وروح لوحة تحكم MongoDB Atlas وشوف لو المستخدم اتسجل فعليًا في قاعدة البيانات.
- سجل دخول وجرب عملية حذف أو تعديل، ده بيتأكد إن هيدر Authorization فعليًا بيوصل من الفرونت إند للباك إند سليم.
- افتح أدوات المطور في المتصفح (F12) وشوف تبويب Network، لو فيه أي طلب لونه أحمر أو رسالة CORS، ارجع لقسم سادساً وراجع الإعدادات.
حاجة أخيرة محتاج تعرفها قبل ما تحكم على السرعة: خدمات الباقة المجانية غالبًا بتخلي السيرفر “ينام” لو محدش استخدمه لفترة، وأول طلب بعد فترة الخمول ده بياخد وقت أطول بشكل ملحوظ (ثواني بدل ميلي ثانية) لحد ما السيرفر يصحى تاني. الظاهرة دي اسمها Cold Start، ومش عيب في الكود بتاعك ولا في الإعدادات، هي سلوك طبيعي ومتوقع في أغلب الباقات المجانية. لو حسيت إن أول زيارة للموقع بطيئة بشكل غريب بعد ما تسيبه فترة من غير استخدام، ده السبب غالبًا، والزيارات اللي بعدها هترجع لسرعتها الطبيعية.
ثامناً: أخطاء شائعة هتقابلك
- نسيان تحديث API_URL في الفرونت إند، فالواجهة تفضل بتحاول تكلم localhost حتى بعد النشر.
- ترك الـ CORS مفتوح لأي عنوان في الإنتاج، وده نفس نصيحة الحماية اللي اتكررت في أكتر من مقال في السلسلة.
- نسيان إضافة متغيرات البيئة في لوحة تحكم المنصة، فالباك إند بيقع فورًا لأنه مش لاقي MONGODB_URI.
- عدم إضافة عنوان IP منصة النشر في إعدادات Network Access بتاعة MongoDB Atlas، فقاعدة البيانات بترفض الاتصال من سيرفر Railway.
تاسعاً: خطوة قبل الـ CI/CD
دلوقتي مشروعك شغال فعليًا على الإنترنت، أي حد في العالم يقدر يفتحه. لاحظ حاجة مهمة: كل مرة تعمل فيها push لـ GitHub، المنصتين بينشروا النسخة الجديدة تلقائيًا من غير ما تطلب منهم، ده فعليًا شكل بسيط جدًا من الـ CI/CD اللي هنتعمق فيه في المقال الجاي، ونتعلم إزاي نضيف خطوات زي تشغيل الاختبارات تلقائيًا قبل ما أي نشر يحصل.
لو وصلت للنقطة دي، يبقى عندك مشروع ميرن ستاك كامل: مبني، محمي، معزول في حاويات، ومنشور فعليًا بلينك حقيقي. لو عندك سؤال عن أي خطوة، قولّي في التعليقات.
اكتشاف المزيد من كود التطور
اشترك للحصول على أحدث التدوينات المرسلة إلى بريدك الإلكتروني.
