בדף הזה מפורטות שיטות מומלצות כלליות להגדרת פרויקטים ב-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 Analytics, כאשר כל אפליקציה ב-Firebase היא מקור נתונים נפרד באותו נכס.
איפה פרויקט Google Cloud משתלב בהיררכיה הזו?
היבט אחד של היררכיית הפרויקטים ב-Firebase שלא מוצג בתרשים שלמעלה הוא הקשר עם פרויקט Google Cloud. פרויקט Firebase הוא למעשה פרויקט Google Cloud עם הגדרות נוספות שספציפיות ל-Firebase ושירותים שמופעלים בו. חשוב לציין שכל האפליקציות שרשומות לאותו פרויקט ב-Firebase חולקות גישה לאותם Google Cloud משאבים ושירותים.
מידע נוסף על הקשר בין Firebase ו-Google Cloud זמין במאמר הסבר על פרויקטים ב-Firebase
רישום של וריאציות של אפליקציות בפרויקטים של Firebase
ריכזנו כאן כמה טיפים חשובים לרישום של וריאציות של האפליקציה בפרויקט Firebase:
חשוב לוודא שכל האפליקציות שרשומות בפרויקט Firebase הן גרסאות של אותה אפליקציה לפלטפורמות שונות מנקודת המבט של משתמש הקצה. צריך לרשום את הגרסאות ל-iOS, ל-Android ולאינטרנט של אותה אפליקציה או משחק באותו פרויקט Firebase.
אם יש לכם כמה וריאציות של build שיכולות לחלוק את אותם משאבי Firebase, רשמו את הווריאציות באותו פרויקט Firebase . למשל, בלוג ואפליקציית אינטרנט באותו פרויקט, או הגרסה החינמית והגרסה בתשלום של אותה אפליקציה באותו פרויקט.
אם יש לכם כמה וריאציות של גרסאות build שמבוססות על סטטוס ההפצה (ולא על פעילות או גישה נפוצות של משתמשי קצה, כמו בדוגמה שלמעלה), צריך לרשום כל וריאציה בפרויקט Firebase נפרד. לדוגמה, גרסת הניפוי באגים לעומת גרסת build להפצה – כדאי לרשום כל אחת מהגרסאות האלה בפרויקט Firebase משלה.
גרסאות build שמבוססות על סטטוס ההפצה לא צריכות לשתף את אותם משאבי Firebase, כי יש סיכון שהנתונים לניפוי באגים יזהמו את נתוני הייצור או אפילו יחליפו אותם.
הווריאציות של כל אחת מהווריאציות האלה של הגרסה צריכות להיות באותו פרויקט Firebase. לדוגמה, כדאי לרשום את גרסאות הניפוי באגים של iOS ו-Android בפרויקט Firebase 'פיתוח', כי שתיהן יכולות ליצור אינטראקציה עם אותם נתונים ומשאבים שאינם נתוני ייצור.
הימנעות מריבוי דיירים
ריבוי דיירים עלול להוביל לבעיות חמורות בהגדרות ובפרטיות הנתונים, כולל בעיות לא מכוונות בצבירת נתונים של ניתוח, אימות משותף, מבני מסדי נתונים מורכבים מדי וקשיים בכללי אבטחה.
באופן כללי, אם קבוצת אפליקציות לא משתפת את אותם נתונים ואותן הגדרות, מומלץ מאוד לרשום כל אפליקציה בפרויקט Firebase אחר.
לדוגמה, אם אתם מפתחים אפליקציה עם מיתוג של צד שלישי, לכל אפליקציה עם מיתוג עצמאי צריך להיות פרויקט Firebase משלה, והגרסאות ל-iOS ול-Android של אותו מיתוג צריכות להיות באותו פרויקט Firebase. כל אפליקציה עם תווית נפרדת לא אמורה (מסיבות שקשורות לפרטיות) לשתף נתונים עם אפליקציות אחרות.
השלבים הבאים
כדאי לעיין בהנחיות האבטחה הכלליות לסביבות שונות. חשוב לוודא שכל סביבה והנתונים שלה מאובטחים.
כדאי לעיין ברשימת המשימות להשקה ב-Firebase.