Supabase أم Firebase: أيّهما تستطيع مغادرته

الخاصية التي تحسم هذا الاختيار ليست قائمة الميزات، بل الخروج. Supabase تضع قاعدة PostgreSQL عادية في المركز، فللبيانات شكل يستطيع مضيف آخر تشغيله. وFirebase تضع مخزن مستندات في المركز، وحزمة تطوير العميل (SDK) هي الشكل نفسه: تكتبون مستندات لا صفوفًا، والقواعد التي تحميها مكتوبة بلغة لا يقيّمها غير Firebase. وينقلب الجواب حين يجب أن يعمل التطبيق دون اتصال على هاتف.

ما نموذج البيانات، وهل يمكن حمله معكم؟

Supabase هي PostgreSQL: جداول ومفاتيح أجنبية ووصلات ومعاملات وسجل ترحيل محفوظ في ملفات SQL، والمحرك نفسه الذي تشغّلونه على مضيف مُدار أو على خادم تملكونه. والنسخة الكاملة هي تفريغ قاعدة البيانات بصيغتها، ويستعيدها فريق آخر دون أن يعرف من أنتجها.

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

ماذا تفعل واجهة تتحدث إلى قاعدة البيانات مباشرة بقواعدكم؟

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

في Supabase الحارس صلاحيات على مستوى الصف: سياسات SQL على كل جدول، يقيّمها PostgreSQL نفسه، مكتوبة بلغة المخطط وقابلة للاختبار باستعلام. والمفتاح المنشور يُشحن داخل حزمة المتصفح، فجدول بلا سياسة جدول عام؛ الوضع الافتراضي مفتوح حتى يغلقه أحد.

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

في الحالتين، الصلاحيات قاعدة شيفرة ثانية تُنشر بجدولها، وهي الجزء الأقل مراجعة في معظم المشاريع. إرشادات OWASP للمصادقة مكتوبة للخوادم، لكن القاعدة التي تحتها تنتقل إلى هذا السياق: القرار في المكان الذي تحلّ فيه البيانات، وكل ما يكلّف مالًا يحتاج فحصًا لا يتجاوزه العميل.

كم يكلّفكم الحساب والتخزين عند المغادرة؟

هذا الجزء يستصغره الفريق لأنه لا يظهر ما دام كل شيء يعمل.

الحساب أصعب ما يُنقل: سجلات المستخدمين، وتجزئات كلمات المرور، وأرقام الهاتف المؤكدة، والحسابات المرتبطة بجوجل أو آبل، والجلسات المفتوحة. اسألوا قبل التوقيع ماذا تحمل النسخة الكاملة: سجلات مع تجزئات كلمات المرور، أم قائمة بريد فقط. الجواب يحدد هل المغادرة نهاية أسبوع أم ربع سنة.

وتخزين الملفات أسهل، وليس مجانيًا. Supabase تحفظ الملفات في حاوية متوافقة مع S3 وسياساتها مكتوبة بلغة SQL، فالنسخة تُسحب بأدوات عادية. وFirebase Storage يقوم على حاوية تصلون إليها كذلك، لكن روابط التنزيل التي يتلقاها التطبيق مصنوعة على مقاس المورّد، وكل رابط محفوظ في قاعدة بياناتكم يُعاد كتابته عند تغيير المضيف.

والفخ الهادئ هو الدخول برقم الهاتف: تسليم الرسائل القصيرة ترتيب تجاري لكل بلد، لا خيار في المنصة. تأكدوا من وصول رسائل التحقق إلى أرقام جزائرية قبل أن تبنوا التسجيل عليها.

متى يكون العمل دون اتصال هو الفيصل؟

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

وفي Supabase النتيجة نفسها ممكنة، لكن المزامنة تبنونها: مخزن محلي، وطابور كتابات معلّقة، وقواعد تعارض، وقرار فيما يحدث حين يعدّل جهازان السجل نفسه. هذه ميزة حقيقية بكلفة حقيقية.

أما نظام إدارة داخلي يُستخدم على حاسوب موصول، فالعمل دون اتصال شرط لا يحتاجه أحد. حدّدوا أي الحالتين عندكم قبل أي مقارنة.

كيف يبدو الاختيار كاملًا؟

البعد	Supabase	Firebase
نموذج البيانات	PostgreSQL: جداول ووصلات ومعاملات	Firestore: مستندات وفهارس معلنة
ما تمنحه النسخة الكاملة	تفريغ يستعيده مضيف آخر	مستندات تُعاد بنيتها في مكان آخر
أين تسكن الصلاحيات	سياسات SQL داخل قاعدة البيانات	لغة قواعد تُقيَّم لكل مستند
العمل دون اتصال	تبني طبقة المزامنة	مدمج في أدوات العميل
ما تتحققون منه	أي نسخة تشمل المستخدمين والملفات	ماذا تحمل نسخة الحسابات كاملة

كيف يقرر الفريق؟

1. اكتبوا خمسة أسئلة سيطرحها العمل على هذه البيانات بعد سنة. إن احتاج أحدها وصلة، فهذه نقطة ضد المستندات.
2. قرّروا هل يجب أن يعمل التطبيق دون اتصال. إن وجب، فاختبروا ذلك المسار قبل غيره.
3. اطلبوا من المورّدين كتابةً نسخة كاملة: المخطط والبيانات والمستخدمين والملفات. قارنوا الأجوبة لا الصفحات التسويقية.
4. استعيدوا تلك النسخة في بيئة جديدة وسلّموها لمن لم يرَ المشروع. إن لم يستطع تشغيلها فقد قستم الخروج.
5. قارنوا الأدوات واللوحات والشروط بعد ذلك، وكلفة الخروج مكتوبة في القرار.

أين يخطئ الفريق؟

• قواعد تُكتب في النهاية. يخرج النموذج الأولي بجدول مفتوح، ويأتي موعد الإطلاق، فتُكتب السياسات على عجل.
• لوحة إدارة بالمفتاح العام. تُبنى لوحة على مفتاح التطبيق نفسه، فيقرأ كل زائر ما تقرؤه اللوحة.
• لوحة المورّد بدل التقارير. لا أحد يبني التقرير الذي يحتاجه المحاسب، لأن لوحة عرضت رقمًا مرة واحدة.
• روابط التخزين في قاعدة البيانات. تنتقل الملفات وتبقى الروابط، فتنكسر كل صورة دفعة واحدة.
• حصص تُكتشف في الإنتاج. يُدرَك حد لم يقرأه أحد أثناء حملة، فتبدأ الكتابات بالفشل.

ما لا يغطيه هذا الرأي

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

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

نبني قاعدة البيانات كالجزء الذي تحتفظون به، والمورّد كالجزء الذي تستطيعون استبداله، لأن الخروج هو قرار التصميم.