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