Firebase أو Supabase أو باك إند خاص؟ إطار قرار من عبدالله عبدالرحيم سنكر

كل تطبيق يحتاج «خلفية»: مكان تُحفظ فيه البيانات، وتسجيل دخول، وملفات، وإشعارات. وقبل ما تنكتب أول شاشة، لازم تختار: خدمة جاهزة مثل Firebase أو Supabase، أو باك إند يُبنى لك من الصفر. عبدالله عبدالرحيم سنكر يتعامل مع هذا السؤال في كل مشروع تطبيق أو موقع، وما عنده جواب واحد يصلح للكل. عنده بدال الجواب أربعة أسئلة، وإذا جاوبتها بصدق يطلع لك الخيار المناسب لحاله.

قبل الأسئلة: اعرف الخيارات بدون تسويق

Firebase من جوجل: قاعدة بيانات Firestore من نوع المستندات، مع تسجيل دخول وتخزين ملفات ودوال سحابية وإشعارات وتحليلات، كلها مترابطة ومتكاملة مع Flutter بشكل ممتاز. Supabase مبني على PostgreSQL، قاعدة بيانات علائقية حقيقية بجداول وعلاقات و SQL، مع تسجيل دخول وتخزين ودوال، وكوده مفتوح المصدر وتقدر تستضيفه بنفسك. والباك إند الخاص يعني خادماً وقاعدة بيانات تختارهم أنت، ومنطقاً يُكتب بلغة مثل TypeScript أو Dart، وتشغيلاً تتحمّل مسؤوليته كاملة. والثلاثة تشتغل مع Flutter ومع Next.js، فاختيار الواجهة ما يفرض عليك الخلفية.

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

السؤال الأول: وش شكل بياناتك؟

هذا أهم سؤال وأكثر سؤال يُهمل. لو بياناتك مترابطة بقوة — عملاء لهم طلبات، والطلبات فيها منتجات، والمنتجات لها مخزون في فروع، وتحتاج تقارير تجمع كل هذا — فقاعدة علائقية مثل PostgreSQL تريحك، و Supabase أو الباك إند الخاص أقرب لك. ولو بياناتك مستندات مستقلة نسبياً — رسائل محادثة، وملفات شخصية، ومنشورات — وتحتاج تحديثاً لحظياً على الشاشة، فـ Firestore يلمع. اختيار قاعدة مستندات لبيانات علائقية معناه إنك بتكتب في الكود اللي كانت قاعدة البيانات بتسويه عنك. مثال صغير يوضح: تقرير «أكثر عشرة منتجات مبيعاً في كل فرع خلال الشهر» استعلام SQL واحد في PostgreSQL، أما في Firestore فغالباً تحتاج تحسبه مسبقاً وتخزّن النتيجة، أو تنقل البيانات لأداة تحليل منفصلة. وخلّك صريح مع نفسك: أنظمة أعمال كثيرة تبدأ «بسيطة» وتتحول خلال سنة لعلاقات وتقارير.

السؤال الثاني: كيف بتدفع لما تكبر؟

Firestore يُحاسب بشكل أساسي على عدد عمليات القراءة والكتابة. هذا رخيص جداً في البداية، لكن شاشة مصمّمة بدون انتباه — تقرأ مئات المستندات كل ما فتحها مستخدم — ممكن تفاجئك بفاتورة. ونفس الشي مع الاستماع اللحظي لقائمة طويلة: كل تغيير ينحسب قراءة عند كل مستخدم فاتح الشاشة، فالتصميم الذكي يحدد عدد العناصر ويقسّم القوائم لصفحات. Supabase يُحاسب أكثر حسب الخطة وموارد المشروع، فالتكلفة أسهل في التوقّع. والباك إند الخاص تدفع فيه سعر الخادم، لكنك تدفع كمان وقت التشغيل والمراقبة والتحديثات الأمنية، وهذا الوقت تكلفة حقيقية حتى لو ما ظهر في فاتورة. القاعدة: لا تقارن سعر الشهر الأول، قارن السعر عند عشرة أضعاف مستخدميك الحاليين. واطلب من المطوّر تقديراً مكتوباً للتكلفة عند ثلاثة أحجام: اليوم، وبعد سنة، ويوم ينجح المشروع نجاحاً كبيراً.

السؤال الثالث: قد إيش تتحمّل الارتباط بمزوّد؟

الخدمة الجاهزة تسرّعك، لكنها تربطك. الخروج من Firestore يعني إعادة تصميم البيانات وإعادة كتابة القواعد والاستعلامات. الخروج من Supabase أسهل نسبياً لأن تحته PostgreSQL قياسي تنقله لأي مكان، مع إن بعض ميزاته الخاصة بتحتاج بديلاً. والباك إند الخاص ما يربطك بمزوّد، لكنه ممكن يربطك بالشخص اللي كتبه إذا ما كان موثّقاً ومكتوباً بطريقة يفهمها غيره. وعشان تقيس ارتباطك بصدق، اسأل: لو تضاعف السعر غداً، أو تغيّرت شروط الخدمة، كم أسبوع أحتاج عشان أنتقل؟ إذا الجواب «ما أدري»، فأنت مرتبط أكثر مما تظن. والفريق نفسه جزء من المعادلة: أداة يعرفها فريقك جيداً اليوم أسلم غالباً من أداة أفضل نظرياً يتعلمها على حساب مشروعك.

السؤال الرابع: وين لازم تكون البيانات، ومين يحرسها؟

بعض القطاعات — الصحة، والقانون، والمالية — عندها اشتراطات على مكان تخزين البيانات وطريقة حمايتها، وفي السعودية نظام حماية البيانات الشخصية. قبل ما تختار، تأكد من مناطق الاستضافة المتاحة في كل خدمة ومن اشتراطات قطاعك. وتذكّر إن الأمان في الخدمات الجاهزة مسؤوليتك أنت: قواعد الأمان في Firebase وسياسات RLS في Supabase إذا ما انكتبت صح، تصير بياناتك مكشوفة لأي شخص يعرف عنوان المشروع، لأن التطبيق يتصل بالقاعدة مباشرة. واسأل كمان عن النسخ الاحتياطية: هل تؤخذ تلقائياً، وكم يوم تبقى، وهل جرّب أحد يسترجع منها فعلاً؟

الخلاصة في شكل قرار

• نموذج أولي، أو تطبيق تحديثاته لحظية وبياناته بسيطة العلاقات: Firebase يوصلك أسرع، خصوصاً مع Flutter، لأن حزمه الرسمية ناضجة ومجرّبة.
• نظام أعمال فيه علاقات وتقارير واشتراكات، وتبي مرونة SQL مع سرعة البداية: Supabase، وتبقى قاعدة بياناتك PostgreSQL عادية تقدر تاخذها معك.
• منطق أعمال معقد، أو تكامل مع أنظمة داخلية، أو اشتراطات استضافة صارمة، أو حجم يخلّي التحكم الكامل أوفر: باك إند خاص.
• محتار؟ ابدأ بالخيار اللي يسمح لك تطلع منه بأقل تكلفة، واجمع كل تعامل مع البيانات في طبقة وحدة داخل تطبيقك، عشان التبديل لاحقاً يصير في مكان واحد مو في مئة شاشة.

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

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