בדף הזה מפורטות שיטות מומלצות כלליות להגדרת פרויקטים ב-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.