تقدّم هذه الصفحة أفضل الممارسات العامة والعالية المستوى لإعداد مشاريع 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 نفسه. يجب ألا تتشارك التطبيقات التي تحمل علامات تجارية بشكل مستقل البيانات مع التطبيقات الأخرى (لأسباب تتعلّق بالخصوصية).
الخطوات التالية
راجِع إرشادات الأمان العامة للبيئات المختلفة. عليك التأكّد من أنّ كل بيئة وبياناتها آمنة.
راجِع قائمة التحقّق من الإطلاق في Firebase.