查看 2022 年 Google I/O 大会上介绍的 Firebase 新动态。了解详情

أفضل الممارسات العامة لإعداد مشاريع Firebase

توفر هذه الصفحة أفضل الممارسات العامة عالية المستوى لإعداد مشاريع Firebase وتسجيل تطبيقاتك في مشروع حتى يكون لديك سير عمل تطوير واضح باستخدام بيئات متميزة. بمجرد أن تتعرف على أفضل الممارسات على هذه الصفحة ، تحقق من إرشادات الأمان العامة الخاصة بنا.

فهم التسلسل الهرمي لمشاريع 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. يجب ألا يشارك كل تطبيق مصنف بشكل مستقل (لأسباب تتعلق بالخصوصية) البيانات مع الآخرين.

الخطوات التالية