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