> ## Content Index
> Fetch the complete content index at: https://arabroot.io/llms.txt
> Use this file to discover other available public pages before exploring further.

# ما هو Backend as a Service؟ وما بديل كل خدمة في Firebase
- URL: https://arabroot.io/articles/ما-هو-backend-as-a-service-وبدائل-firebase/
- Published: 2026-10-08T09:00:00.000Z
- Updated: 2026-10-09T13:02:09.000Z
- Description: ما الذي يقدمه ال Backend الجاهز لتطبيقك، ولماذا تصبح قواعد الوصول هي الحارس الوحيد لبياناتك، وما البديل المفتوح لكل خدمة في Firebase.
- Author: فريق عرب رووت
- Tags: الأدلة التقنية, الاستضافة الذاتية والتطبيقات, DevOps وCI/CD, السيادة الرقمية والامتثال, الاستضافة الذاتية

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

وهذا المقال هو أول مقالات مرحلة [بدائل Firebase](https://arabroot.io/start/#stage-firebase-alt) في خارطة الطريق، وهو مقال للفهم قبل التثبيت، فلا يحتاج منك سيرفراً ولا أوامر، وسوف نناقش في هذا المقال ما يلي:

- ما هو ال Backend as a Service، واختصاراً BaaS، وما الذي يقدمه، وكيف يختلف عن السيرفر الذي تكتبه بنفسك.
- لماذا يكلم التطبيق قاعدة البيانات مباشرة في هذا النموذج، ولماذا تصبح قواعد الوصول هي الحارس الوحيد للبيانات.
- خدمات Firebase خدمة خدمة: ما الذي تفعله كل واحدة منها، وما بديلها مفتوح المصدر الذي تستضيفه بنفسك، وأين لا يوجد بديل حقيقي.
- طبقات الارتباط بالمزود Vendor Lock-in، من المكتبة في كود التطبيق إلى كلمات المرور والإشعارات.
- أين تقيم بيانات المستخدمين Data Residency، وما الذي يتغير عندما تستضيف الخلفية بنفسك.
- متى يناسبك Firebase فعلاً، ومتى يكون البديل المستضاف أفضل.

## ما هو ال Backend as a Service؟

الخلفية Backend هي كل ما يعمل على السيرفر ولا يراه المستخدم: قاعدة البيانات التي تحفظ البيانات، والواجهة البرمجية API التي يطلب منها التطبيق هذه البيانات، والكود الذي يتحقق من هوية المستخدم ومن صلاحياته، والمهام التي تعمل في الخلفية مثل إرسال بريد الترحيب أو تصغير الصور المرفوعة. وال Backend as a Service هو خدمة تقدم لك هذه الأجزاء جاهزة، فبدل أن تكتب سيرفراً فيه نقاط نهاية Endpoints لكل عملية، تضيف إلى تطبيقك مكتبة SDK من المزود، ثم تستدعي منها دوال مثل تسجيل الدخول وحفظ مستند ورفع ملف، والمزود هو الذي يدير السيرفرات وقاعدة البيانات والنسخ الاحتياطي والتوسع.

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

والصورة التالية تبين الفرق بين الطريقتين، فعلى اليمين يكتب الفريق الواجهة البرمجية بنفسه ويربطها بكل جزء، وعلى اليسار يستدعي التطبيق الخدمات الجاهزة مباشرة عبر مكتبة المزود:

![مقارنة بين لوحتين: على اليمين تطبيق جوال يتصل بواجهة API يكتبها الفريق وتحتها قاعدة البيانات والملفات وتسجيل الدخول والإشعارات والمهام، وعلى اليسار تطبيق مع SDK يتصل بصندوق واحد اسمه Backend as a Service فيه Auth وDatabase وStorage وFunctions وPush وتحتها شريط أخضر لقواعد الوصول](https://arabroot.io/content/images/2026/10/baas-basics-01-what-backend.webp)

بدون BaaS تكتب كل جزء وتشغله، ومع BaaS تكتب نموذج البيانات والقواعد وبعض الدوال فقط

والأجزاء التي تقدمها أغلب خدمات BaaS متشابهة، وهي كما يلي:

- **المصادقة Authentication:** تسجيل المستخدمين ودخولهم بالبريد وكلمة المرور أو برقم الجوال أو بحساب Google وApple، وإصدار توكن Token يثبت هوية المستخدم في كل طلب، وقد شرحنا فكرة التوكن والجلسة في [الجلسات وملفات تعريف الارتباط وJWT](https://arabroot.io/articles/%D8%A7%D9%84%D8%AC%D9%84%D8%B3%D8%A7%D8%AA-%D9%88%D9%85%D9%84%D9%81%D8%A7%D8%AA-%D8%AA%D8%B9%D8%B1%D9%8A%D9%81-%D8%A7%D9%84%D8%A7%D8%B1%D8%AA%D8%A8%D8%A7%D8%B7-%D9%88-jwt-%D9%84%D9%84%D9%85%D8%A8%D8%AA%D8%AF%D8%A6%D9%8A%D9%86/).
- **قاعدة البيانات Database:** مكان لحفظ البيانات يقرأ منه التطبيق ويكتب فيه، وقد تكون قاعدة مستندات Document Database مثل Firestore، أو قاعدة علائقية Relational مثل PostgreSQL في Supabase.
- **التخزين Storage:** رفع الملفات والصور وتنزيلها، مع صلاحيات تحدد من يرى كل ملف، وقد شرحنا أنواع التخزين وواجهة S3 في [أنواع التخزين للمبتدئين](https://arabroot.io/articles/%D8%A7%D9%86%D9%88%D8%A7%D8%B9-%D8%A7%D9%84%D8%AA%D8%AE%D8%B2%D9%8A%D9%86-block-%D9%88-file-%D9%88-object-%D9%84%D9%84%D9%85%D8%A8%D8%AA%D8%AF%D8%A6%D9%8A%D9%86/).
- **الدوال Functions:** كود صغير يعمل على سيرفر المزود عند حدث معين، مثل تسجيل مستخدم جديد أو رفع ملف، أو عند طلب HTTP، وهو المكان المناسب للعمليات التي لا يجوز أن تعمل في جهاز المستخدم، مثل الاتصال ببوابة الدفع بمفتاح سري.
- **التحديث الفوري Realtime:** أن يصل التغيير في البيانات إلى الشاشات المفتوحة دون أن يعيد المستخدم تحميل الصفحة، وهو ما تحتاجه تطبيقات المحادثة واللوحات المشتركة.
- **الإشعارات Push Notifications:** إرسال تنبيه إلى هاتف المستخدم حتى وهو لا يستخدم التطبيق.

### ما الفرق بينه وبين سيرفرك وبين منصات النشر؟

وقد يتساءل البعض: ما الفرق بين BaaS وبين منصة نشر مثل Coolify أو Heroku؟ والإجابة أن منصة النشر Platform as a Service تشغل الكود الذي كتبته أنت، فأنت ما زلت تكتب الواجهة البرمجية والصلاحيات واستعلامات قاعدة البيانات، والمنصة توفر عليك تجهيز السيرفر والنشر فقط، كما شرحنا في [تثبيت Coolify](https://arabroot.io/articles/%D8%AA%D8%AB%D8%A8%D9%8A%D8%AA-coolify-%D9%84%D9%86%D8%B4%D8%B1-%D8%A7%D9%84%D8%AA%D8%B7%D8%A8%D9%8A%D9%82%D8%A7%D8%AA/). أما BaaS فيعطيك الواجهة البرمجية نفسها جاهزة، فلا يوجد سيرفر تكتبه في أغلب الحالات، والجدول التالي يلخص الفرق:

| السؤال                           | سيرفرك الخاص   | منصة نشر PaaS  | Backend as a Service        |
| -------------------------------- | -------------- | -------------- | --------------------------- |
| من يكتب الواجهة البرمجية API؟    | أنت            | أنت            | المزود، وأنت تكتب القواعد   |
| من يدير السيرفر وقاعدة البيانات؟ | أنت            | المنصة جزئياً  | المزود، أو أنت إذا استضفته  |
| أين تكتب الصلاحيات؟              | في كود السيرفر | في كود السيرفر | في قواعد الوصول داخل الخدمة |
| سرعة البداية                     | بطيئة          | متوسطة         | سريعة جداً                  |
| صعوبة الانتقال لاحقاً            | منخفضة         | منخفضة         | مرتفعة غالباً               |

## التطبيق يكلم قاعدة البيانات مباشرة، فمن يحمي البيانات؟

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

وقد يتساءل البعض: أليس هذا المفتاح سراً يجب إخفاؤه؟ والإجابة لا، فالمفتاح العام موجود في كود التطبيق الذي ينزله كل مستخدم، وأي شخص يستطيع أن يستخرجه من ملف التطبيق أو من أدوات المطور في المتصفح خلال دقائق، ولذلك لا يمنح هذا المفتاح أي صلاحية بنفسه، وإنما يعرف الخدمة بالمشروع فقط، والذي يقرر ما يراه كل طلب هو **قواعد الوصول**: ففي Firebase تسمى قواعد الأمان Security Rules، وفي Supabase هي سياسات الصفوف Row-Level Security داخل PostgreSQL نفسه. والصورة التالية تبين ذلك بطلبين يحملان المفتاح العام نفسه:

![هاتف سارة يرسل طلب GET /notes مع توكن سارة، وطلب curl من أي شخص يرسل الطلب نفسه دون توكن، والطلبان يمران على صندوق أخضر عليه درع اسمه Security Rules أو RLS وفيه الشرط owner_id = auth.uid()، ثم يصل الطلب الأول إلى جدول الملاحظات ويعود بملاحظتي سارة فقط، ويعود الطلب الثاني بقائمة فارغة](https://arabroot.io/content/images/2026/10/baas-basics-02-client-direct.webp)

المفتاح العام يعرفه الجميع، والقاعدة داخل الخلفية هي التي تقرر ما يعود لكل طلب

ولهذا فإن الخطأ الأخطر في هذا النموذج هو جدول أو مجموعة بيانات Collection بلا قاعدة، أو بقاعدة تسمح للجميع أثناء التطوير ثم تبقى كما هي بعد الإطلاق، فعندها يقرأ أي شخص يملك المفتاح العام كل البيانات بأمر واحد، دون أن يخترق شيئاً. وقد بينا ذلك عملياً في [دليل Supabase](https://arabroot.io/articles/%D8%AA%D8%AB%D8%A8%D9%8A%D8%AA-supabase-%D8%B9%D9%84%D9%89-%D8%B3%D9%8A%D8%B1%D9%81%D8%B1%D9%83/#rls-forgotten)، حيث أنشأنا جدول عملاء دون سياسة فأعاد كل الصفوف لأي طلب، ثم فعلنا السياسة فأصبحت النتيجة قائمة فارغة.

ولن نشرح هنا كيف تكتب سياسات الصفوف، لأننا شرحناها بالتفصيل وبتجربة كاملة في [سياسات الصفوف Row-Level Security خطوة بخطوة](https://arabroot.io/articles/%D8%A8%D9%86%D8%A7%D8%A1-%D8%AA%D8%B7%D8%A8%D9%8A%D9%82-saas-%D9%85%D8%AA%D8%B9%D8%AF%D8%AF-%D8%A7%D9%84%D9%85%D8%B3%D8%AA%D8%A7%D8%AC%D8%B1%D9%8A%D9%86-%D8%B9%D9%85%D9%84%D9%8A%D8%A7/#rls)، وشرحنا كيف تبني PostgREST وSupabase واجهة برمجية كاملة من قاعدة البيانات في [PostgreSQL لكل شيء](https://arabroot.io/articles/postgresql-%D9%84%D9%83%D9%84-%D8%B4%D9%8A%D8%A1-%D9%85%D8%AA%D9%89-%D8%AA%D9%83%D9%81%D9%8A%D9%83-%D9%82%D8%A7%D8%B9%D8%AF%D8%A9-%D8%A8%D9%8A%D8%A7%D9%86%D8%A7%D8%AA-%D9%88%D8%A7%D8%AD%D8%AF%D8%A9/#api). والقاعدة التي تكفيك الآن هي: لا تقم بإطلاق تطبيق مبني على BaaS قبل أن تختبر كل جدول بطلب دون تسجيل دخول وبطلب من مستخدم آخر، والسبب أن الخطأ هنا لا يظهر في الواجهة أبداً، فالتطبيق يعرض لكل مستخدم بياناته بشكل صحيح، بينما البيانات كلها مفتوحة لمن يطلبها خارج التطبيق.

⚠️

المفتاح السري Service Role Key أو Secret Key الذي يتجاوز القواعد كلها مكانه السيرفر أو الدوال فقط، ولا تضعه في تطبيق الجوال أو في كود المتصفح أبداً، والسبب أن أي مفتاح يصل إلى جهاز المستخدم يصل إلى كل من يريد استخراجه.

## ما الذي يقدمه Firebase خدمة خدمة، وما البديل المفتوح لكل منها؟

يقسم Firebase خدماته في موقعه إلى قسمين: خدمات البناء Build التي يعمل عليها التطبيق، وخدمات التشغيل Run التي تساعدك على مراقبته وتحسينه بعد الإطلاق. والصورة التالية تضع كل خدمة أمام البدائل مفتوحة المصدر التي تؤدي العمل نفسه على سيرفرك، ثم نشرح كل خدمة بعدها:

![جدول من أحد عشر صفاً: في كل صف خدمة من Firebase مثل Authentication وFirestore وCloud Storage وCloud Functions وCloud Messaging وRemote Config وCrashlytics وGoogle Analytics وTest Lab، وأمامها بدائلها مفتوحة المصدر مثل Supabase وAppwrite وPocketBase وntfy وUnleash وGlitchTip وUmami، والإشعارات ملونة بالأصفر لأن iPhone يحتاج APNs، وTest Lab بالأحمر لأنه لا يوجد بديل قريب](https://arabroot.io/content/images/2026/10/baas-basics-03-firebase-map.webp)

أغلب خدمات Firebase لها بديل ناضج، والإشعارات بديلها جزئي، واختبار التطبيق على أجهزة حقيقية لا يوجد له بديل قريب

### خدمات البناء Build

- **المصادقة Firebase Authentication:** تسجيل الدخول بالبريد ورقم الجوال وحسابات Google وApple وغيرها، وإدارة المستخدمين. والبديل هو خدمة المصادقة في Supabase أو Appwrite أو PocketBase إذا أردت كل شيء في منصة واحدة، أو مزود هوية مستقل مثل Keycloak وauthentik إذا كانت عندك عدة تطبيقات، وقد شرحنا [تثبيت authentik](https://arabroot.io/articles/%D8%AA%D8%AB%D8%A8%D9%8A%D8%AA-authentik-%D9%84%D9%84%D8%AF%D8%AE%D9%88%D9%84-%D8%A7%D9%84%D9%85%D9%88%D8%AD%D8%AF/) و[OAuth وOpenID Connect](https://arabroot.io/articles/%D8%B4%D8%B1%D8%AD-oauth-%D9%88-openid-connect-%D9%84%D9%84%D9%85%D8%A8%D8%AA%D8%AF%D8%A6%D9%8A%D9%86/).
- **قاعدة المستندات Cloud Firestore وقاعدة Realtime Database:** قاعدتا بيانات من نوع المستندات تتزامن مع التطبيق لحظياً، وFirestore هي الأحدث والموصى بها. والبديل الأقرب في الفكرة هو قاعدة Appwrite أو PocketBase، أما Supabase فيستبدلها بقاعدة PostgreSQL علائقية، وهذا يعني إعادة تصميم البيانات من مستندات متداخلة إلى جداول، وهو عمل حقيقي لكنه يعطيك SQL والقيود والعلاقات، كما شرحنا في [تصميم قواعد البيانات](https://arabroot.io/articles/%D8%AA%D8%B5%D9%85%D9%8A%D9%85-%D9%82%D9%88%D8%A7%D8%B9%D8%AF-%D8%A7%D9%84%D8%A8%D9%8A%D8%A7%D9%86%D8%A7%D8%AA-%D8%A7%D9%84%D8%AA%D8%B7%D8%A8%D9%8A%D8%B9-%D9%88%D8%A7%D9%84%D8%AA%D9%88%D8%B3%D8%B9/).
- **Firebase SQL Connect:** خدمة أحدث كانت تسمى Data Connect، تعطيك قاعدة PostgreSQL مدارة على Cloud SQL مع واجهة GraphQL، وصفحة [Data Connect](https://firebase.google.com/docs/data-connect?ref=arabroot.io) القديمة تحولك اليوم إلى [SQL Connect](https://firebase.google.com/docs/sql-connect?ref=arabroot.io). والبديل هو PostgreSQL نفسها مع PostgREST أو واجهة GraphQL، وهذا بالضبط ما يفعله Supabase.
- **التخزين Cloud Storage for Firebase:** رفع الملفات وتنزيلها بقواعد أمان. والبديل هو تخزين Supabase أو Appwrite، أو أي تخزين متوافق مع S3 مثل Garage وSeaweedFS خلف واجهتك.
- **الدوال Cloud Functions for Firebase:** كود Node.js أو Python يعمل عند حدث أو طلب HTTP. والبديل هو Edge Functions في Supabase أو Functions في Appwrite، أو ببساطة سيرفر صغير تكتبه بنفسك وتنشره كما في [Dokploy](https://arabroot.io/articles/%D8%AA%D8%AB%D8%A8%D9%8A%D8%AA-dokploy-%D9%84%D9%86%D8%B4%D8%B1-%D8%A7%D9%84%D8%AA%D8%B7%D8%A8%D9%8A%D9%82%D8%A7%D8%AA/).
- **الاستضافة Hosting وApp Hosting:** نشر الموقع الثابت أو تطبيق Next.js وأمثاله مع شهادة HTTPS. والبديل هو Caddy أو Nginx أمام ملفاتك، أو منصة مثل Coolify، كما في [تثبيت Caddy](https://arabroot.io/articles/%D8%AA%D8%AB%D8%A8%D9%8A%D8%AA-caddy-reverse-proxy/).
- **حماية الواجهة App Check:** يتأكد أن الطلبات تأتي من تطبيقك الحقيقي على جهاز سليم، عبر خدمات Apple وGoogle للتحقق من الجهاز. وهذه الخدمة لا يوجد لها بديل مفتوح كامل، لأنها تعتمد على شهادة من نظام تشغيل الهاتف نفسه، والبديل العملي هو تحديد معدل الطلبات Rate Limiting وقواعد وصول صارمة.
- **Firebase AI Logic:** استدعاء نماذج Gemini من التطبيق عبر Firebase. والبديل هو نموذج تشغله على سيرفرك خلف دالة، كما شرحنا في [تشغيل نماذج اللغة على جهازك](https://arabroot.io/articles/%D8%AA%D8%B4%D8%BA%D9%8A%D9%84-%D9%86%D9%85%D8%A7%D8%B0%D8%AC-%D8%A7%D9%84%D9%84%D8%BA%D8%A9-%D8%B9%D9%84%D9%89-%D8%AC%D9%87%D8%A7%D8%B2%D9%83-%D9%84%D9%84%D9%85%D8%A8%D8%AA%D8%AF%D8%A6%D9%8A%D9%86/).

### خدمات التشغيل Run

- **الإشعارات Firebase Cloud Messaging:** وتختصر FCM، وهي الطريق الذي ترسل منه الإشعارات إلى هواتف Android وiPhone والمتصفحات. وهنا الاستثناء الصادق الوحيد في هذه القائمة: ففي Android تستطيع أن تستبدل FCM بأدوات مثل ntfy وUnifiedPush، أما في iPhone فكل إشعار يمر عبر خدمة Apple Push Notification service، واختصاراً APNs، سواء أرسلته عبر Firebase أو عبر سيرفرك، فتستطيع أن تخرج Firebase من الطريق لكنك لا تستطيع أن تخرج Apple. وتفاصيل ذلك في مرحلة [الإشعارات والتنبيهات](https://arabroot.io/start/#stage-notifications).
- **الإعدادات عن بعد Remote Config واختبارات A/B Testing:** تغيير سلوك التطبيق وتجربة نسختين على مجموعتين من المستخدمين دون إصدار جديد. والبديل هو Unleash وFlagsmith وGrowthBook، وفكرتها في مرحلة [منصات المطورين](https://arabroot.io/start/#stage-devplatform).
- **تقارير الأعطال Crashlytics ومراقبة الأداء Performance Monitoring:** جمع أخطاء التطبيق وانهياراته وبطء الشاشات. والبديل هو Sentry بنسخته المستضافة أو GlitchTip المتوافق مع مكتبات Sentry.
- **التحليلات Google Analytics:** قياس استخدام التطبيق. والبديل هو Umami وMatomo وPostHog، وموقعنا نفسه يستخدم Umami على سيرفرنا.
- **الرسائل داخل التطبيق In-App Messaging:** رسائل تظهر للمستخدم داخل التطبيق حسب سلوكه، وبديلها جزء من أدوات مثل PostHog أو كود تكتبه فوق قاعدة بياناتك.
- **مختبر الاختبار Test Lab وتوزيع النسخ التجريبية App Distribution:** تشغيل تطبيقك على أجهزة حقيقية في مراكز Google، وإرسال النسخ التجريبية إلى المختبرين. وهذا هو الجزء الذي لا يوجد له بديل قريب تستضيفه بنفسك، لأن قيمته في مئات الأجهزة الحقيقية وليس في البرنامج، والبديل العملي هو قنوات الاختبار في متجري Apple وGoogle نفسيهما.

💡

في 25 أغسطس 2025 أوقفت Google خدمة [Firebase Dynamic Links](https://firebase.google.com/support/dynamic-links-faq?ref=arabroot.io) بشكل نهائي، وهي الروابط التي تفتح شاشة معينة داخل التطبيق أو تحول المستخدم إلى المتجر، فأصبحت كل الروابط القديمة المنشورة في الرسائل والإعلانات تعيد خطأ، واضطرت كل التطبيقات التي تعتمد عليها إلى نقل الروابط إلى حل آخر قبل الموعد. والدرس أن الخدمة المدارة قد تتوقف بقرار من المزود مهما كانت مستقرة، فاجعل الأجزاء التي تنتشر خارج تطبيقك، مثل الروابط والنطاقات، تحت اسم نطاقك أنت.

## أين يقيدك المزود؟

الارتباط بالمزود Vendor Lock-in ليس أمراً سيئاً في كل حال، فكل أداة تختارها تربطك بها بدرجة ما، والسؤال الصحيح هو: كم يكلف الخروج إذا احتجت إليه؟ ومع BaaS يأتي الارتباط من خمس طبقات، كما تبين الصورة التالية:

![خمسة صفوف مرقمة: استدعاءات SDK في كود التطبيق بدرجة متوسطة، ونموذج البيانات وصيغة التصدير بدرجة عالية، وكلمات المرور وحسابات المستخدمين بدرجة عالية، ولغة قواعد الأمان بدرجة متوسطة، والإشعارات عبر نظام تشغيل الهاتف بدرجة لا يمكن إزالتها](https://arabroot.io/content/images/2026/10/baas-basics-04-lock-in.webp)

كلما انتشرت مكتبة المزود في كودك وكثر مستخدموك زادت كلفة الخروج

1. **مكتبة SDK في كل شاشة:** إذا كانت كل شاشة تستدعي دوال Firebase مباشرة، فالخروج يعني تعديل كل هذه الشاشات. والحل الأنسب أن تضع طبقة بيانات صغيرة في التطبيق، أي ملف أو كلاس واحد يكلم المزود، وبقية التطبيق يكلم هذه الطبقة، فإذا غيرت المزود غيرت ملفاً واحداً.
2. **نموذج البيانات وصيغة التصدير:** بيانات Firestore مستندات متداخلة، وأداة [التصدير المدارة](https://firebase.google.com/docs/firestore/manage-data/export-import?ref=arabroot.io) تكتب نسخة في Cloud Storage يمكن استيرادها في قاعدة Firestore أخرى أو تحميلها في BigQuery، وليست ملف SQL أو JSON تفتحه في أي قاعدة، فالانتقال إلى قاعدة علائقية يحتاج سكربتاً يقرأ المستندات ويكتبها في جداول.
3. **كلمات المرور:** الأمر `firebase auth:export` يصدر حسابات المستخدمين إلى ملف JSON أو CSV، لكن [توثيق Firebase](https://firebase.google.com/docs/cli/auth?ref=arabroot.io) يذكر أن أغلب المشاريع تحفظ كلمات المرور بنسخة معدلة من خوارزمية scrypt، فالنظام الجديد يجب أن يعرف كيف يتحقق من هذا الهاش Hash مع معاملاته السرية، وإلا يضطر كل مستخدم إلى تعيين كلمة مرور جديدة، وهذا ما سوف نفصله في مقال الانتقال من Firebase ضمن المرحلة.
4. **لغة قواعد الأمان:** قواعد Firebase مكتوبة بلغة خاصة به، والانتقال إلى Supabase يعني إعادة كتابتها سياسات RLS في SQL، ثم اختبارها من جديد بطلب من كل نوع من المستخدمين.
5. **الإشعارات:** كما ذكرنا، فإشعارات iPhone تمر عبر APNs دائماً، فهذه طبقة لا تخرج منها بتغيير المزود.

ولاحظ أن Supabase وAppwrite نفسيهما يقدمان خدمة سحابية مدارة بجانب النسخة التي تستضيفها، والفرق أن الكود مفتوح المصدر والبيانات في قاعدة تعرف كيف تأخذ نسخة منها، فإذا ارتفع السعر أو تغيرت الشروط تستطيع أن تنقل المشروع نفسه إلى سيرفرك، وهذا هو المعنى العملي لأن تكون الأداة مفتوحة المصدر، كما شرحنا في [ما هي البرمجيات مفتوحة المصدر](https://arabroot.io/articles/%D9%85%D8%A7-%D9%87%D9%8A-%D8%A7%D9%84%D8%A8%D8%B1%D9%85%D8%AC%D9%8A%D8%A7%D8%AA-%D9%85%D9%81%D8%AA%D9%88%D8%AD%D8%A9-%D8%A7%D9%84%D9%85%D8%B5%D8%AF%D8%B1-%D9%88%D8%AA%D8%B1%D8%A7%D8%AE%D9%8A%D8%B5%D9%87%D8%A7/).

## أين تقيم بيانات مستخدميك Data Residency؟

إقامة البيانات Data Residency تعني المكان الجغرافي الذي تحفظ فيه البيانات وتعالج، وهي سؤال قانوني قبل أن تكون سؤالاً تقنياً، ففي المملكة مثلاً يضع [نظام حماية البيانات الشخصية](https://dgp.sdaia.gov.sa/wps/portal/pdp/?ref=arabroot.io) و[لائحة نقل البيانات الشخصية خارج المملكة](https://dgp.sdaia.gov.sa/wps/portal/pdp/knowledgecenter/details/RegulationonPersonalDataTransferOutsidetheKingdom?ref=arabroot.io) شروطاً على نقل البيانات الشخصية إلى الخارج، والجهات الحكومية لها سياسات أشد. والصورة التالية تبين أين تعالج بيانات تطبيق مبني على Firebase، بحسب صفحة [الخصوصية والأمان في Firebase](https://firebase.google.com/support/privacy?ref=arabroot.io):

![ثلاث لوحات: الأولى حمراء لخدمة Firebase Authentication مع سحابة برتقالية وعبارة مراكز بيانات الولايات المتحدة فقط وتحتها مستخدمون مع البريد والأرقام وهاش كلمات المرور، والثانية صفراء لخدمات Firestore والتخزين والدوال مع منطقة تختارها مثل الدمام me-central2، والثالثة خضراء لخلفية مستضافة على سيرفرك](https://arabroot.io/content/images/2026/10/baas-basics-05-data-location.webp)

المصادقة في Firebase تعمل من الولايات المتحدة فقط، وبعض الخدمات تسمح لك باختيار المنطقة

- **المصادقة Authentication:** صفحة الخصوصية في Firebase تقول بوضوح إن خدمة المصادقة تعمل من مراكز بيانات في الولايات المتحدة فقط، أي أن بريد كل مستخدم ورقم جواله وهاش كلمة مروره وعناوين IP التي دخل منها تعالج هناك، أياً كانت المنطقة التي اخترتها لبقية المشروع.
- **Firestore والتخزين والدوال:** تسمح لك باختيار المنطقة، و[قائمة مواقع Firestore](https://firebase.google.com/docs/firestore/locations?ref=arabroot.io) فيها اليوم منطقة الدمام `me-central2`، لكن الصفحة نفسها تذكر أن أغلب خدمات Firebase الأخرى تعمل على بنية Google العالمية وقد تعالج البيانات في أي من مواقعها.
- **خلفية مستضافة على سيرفرك:** البيانات كلها، بما فيها حسابات المستخدمين، في السيرفر الذي اخترته وفي الدولة التي اخترتها، ومعها النسخ الاحتياطية والسجلات، لكنك أصبحت أنت المسؤول عن التحديثات الأمنية والتوفر والنسخ الاحتياطي، وهذا ثمن حقيقي يجب أن تحسبه، كما شرحنا في [الاستضافة الذاتية: متى تكون قراراً استراتيجياً لمؤسستك، ومتى لا تناسبها](https://arabroot.io/articles/%D8%A7%D9%84%D8%A7%D8%B3%D8%AA%D8%B6%D8%A7%D9%81%D8%A9-%D8%A7%D9%84%D8%B0%D8%A7%D8%AA%D9%8A%D8%A9-%D9%85%D8%AA%D9%89-%D8%AA%D8%B5%D8%A8%D8%AD-%D8%AE%D9%8A%D8%A7%D8%B1%D8%A7-%D8%A7%D8%B3%D8%AA%D8%B1%D8%A7%D8%AA%D9%8A%D8%AC%D9%8A%D8%A7-%D9%84%D8%A3%D8%B9%D9%85%D8%A7%D9%84%D9%83/).

## متى يناسبك Firebase، ومتى تستضيف البديل؟

لا ينصح بأن تبدأ كل مشروع ببديل مستضاف لأن Firebase من Google، ولا بأن تبقى على Firebase لأن البداية فيه سهلة، وإنما يحكم القرار عدد من الأسئلة العملية:

| الحالة                                                                    | الأنسب                                      | والسبب                                                                          |
| ------------------------------------------------------------------------- | ------------------------------------------- | ------------------------------------------------------------------------------- |
| نموذج أولي Prototype أو مسابقة أو تطبيق داخلي صغير بلا بيانات شخصية حساسة | Firebase أو النسخة السحابية من Supabase     | البداية أسرع، والخطة المجانية تكفي، ولا يوجد ما يبرر تشغيل سيرفر                |
| تطبيق لعملاء في المملكة فيه بيانات شخصية، أو جهة حكومية                   | Supabase أو Appwrite على سيرفر داخل المملكة | حسابات المستخدمين نفسها لا يمكن إبقاؤها داخل المملكة في Firebase Authentication |
| بيانات علائقية وتقارير واستعلامات معقدة                                   | Supabase                                    | تحصل على PostgreSQL كاملة بدل قاعدة مستندات                                     |
| فريق صغير جداً ومشروع صغير على سيرفر واحد                                 | PocketBase                                  | ملف تنفيذي واحد وقاعدة SQLite، وإدارته أبسط ما يمكن                             |
| تعتمد على Test Lab أو على أجهزة Google للاختبار                           | ابق على هذا الجزء من Firebase               | لا يوجد بديل تستضيفه، ويمكن أن تنقل البقية وتبقيه وحده                          |

ولاحظ أن القرار ليس كل شيء أو لا شيء، فتستطيع أن تنقل قاعدة البيانات والمصادقة إلى Supabase وتبقي FCM للإشعارات وCrashlytics للأعطال، لأن هذه الخدمات لا تحمل بيانات المستخدمين الأساسية. وتفاصيل كل أداة في مقالات المرحلة القادمة بإذن الله: [تثبيت Supabase على سيرفرك](https://arabroot.io/articles/%D8%AA%D8%AB%D8%A8%D9%8A%D8%AA-supabase-%D8%B9%D9%84%D9%89-%D8%B3%D9%8A%D8%B1%D9%81%D8%B1%D9%83/) وهو المقال التالي، ثم Appwrite وPocketBase والمقارنة بينها، ثم الإشعارات بدون Firebase، ثم الانتقال من Firebase بالبيانات والمستخدمين وكلمات المرور، كما في [صفحة المرحلة](https://arabroot.io/start/#stage-firebase-alt).

## أخطاء شائعة

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

## الخلاصة

وصلنا لنهاية الموضوع، وأهم ما فيه:

- ال Backend as a Service يعطيك المصادقة وقاعدة البيانات والتخزين والدوال والإشعارات جاهزة خلف مكتبة واحدة، فتبدأ بسرعة مقابل ارتباط أكبر بالمزود.
- التطبيق يكلم قاعدة البيانات مباشرة بمفتاح عام يعرفه الجميع، فقواعد الأمان أو سياسات RLS هي الحارس الوحيد، وجدول بلا قاعدة مفتوح لكل من يطلبه.
- لكل خدمة بناء في Firebase بديل مفتوح ناضج، مثل Supabase وAppwrite وPocketBase، والإشعارات على iPhone تمر عبر APNs دائماً، واختبار الأجهزة الحقيقية لا بديل له تستضيفه.
- الارتباط بالمزود يأتي من مكتبة SDK ونموذج البيانات وهاش كلمات المرور ولغة القواعد والإشعارات، وطبقة بيانات واحدة في التطبيق تخفف أغلبه.
- Firebase Authentication يعالج بيانات المستخدمين في الولايات المتحدة فقط، فإذا كانت إقامة البيانات شرطاً عندك فالخلفية المستضافة داخل الدولة هي الحل.

[![](https://arabroot.io/content/images/2026/10/supabase-cover-cover.webp)دليلSupabase على سيرفرك: بديل Firebase فوق PostgreSQLكيف تثبت Supabase على سيرفرك وتبني عليه تطبيقاً صغيراً بمستخدمين وصلاحيات وملفات، وما الذي ينقص النسخة المستضافة عن السحابية.](https://arabroot.io/articles/%D8%AA%D8%AB%D8%A8%D9%8A%D8%AA-supabase-%D8%B9%D9%84%D9%89-%D8%B3%D9%8A%D8%B1%D9%81%D8%B1%D9%83/)[![](https://arabroot.io/content/images/2026/10/postgres-for-everything-cover-cover.webp)دليلPostgreSQL لكل شيء: متى يكفيك ومتى تحتاج غيره؟كم عملاً يستطيع PostgreSQL واحد أن يقوم به في شركتك الناشئة قبل أن تحتاج Redis أو Elasticsearch، وما الإشارة التي تقول لك إن الوقت قد حان.](https://arabroot.io/articles/postgresql-%D9%84%D9%83%D9%84-%D8%B4%D9%8A%D8%A1-%D9%85%D8%AA%D9%89-%D8%AA%D9%83%D9%81%D9%8A%D9%83-%D9%82%D8%A7%D8%B9%D8%AF%D8%A9-%D8%A8%D9%8A%D8%A7%D9%86%D8%A7%D8%AA-%D9%88%D8%A7%D8%AD%D8%AF%D8%A9/)[![](https://arabroot.io/content/images/2026/10/multi-tenancy-practice-cover-cover.webp)دليلتطبيق SaaS متعدد المستأجرين عملياً مع Row-Level Securityنبني على PostgreSQL تطبيق SaaS يعزل كل مستأجر Tenant عن غيره بسياسات Row-Level Security، ونرى أين تتسرب البيانات رغم ذلك.](https://arabroot.io/articles/%D8%A8%D9%86%D8%A7%D8%A1-%D8%AA%D8%B7%D8%A8%D9%8A%D9%82-saas-%D9%85%D8%AA%D8%B9%D8%AF%D8%AF-%D8%A7%D9%84%D9%85%D8%B3%D8%AA%D8%A7%D8%AC%D8%B1%D9%8A%D9%86-%D8%B9%D9%85%D9%84%D9%8A%D8%A7/)

## سجل التحديثات

- أكتوبر 2026: كتابة المقال، ومراجعة قائمة خدمات Firebase ومواقع البيانات من توثيقه الرسمي، وأمثلة الصلاحيات من تجربة Supabase المستضافة في مقال المرحلة التالي.