العودة إلى المدونة

استضافة باك إند تطبيق موبايل: كيف تجهّز سيرفر الـ API صح من البداية

فريق تحرير IM Host10 أكتوبر 20267 دقائق قراءة
استضافة باك إند تطبيق موبايل: كيف تجهّز سيرفر الـ API صح من البداية

أي تطبيق موبايل جاد يحتاج باك إند فيه خمسة أجزاء: سيرفر API يتكلم معه التطبيق، وقاعدة بيانات، ومكان لتخزين الملفات، وعمليات خلفية (workers) للإشعارات والمهام البطيئة، ونظام تسجيل دخول. في الشهور الأولى تكفي كل هذه الأجزاء على سيرفر VPS واحد بموارد مخصصة، بشرط أن تكون النسخ الاحتياطية خارج السيرفر نفسه، وأن تعرف مسبقًا أي جزء ستفصله أولًا عندما يكبر التطبيق. في هذا المقال نشرح ماذا تشغّل، وكيف تحدد حجم السيرفر، وأين تضعه لمستخدمين في مصر، وكيف تتوسع بدون إعادة كتابة.

ما الذي يفعله الباك إند بالضبط؟

التطبيق على الهاتف مجرد واجهة. كل ما يجب أن يكون مشتركًا بين المستخدمين أو موثوقًا أو محفوظًا بعد حذف التطبيق مكانه السيرفر:

  • سيرفر الـ API: الخدمة التي يرسل لها التطبيق الطلبات، مكتوبة بـ Node.js أو Django أو Laravel أو Go. تتحقق من البيانات وتطبق منطق العمل وترجع JSON.

  • قاعدة البيانات: غالبًا PostgreSQL أو MySQL للمستخدمين والطلبات، ومعها Redis للجلسات والكاش وعدّادات تحديد المعدل.

  • تخزين الملفات: صور الحسابات والفواتير والرسائل الصوتية. احفظ الملف على القرص أو في تخزين متوافق مع S3، واحفظ المسار فقط في قاعدة البيانات.

  • الطوابير والـ workers: إرسال الإشعارات عبر Firebase Cloud Messaging أو خدمة Apple، وتصغير الصور، وإرسال الإيميل والـ SMS. كل هذا يجري خارج الطلب حتى لا ينتظره المستخدم.

  • المصادقة: تسجيل الدخول، وتوكن قصير العمر، وrefresh token، واستعادة كلمة المرور، وكود OTP لو احتجته.

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

منصة BaaS جاهزة أم سيرفر خاص بك؟

منصات Backend-as-a-Service تعطيك قاعدة بيانات وتسجيل دخول وتخزين عبر SDK جاهز، وهي مناسبة لنموذج أولي. لكن الفروق تظهر مع الوقت:

  • سرعة البداية: الـ BaaS أسرع بلا نقاش؛ تسجيل الدخول وقاعدة البيانات جاهزان في يوم.

  • التكلفة مع النمو: التسعير غالبًا مرتبط بعدد القراءات والكتابات أو المستخدمين النشطين، فالفاتورة تكبر مع نجاحك ويصعب توقعها. السيرفر سعره الشهري ثابت.

  • التحكم: على سيرفرك تختار محرك قاعدة البيانات وتكتب أي استعلام وتثبّت أي مكتبة.

  • مكان البيانات: أنت تختار الدولة، وهذا مهم للبيانات الحساسة ولسرعة الاستجابة.

  • صعوبة الخروج: ترك منصة BaaS يعني غالبًا تعديل كود التطبيق نفسه، والإصدارات القديمة تبقى على هواتف المستخدمين شهورًا.

القاعدة العملية: لو التطبيق تجربة لفكرة، BaaS كافية. لو وراءه نشاط تجاري أو مستخدمون يدفعون، اجعل التطبيق يتكلم مع API تملكه من أول يوم، وبعدها غيّر ما تشاء خلفه بدون إصدار نسخة جديدة من التطبيق.

البنية المبدئية على سيرفر واحد

سيرفر واحد يكفي لتشغيل كل شيء بشكل مرتب إذا كان لكل جزء حدود واضحة:

  1. Nginx على المنفذين 80 و443، يتولى شهادة SSL ويمرر الطلبات إلى الـ API على منفذ داخلي.

  2. الـ API يعمل كخدمة systemd أو تحت PM2 أو داخل حاوية، ويستمع على 127.0.0.1 فقط.

  3. PostgreSQL وRedis على localhost فقط. لا تفتح المنفذ 5432 أو 6379 للإنترنت أبدًا.

  4. عملية worker تقرأ المهام من Redis وتتصل بخدمات الإشعارات والإيميل والـ SMS.

  5. الملفات المرفوعة في مجلد مستقل خارج مجلد الكود، أو في تخزين كائنات.

