تقدّم هذه الصفحة أفضل الممارسات العامة وعالية المستوى لإعداد مشاريع 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
مزيد من المعلومات عن العلاقة بين Firebase وGoogle Cloud في مقالة التعرّف على مشاريع Firebase
تسجيل أشكال التطبيقات المختلفة في مشاريع Firebase
في ما يلي بعض النصائح المهمة لتسجيل أشكال التطبيقات المختلفة في مشروع Firebase:
تأكَّد من أنّ جميع التطبيقات المسجّلة في مشروع Firebase هي أشكال مختلفة من المنصات للتطبيق نفسه من منظور المستخدم النهائي. سجِّل إصدارات iOS وAndroid والويب من التطبيق أو اللعبة نفسها في مشروع Firebase نفسه.
إذا كان لديك أشكال متعدّدة من الإصدارات يمكنها مشاركة موارد Firebase نفسها، سجِّل الأشكال في مشروع Firebase نفسه. بعض الأمثلة هي مدونة وتطبيق ويب في المشروع نفسه، أو كلّ من الإصدارَين المجاني والمدفوع من التطبيق نفسه في المشروع نفسه.
إذا كان لديك أشكال متعدّدة من الإصدارات تستند إلى حالة الإصدار (بدلاً من استنادها إلى نشاط المستخدم النهائي أو وصوله الشائع، كما هو موضّح أعلاه)، سجِّل كل شكل في مشروع Firebase منفصل. أحد الأمثلة هو بنية تصحيح الأخطاء مقابل بنية الإصدار، لذا سجِّل كل بنية من هاتَين البنيتَين في مشروع Firebase خاص به.
يجب عدم مشاركة الإصدارات المستندة إلى حالة الإصدار لموارد Firebase نفسها لأنّ ذلك يعرّض بيانات التصحيح لخطر إفساد بيانات الإنتاج أو حتى استبدالها.
يجب أن تكون أشكال المنصات المختلفة لكل شكل من أشكال الإصدار هذه في مشروع Firebase نفسه. على سبيل المثال، سجِّل كلّ من إصدارَي التصحيح على iOS وAndroid في مشروع Firebase "للتطوير" لأنّهما يستطيعان التفاعل مع البيانات والموارد غير الخاصة بالإنتاج نفسها.
تجنُّب استخدام مشاريع متعددة المستأجرين
يمكن أن يؤدي استخدام مشاريع متعددة المستأجرين إلى مشاكل خطيرة في الإعداد وخصوصية البيانات، بما في ذلك مشاكل غير مقصودة في تجميع الإحصاءات والمصادقة المشتركة وهياكل قواعد البيانات المعقّدة للغاية والصعوبات في قواعد الأمان.
بشكل عام، إذا كانت مجموعة من التطبيقات لا تتشارك البيانات والإعدادات نفسها، ننصحك بشدة بتسجيل كل تطبيق في مشروع Firebase مختلف.
على سبيل المثال، إذا كنت تطوّر تطبيقًا يحمل علامة تجارية مختلفة، يجب أن يكون لكل تطبيق يحمل علامة تجارية مختلفة مشروع Firebase خاص به، ويجب أن يكون كلّ من إصدارَي iOS وAndroid لتلك العلامة التجارية في مشروع Firebase نفسه. يجب ألا تتشارك كل التطبيقات التي تحمل علامة تجارية مختلفة البيانات مع التطبيقات الأخرى (لأسباب تتعلّق بالخصوصية).
الخطوات التالية
راجِع إرشادات الأمان العامة للبيئات المختلفة. عليك التأكّد من أنّ كل بيئة وبياناتها آمنة.