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