設定 Firebase 專案的一般最佳做法

本頁提供設定 Firebase 專案和註冊應用程式的一般高階最佳做法，協助您建立明確的開發工作流程，並使用不同的環境。熟悉本頁的最佳做法後，請參閱一般安全性指南。

瞭解 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 專案中註冊的所有應用程式，從使用者的角度來看，都是同一應用程式的不同平台版本。在同一個 Firebase 專案中，註冊同一個應用程式或遊戲的 iOS、Android 和網頁版本。

  • 如果多個建構變化版本可以共用相同的 Firebase 資源，請使用相同 Firebase 專案註冊這些變化版本。例如，同一個專案中的網誌和網頁應用程式，或同一個專案中同一應用程式的免費版和付費版。

  • 如果您有多個建構變化版本，且這些版本是根據發布狀態 (而非上述的一般使用者活動或存取權) 區分，請為每個變化版本註冊獨立的 Firebase 專案。例如，偵錯版本和發布子版本，請在各自的 Firebase 專案中註冊這些版本。

    • 根據發布狀態建立的版本不應共用相同的 Firebase 資源，因為這可能會導致偵錯資料污染甚至覆寫正式版資料。

    • 這些建構變化版本的平台變化版本應位於同一個 Firebase 專案中。舉例來說，請在「dev」Firebase 專案中註冊 iOS 和 Android 偵錯版本，因為兩者都能與相同的非正式資料和資源互動。

避免多租戶

多租戶架構可能會導致嚴重的設定和資料隱私權疑慮，包括分析匯總、共用驗證、過於複雜的資料庫結構，以及安全性規則方面的非預期問題。

一般來說，如果一組應用程式不共用相同的資料和設定，強烈建議您為每個應用程式註冊不同的 Firebase 專案。

舉例來說，如果您開發白標應用程式，每個獨立標籤的應用程式都應有自己的 Firebase 專案，且該標籤的 iOS 和 Android 版本應位於同一個 Firebase 專案中。基於隱私權考量，每個獨立標籤的應用程式不應與其他應用程式共用資料。

後續步驟