تقدّم هذه الصفحة أفضل الممارسات العامة وعالية المستوى لإعداد مشاريع Firebase وتسجيل تطبيقاتك في مشروع حتى يكون لديك سير عمل واضح للتطوير يستخدم بيئات مختلفة. بعد التعرّف على أفضل الممارسات في هذه الصفحة، ننصحك بالاطّلاع على إرشادات الأمان العامة.
التعرّف على التسلسل الهرمي لمشاريع Firebase
يعرض هذا الرسم البياني التسلسل الهرمي الأساسي لمشروع Firebase. في ما يلي العلاقات الرئيسية:
يشبه مشروع Firebase حاوية لجميع تطبيقاتك وأي موارد وخدمات يتم توفيرها للمشروع.
يمكن أن يحتوي مشروع Firebase على تطبيق واحد أو أكثر على Firebase مسجّلة فيه (على سبيل المثال، كلّ من إصدارَي iOS وAndroid لتطبيق، أو كلّ من الإصدارَين المجاني والمدفوع لتطبيق).
تتشارك جميع التطبيقات على Firebase المسجّلة في مشروع Firebase نفسه في جميع الموارد والخدمات نفسها التي تم توفيرها للمشروع، ويمكنها الوصول إليها. إليك بعض الأمثلة:
تتشارك جميع التطبيقات على Firebase المسجّلة في مشروع Firebase نفسه في الخلفيات نفسها، مثل Firebase Hosting وAuthentication وRealtime Database وCloud Firestore وCloud Storage وCloud Functions.
ترتبط جميع التطبيقات على Firebase المسجّلة في مشروع Firebase نفسه بموقع "إحصاءات Google" نفسه، حيث يكون كل تطبيق على Firebase مصدر بيانات منفصلاً في هذا الموقع.
ما هو دور مشروع Google Cloud في هذا التسلسل الهرمي؟
أحد جوانب التسلسل الهرمي لمشروع Firebase غير الموضّحة في الرسم البياني أعلاه هو العلاقة بمشروع Google Cloud. مشروع Firebase هو في الواقع مجرّد مشروع Google Cloud تم تفعيل إعدادات وخدمات إضافية خاصة بمنصّة Firebase له. يُرجى العِلم أنّ جميع التطبيقات المسجّلة في مشروع Firebase نفسه تتشارك أيضًا في جميع موارد وخدمات Google Cloud نفسها ويمكنها الوصول إليها.Google Cloud
مزيد من المعلومات عن العلاقة بين Firebase وGoogle Cloud في مقالة التعرّف على مشاريع Firebase
تسجيل أشكال التطبيقات المختلفة في مشاريع Firebase
في ما يلي بعض النصائح المهمة لتسجيل أشكال التطبيقات المختلفة في مشروع Firebase:
تأكَّد من أنّ جميع التطبيقات المسجّلة في مشروع Firebase هي أشكال مختلفة من المنصات للتطبيق نفسه من منظور المستخدم النهائي. سجِّل إصدارات iOS وAndroid والويب من التطبيق أو اللعبة نفسها في مشروع Firebase نفسه.
إذا كان لديك أشكال متعدّدة من الإصدارات يمكنها مشاركة موارد Firebase نفسها، سجِّل الأشكال في مشروع Firebase نفسه. بعض الأمثلة هي مدونة وتطبيق ويب في المشروع نفسه، أو كلّ من الإصدارَين المجاني والمدفوع من التطبيق نفسه في المشروع نفسه.
إذا كان لديك أشكال متعدّدة من الإصدارات تستند إلى حالة الإصدار (بدلاً من استنادها إلى نشاط المستخدم النهائي أو وصوله الشائع، كما هو موضّح أعلاه)، سجِّل كل شكل في مشروع Firebase منفصل. أحد الأمثلة هو إصدار تصحيح الأخطاء مقابل بنية الإصدار، لذا سجِّل كل إصدار من هذَين الإصدارَين في مشروع Firebase خاص به.
يجب ألا تتشارك الإصدارات المستندة إلى حالة الإصدار في موارد Firebase نفسها لأنّ ذلك يعرّض بيانات التصحيح لخطر إفساد بيانات الإنتاج أو حتى استبدالها.
يجب أن تكون الأشكال المختلفة للمنصات لكل شكل من أشكال الإصدارات هذه في مشروع Firebase نفسه. على سبيل المثال، سجِّل كلّ من إصدارَي التصحيح لنظامَي التشغيل iOS وAndroid في مشروع Firebase "للتطوير" لأنّهما يمكنهما التفاعل مع البيانات والموارد غير الخاصة بالإنتاج نفسها.
تجنُّب استخدام مشاريع متعددة المستأجرين
يمكن أن يؤدي استخدام مشاريع متعددة المستأجرين إلى مشاكل خطيرة في الإعداد وخصوصية البيانات، بما في ذلك مشاكل غير مقصودة في تجميع الإحصاءات والمصادقة المشتركة وهياكل قواعد البيانات المعقّدة للغاية والصعوبات في قواعد الأمان.
بشكل عام، إذا كانت مجموعة من التطبيقات لا تتشارك في البيانات والإعدادات نفسها، ننصحك بشدة بتسجيل كل تطبيق في مشروع Firebase مختلف.
على سبيل المثال، إذا كنت تطوّر تطبيقًا يحمل علامة تجارية مختلفة، يجب أن يكون لكل تطبيق يحمل علامة تجارية مختلفة مشروع Firebase خاص به، ويجب أن يكون كلّ من إصدارَي iOS وAndroid لهذه العلامة التجارية في مشروع Firebase نفسه. يجب ألا تتشارك التطبيقات التي تحمل علامات تجارية مختلفة بشكل مستقل في البيانات مع التطبيقات الأخرى (لأسباب تتعلّق بالخصوصية).
الخطوات التالية
راجِع إرشادات الأمان العامة للبيئات المختلفة. عليك التأكّد من أنّ كل بيئة وبياناتها آمنة.
راجِع قائمة التحقّق من الإطلاق في Firebase.