لو تكتب بـ Node.js، راجع شرح تشغيل Node.js على VPS باستخدام PM2 وNginx. ولو تفضّل الحاويات، فـقائمة تجهيز Docker Compose للإنتاج تغطي سياسات إعادة التشغيل والـ volumes وتدوير السجلات، وهي التفاصيل التي تنكسر أولًا.

هناك نقطة خاصة بشبكات الموبايل في مصر: كثير من المستخدمين يصلون إليك من خلال CGNAT عند شركة الاتصالات، أي أن مئات الهواتف قد تظهر بعنوان IP واحد. لذلك اجعل حدود المعدل لكل IP واسعة، وضع الحدود الصارمة على مسارات حساسة مثل تسجيل الدخول وإرسال الـ OTP:

limit_req_zone $binary_remote_addr zone=auth:10m rate=5r/s;

server {
    server_name api.example.com;
    location /auth/ {
        limit_req zone=auth burst=20 nodelay;
        proxy_pass http://127.0.0.1:3000;
    }
    location / {
        proxy_pass http://127.0.0.1:3000;
    }
}

استبدل api.example.com بالنطاق الفرعي الخاص بك. وأضف داخل الـ API حدودًا لكل حساب، فهي أعدل مع المستخدمين الذين يتشاركون IP واحدًا.

حجم السيرفر: قواعد تقريبية مجرَّبة

  • عند الإطلاق: 4 vCPU و8 GB RAM تكفي عادة لـ API بصيغة JSON مع PostgreSQL وRedis وworker في الشهور الأولى. أغلب الـ APIs يحدّها أداء الاستعلامات لا المعالج.

  • توزيع الذاكرة: أعطِ PostgreSQL حوالي 25% من الرام في shared_buffers، واترك مساحة لعمليات الـ API، وأبقِ 20% على الأقل حرة لكاش نظام التشغيل.

  • هامش الأمان: إذا بقي المعالج فوق 70% وقت الذروة أو استمر زمن الاستجابة p95 في الارتفاع، كبّر السيرفر قبل الحملة الإعلانية لا أثناءها.

  • التخزين: أقراص NVMe تفرق مع قاعدة البيانات أكثر من أي شيء آخر. احسب مساحة القاعدة وسجلاتها ونسختين محليتين على الأقل.

  • معالج مخصص: API يرد في 40 ملي ثانية والسيرفر هادئ ثم في 400 عندما ينشغل الجيران مشكلة يصعب تتبعها. الأنوية المخصصة تلغي هذا الاحتمال.

باقات Cloud VPS من IM HOST بمعالج ورام وNVMe مخصصة متاحة بسعات 8 و16 و32 و64 GB RAM، ويمكنك الانتقال بين الباقات مع نمو التطبيق.

متى تفصل قاعدة البيانات على سيرفر مستقل؟

لا تستعجل. سيرفران يعنيان شبكة داخلية وتحديثات مضاعفة ومراقبة في مكانين. افصلها عندما ترى إحدى هذه العلامات:

  • القاعدة والـ API يتنافسان على الرام وتنخفض نسبة الكاش في القاعدة.

  • التقارير والتصديرات الثقيلة تبطئ الـ API الحي.

  • تحتاج أكثر من سيرفر API، وهذا يتطلب قاعدة مشتركة في كل الأحوال.

  • تريد استرجاع القاعدة بدون المساس بسيرفر التطبيق.

مكان السيرفر وسرعة الاستجابة للمستخدم المصري

التطبيق يرسل طلبات صغيرة كثيرة، وكل طلب على شبكة الموبايل يحمل تأخيرًا من الشبكة نفسها قبل أن يصل للسيرفر. لو الشاشة الواحدة تحتاج خمسة طلبات، فبُعد السيرفر يتضاعف أثره. ثلاث قواعد:

  • ضع السيرفر قريبًا من أغلب مستخدميك؛ للجمهور المصري يعني ذلك القاهرة أو موقعًا أوروبيًا قريبًا. لدى IM HOST مراكز بيانات في القاهرة ولندن وبرلين ووارسو ونيويورك، والخدمات متاحة عبر مواقعنا حسب التوفر، ونؤكد معك الموقع قبل التفعيل.

  • قلّل عدد الطلبات: صمّم endpoints تعطي الشاشة كل ما تحتاجه في طلب واحد، وفعّل keep-alive والضغط.

  • اختبر من هاتف على 4G وليس من إنترنت المكتب، وقارن الأزمنة مع سجلات الـ API.

