لكل تطبيق جوال واجهة خلفية (backend)؛ والسؤال ليس هل ستوجد، بل من سيبنيها. الجواب المختصر: لمنتج أولي (MVP) يطوّره فريق واحد بقواعد عمل قليلة ونموذج بيانات بسيط، تكون خدمة الباك إند الجاهزة (BaaS) مثل Firebase أو Supabase أسرع طريق. أما إذا كان هناك عدة عملاء (تطبيق الجوال مع لوحة ويب مع أطراف خارجية)، وقواعد عمل يجب أن تُنفَّذ على الخادم، وتكاملات مثل ERP أو الفوترة الإلكترونية، وتقارير علائقية، والتزامات بشأن مكان تخزين البيانات، فأنت بحاجة إلى باك إند مخصص. في معظم المشاريع المؤسسية الجواب الصحيح هجين: Firebase للإشعارات الفورية وتقارير الأعطال والتحليلات، وواجهة API خاصة بك للبيانات الأساسية وقواعد العمل. تشرح هذه المقالة كيف نتخذ هذا القرار في مشاريع تطبيقات الجوال.
ماذا تفعل الواجهة الخلفية في تطبيق الجوال؟
التطبيق على الهاتف مجرد واجهة؛ وكل ما هو دائم يعيش على خادم. تتولى الواجهة الخلفية المهام التالية:
- المصادقة والجلسات: من هو المستخدم، ومن أي جهاز دخل، ومتى تنتهي جلسته.
- تخزين البيانات والاستعلام عنها: الطلبات والرسائل والملفات الشخصية، بما في ذلك تعديل مستخدمَين للسجل نفسه في الوقت نفسه.
- قواعد العمل: حساب السعر، خصم المخزون، مسارات الموافقة، فحص الحدود. تنفيذها على العميل ثغرة أمنية.
- الملفات والوسائط: رفع الصور، تغيير الحجم، صلاحيات الوصول.
- الإشعارات والمهام المجدولة: الإشعارات الفورية، البريد، التقارير الليلية.
- التكاملات: مزوّد الدفع، الشحن، المحاسبة، ERP؛ ولا يمكن وضع مفاتيح هذه الاتصالات داخل حزمة التطبيق.
تغطي خدمة الباك إند الجاهزة البنود الأول والثاني والرابع جيدًا جدًا، أما الثالث والسادس فلا تغطيهما إلا بكود إضافي. وعلى هذه الفجوة يُبنى القرار.
ما الذي تقدمه BaaS (Firebase وSupabase) وما الذي لا تقدمه؟
Firebase حزمة خدمات تستضيفها Google: Authentication وFirestore (قاعدة بيانات مستندية) وStorage وCloud Functions وCloud Messaging (الإشعارات الفورية) وCrashlytics وAnalytics. أما Supabase فتبني حزمة مشابهة فوق PostgreSQL وهي مفتوحة المصدر. في كليهما لا تدير خوادم؛ يتصل التطبيق بقاعدة البيانات مباشرة عبر SDK، وتُعرَّف قواعد الوصول على جانب الخدمة. ما تحصل عليه واضح: إصدار أول خلال أيام بدل أسابيع، ولا حاجة لكتابة المصادقة أو المزامنة الفورية، ولا للتفكير في التوسع. أما ما لا تحصل عليه فيظهر لاحقًا في المشروع: لا يوجد في Firestore ربط بين الجداول (join) ولا تقارير جماعية، ويُبنى نموذج البيانات حول الشاشات فيجهده كل شاشة جديدة؛ وقواعد العمل متعددة الخطوات تعني كتابة Cloud Functions على أي حال؛ ونقل البيانات إلى نظام آخر ممكن، لكن الانتقال من بنية مستندية إلى بنية علائقية مشروع قائم بذاته. تحل Supabase المشكلة الأولى بتقديم قاعدة علائقية، لكن سؤال قواعد العمل والتكاملات يبقى نفسه.
الفرق الحاسم: أين تُنفَّذ قواعد العمل؟
في نموذج BaaS يكتب التطبيق في قاعدة البيانات مباشرة. هذه أسرع الميزات وأخطرها. في تطبيق طلبات، إذا كان الهاتف يحسب الإجمالي ويكتبه في Firestore، فإن أي شخص يفتح التطبيق يستطيع تغيير هذا الإجمالي وإرساله؛ تتحقق قواعد الأمان من أنواع الحقول والملكية، لكن قاعدة مثل «يجب أن يساوي الإجمالي مجموع السعر مضروبًا في الكمية لكل البنود» يصعب التعبير عنها بشكل مقروء. الحل نقل عملية الكتابة إلى دالة على الخادم:
// Cloud Function: الإجمالي لا يؤخذ من العميل بل يُحسب على الخادم
import { onCall, HttpsError } from 'firebase-functions/v2/https';
import { getFirestore } from 'firebase-admin/firestore';
export const createOrder = onCall(async (req) => {
if (!req.auth) throw new HttpsError('unauthenticated', 'Sign-in required');
const db = getFirestore();
const items = req.data.items as { productId: string; qty: number }[];
return db.runTransaction(async (tx) => {
let total = 0;
for (const item of items) {
const snap = await tx.get(db.doc('products/' + item.productId));
if (!snap.exists) throw new HttpsError('not-found', 'Unknown product');
const product = snap.data()!;
if (product.stock < item.qty) {
throw new HttpsError('failed-precondition', 'Insufficient stock');
}
total += product.price * item.qty; // السعر من السجل لا من الهاتف
tx.update(snap.ref, { stock: product.stock - item.qty });
}
const ref = db.collection('orders').doc();
tx.set(ref, { userId: req.auth!.uid, items, total, createdAt: new Date() });
return { orderId: ref.id, total };
});
});لحظة كتابتك هذه الدالة تكون قد بدأت كتابة باك إند؛ الاستضافة فقط عند Google. ومع تزايد عدد قواعد العمل تتكاثر الدوال، ويحتاج الكود المشترك بينها وترتيب الاختبارات إلى إطار، فيتحول المشروع إلى باك إند مخصص دون أن يقرر ذلك أحد. لهذا لا يبدأ القرار بسؤال «Firebase أم خادمي الخاص» بل بسؤال «كم من قواعد عملي يجب أن تُنفَّذ على الخادم». شرحنا مبادئ أمان جانب الجوال في مقالة أمان تطبيقات الجوال، وتصميم API في مقالة REST أم GraphQL.
خدمة الباك إند الجاهزة لا تلغي قواعد العمل، بل تغيّر فقط مكان كتابتها. وعندما يتجاوز عدد القواعد التي يجب أن تُنفَّذ على الخادم بضع قواعد، تبدأ السرعة التي منحتها الخدمة في الارتداد.
ما الذي يرفع التكلفة؟
تسعير BaaS بحسب الاستخدام: عمليات القراءة والكتابة والتخزين واستدعاءات الدوال. أما الباك إند المخصص فله تكاليف خادم وصيانة ثابتة. لا نذكر أرقامًا، لأن الفاتورتين تحددهما أمور مختلفة، ومعرفة ذلك أهم من الرقم. تنمو فاتورة BaaS مع نموذج البيانات لا مع عدد المستخدمين: إذا كانت شاشة قائمة تقرأ مئة مستند في كل فتح، فإن عدد القراءات اليومية لكل مستخدم يعتمد على تصميم تلك الشاشة، وهذا أغلى خطأ يمكن إصلاحه بعد الإطلاق. أما تكلفة الباك إند المخصص فتنمو لا مع حجم المعاملات بل مع وقت الفريق الذي يكتبه ويصونه. فصّلنا التكاليف السنوية في مقالة تكلفة صيانة تطبيق الجوال؛ ولميزانية التطوير الأولى انظر مقالة تكلفة تطوير تطبيق الجوال.
هل البيانات ملكك؟ قابلية النقل والموقع
على كل مشروع يستخدم BaaS أن يجيب مسبقًا عن ثلاثة أسئلة. الأول: في أي بلد تُخزَّن البيانات؛ تتيح مشاريع Firebase اختيار المنطقة، لكن نقل البيانات الشخصية إلى الخارج التزام منفصل بموجب قانون حماية البيانات التركي (KVKK) يُغطَّى بسياسة الخصوصية، وبالموافقة الصريحة حيث يلزم (هذه المقالة ليست استشارة قانونية). الثاني: كيف تُصدَّر البيانات؛ شرحنا الانتقال من قاعدة مستندية إلى علائقية في مقالة ترحيل البيانات؛ وهو ممكن، لكن نموذج البيانات المبني حول الشاشات يُعاد تصميمه عند تحويله إلى جداول. الثالث: ماذا يحدث إذا أوقفت الخدمة ميزة ما؛ أُغلقت Firebase Dynamic Links فأعادت التطبيقات المعتمدة عليها بناء بنية الروابط لديها. هذا لا يجعل الخدمة سيئة؛ بل يبيّن أن قرارًا منتجيًا لدى المزوّد قد يصل إلى منتجك. دوّن تكلفة الخروج كتابةً قبل ربط أي مسار حرج بمزوّد واحد.
اختبار القرار: ثلاثة أسئلة
إذا أجبت بـ«نعم» عن سؤالين على الأقل مما يلي، فضع البيانات الأساسية في باك إند مخصص:
- هل سيستخدم بيانات التطبيق عملاء آخرون غير تطبيق الجوال: لوحة إدارة على الويب، بوابة وكلاء، API لطرف خارجي، تكامل مع المحاسبة أو ERP؟
- هل توجد قواعد عمل يجب أن تُنفَّذ على الخادم: حساب الأسعار والخصومات، حجز المخزون، مسارات الموافقة، فحص الحدود، معاملات مرتبة؟
- هل تحتاج إلى تقارير علائقية: الإيراد حسب فترة زمنية، المتوسط لكل مستخدم، تقارير إدارية تجمع عدة جداول؟
سؤال رابع يُطرح في المسارين: هل تستطيع اليوم تصدير البيانات بأمر واحد؟ إن كان الجواب لا، فحلّ هذا أولًا أيًا كان النموذج الذي تختاره. إذا كان عدد إجابات «نعم» أقل من اثنتين، وخاصةً إذا أردت طرح الإصدار الأول في السوق بسرعة وقياس الطلب، فإن BaaS بداية صحيحة؛ شرحنا نطاق MVP في مقالة ما هو MVP. وإذا طُرح اختيار قاعدة البيانات، تفيدك مقالة PostgreSQL أم MySQL.
النموذج الهجين: استخدام الاثنين معًا
عمليًا، الإعداد الأكثر شيوعًا هو: Firebase Cloud Messaging للإشعارات الفورية، وCrashlytics لتقارير الأعطال، وAnalytics لتحليلات الاستخدام؛ وواجهة API خاصة بك للهوية والبيانات الأساسية وقواعد العمل. في هذا النموذج لا يتصل تطبيق الجوال بـ Firestore أبدًا؛ تقدّم Firebase فقط الخدمات المساعدة على جانب الجهاز. شرحنا إعداد الإشعارات في مقالة الإشعارات الفورية، والتصميم الذي يواصل العمل عند انقطاع الاتصال في مقالة التطبيق الذي يعمل دون اتصال. للنموذج الهجين شرط واحد: أن تكون الحدود واضحة. أي البيانات تملكها Firebase وأيها تملكها API يجب أن يُكتب منذ اليوم الأول؛ وإلا عاشت المعلومة نفسها في مكانين ولا أحد يعرف أيهما الصحيح.
الخلاصة
Firebase والخدمات المشابهة أدوات حقيقية تسرّع الإصدار الأول لتطبيق الجوال؛ والمشكلة ليست في الأداة بل في القرار الذي لم يُتخذ. عندما تضطر إلى نقل قاعدة عمل إلى الخادم، أو يأتي عميل ثانٍ، أو يُطلب أول تقرير إداري، يكون المشروع قد تحول بالفعل إلى باك إند مخصص، وفعل ذلك عن قصد أرخص من فعله بالمصادفة. راسلنا عبر نموذج طلب العرض لنحدد معًا أين يجب أن تُخزَّن كل بيانات تطبيقك؛ وسنجيب معًا عن الأسئلة الثلاثة أعلاه في أول اجتماع.