لقياس زمن الاستجابة من أي جهاز:

curl -s -o /dev/null -w "connect: %{time_connect}  ttfb: %{time_starttransfer}  total: %{time_total}\n" https://api.example.com/health

النسخ الاحتياطي والمراقبة

نسخ السيرفر الكاملة تحميك من فقدان الجهاز، لكنها لا تكفي لاسترجاع قاعدة بيانات نشطة إلى لحظة محددة. خذ نسخًا من القاعدة بنفسك وانقلها خارج السيرفر. مهمة ليلية بسيطة تضيفها بالأمر sudo crontab -u postgres -e:

0 3 * * * pg_dump -Fc appdb > /var/lib/postgresql/backups/appdb-$(date +\%F).dump

أنشئ مجلد backups أولًا، ثم انسخ الملفات إلى تخزين في مكان آخر واحذف ما تجاوز مدة الاحتفاظ. جرّب الاسترجاع بـ pg_restore على قاعدة تجريبية مرة شهريًا على الأقل؛ النسخة التي لم تُجرَّب مجرد افتراض.

للمراقبة ابدأ بثلاثة أشياء: فحص خارجي على مسار /health يستعلم من القاعدة أيضًا، وتنبيه عند امتلاء القرص فوق 80%، ومتابعة معدل الأخطاء في سجلات الـ API. وتقارير الأعطال من التطبيق نفسه كثيرًا ما تكشف أخطاء السيرفر قبل السجلات.

طريق التوسع خطوة بخطوة

  1. التوسع الرأسي: باقة أكبر. أرخص وقت هندسي ستشتريه.

  2. فصل القاعدة: سيرفر للـ API والـ workers وآخر لـ PostgreSQL.

  3. أكثر من سيرفر API: سيرفرات بلا حالة خلف موزع أحمال، مع إخراج الجلسات والملفات من القرص المحلي.

  4. سيرفر مخصص: لقاعدة بيانات كبيرة ومستقرة تحتاج أداء قرص ومعالج ثابتًا.

لو محتار بين أنواع السيرفرات في كل مرحلة، اقرأ الفرق بين Cloud VPS والـ VPS العادي. ولو التطبيق جزء من منتج اشتراكات، فـدليل البنية التحتية لشركات SaaS الناشئة يشرح بيئة الاختبار وعزل بيانات العملاء وتجارب الاسترجاع.

أخطاء مكلفة

  • وضع مفاتيح API أو بيانات القاعدة داخل التطبيق. أي شيء داخل ملف التطبيق يمكن استخراجه؛ الأسرار مكانها السيرفر.

  • كتابة IP السيرفر داخل التطبيق بدل اسم مثل api.example.com، فتفقد القدرة على النقل بتعديل DNS.

  • عدم ترقيم إصدارات الـ API. ابدأ بـ /v1/ من أول يوم.

  • إرسال الإشعارات داخل الطلب بدل الـ worker.

  • الاحتفاظ بالنسخ الاحتياطية على السيرفر نفسه فقط.

أسئلة شائعة

هل يمكن رفع باك إند التطبيق على استضافة مشتركة؟

لـ API بسيط بلغة PHP وزيارات قليلة قد ينفع، لكن أغلب تطبيقات الموبايل تحتاج workers تعمل باستمرار وRedis وأحيانًا WebSockets، وهذا يتطلب صلاحيات root على VPS.

كم رام يحتاج سيرفر تطبيق الموبايل؟

كقاعدة تقريبية، 8 GB RAM تكفي للـ API وPostgreSQL وRedis وworker عند الإطلاق. راقب الذاكرة وقت الذروة وكبّر عندما تبقى المساحة الحرة أقل من 20%.

هل أضع الـ API وقاعدة البيانات على نفس السيرفر؟

في البداية نعم، مع جعل القاعدة تستمع على localhost فقط. افصلهما عندما يتنافسان على الموارد أو تحتاج أكثر من سيرفر API.

أين أستضيف API لمستخدمين في مصر؟

أقرب ما يمكن إليهم. القاهرة تقلل المسافة على الشبكة، والمواقع الأوروبية القريبة بديل معقول. واختبر دائمًا من هاتف على شبكة موبايل.

إذا قررت تشغيل الـ API بنفسك، ابدأ بـسيرفر Cloud VPS بموارد مخصصة ونسخ احتياطي تلقائي وانتقل بين الباقات مع نمو مستخدميك. ومهندسو الدعم متاحون 24/7 لو أردت رأيًا ثانيًا في الإعداد.

المزيد من مدونتنا

اكتشف المزيد من الأدلة العملية ورؤى الخدمات من فريق IM Host.

عرض كل المقالات