Các phương pháp chung hay nhất để thiết lập dự án Firebase
Sử dụng bộ sưu tập để sắp xếp ngăn nắp các trang
Lưu và phân loại nội dung dựa trên lựa chọn ưu tiên của bạn.
Trang này cung cấp các phương pháp hay nhất chung, cấp cao để thiết lập dự án Firebase và đăng ký ứng dụng của bạn với một dự án để bạn có một quy trình phát triển rõ ràng sử dụng các môi trường riêng biệt. Khi bạn đã quen với các phương pháp hay nhất về giải pháp này
hãy xem
nguyên tắc bảo mật chung.
Tìm hiểu hệ phân cấp của các dự án Firebase
Sơ đồ này cho thấy hệ phân cấp cơ bản của một dự án Firebase. Sau đây là yếu tố quan trọng
mối quan hệ:
Dự án Firebase giống như một vùng chứa dành cho tất cả ứng dụng và tài nguyên của bạn
và dịch vụ được cung cấp cho dự án.
Một dự án Firebase có thể có một hoặc nhiều Ứng dụng Firebase được đăng ký (ví dụ: cả phiên bản iOS và Android của một ứng dụng hoặc cả phiên bản miễn phí và trả phí của một ứng dụng).
Tất cả các Ứng dụng Firebase đã đăng ký với cùng một dự án Firebase đều chia sẻ và có
quyền truy cập vào cùng một tài nguyên và dịch vụ được cung cấp cho dự án.
Sau đây là một số ví dụ:
Tất cả các Ứng dụng Firebase được đăng ký với cùng một dự án Firebase đều có chung
phần phụ trợ, như Firebase Hosting, Authentication, Realtime Database, Cloud Firestore,
Cloud Storage và Cloud Functions.
Tất cả Ứng dụng Firebase được đăng ký cho cùng một dự án Firebase đều được liên kết với cùng một tài sản Google Analytics, trong đó mỗi Ứng dụng Firebase là một luồng dữ liệu riêng biệt trong tài sản đó.
Dự án Google Cloud phù hợp với hệ phân cấp này ở đâu?
Một thành phần của hệ phân cấp dự án Firebase không xuất hiện trong biểu đồ
ở trên là mối quan hệ với một dự án Google Cloud. Một dự án Firebase
thực sự chỉ là một dự án Google Cloud có bổ sung dành riêng cho Firebase
các cấu hình và dịch vụ được bật cho nó.
Xin lưu ý rằng tất cả ứng dụng được đăng ký cho cùng một dự án Firebase cũng chia sẻ và có quyền truy cập vào tất cả tài nguyên và dịch vụ Google Cloud giống nhau.
Dưới đây là một số mẹo quan trọng để đăng ký biến thể ứng dụng của bạn bằng Firebase
dự án:
Đảm bảo rằng tất cả các ứng dụng đã đăng ký với dự án Firebase đều là biến thể nền tảng
của cùng một ứng dụng từ góc độ người dùng cuối. Đăng ký phiên bản iOS, Android và web của cùng một ứng dụng hoặc trò chơi bằng cùng một dự án Firebase.
Nếu bạn có nhiều biến thể bản dựng có thể dùng chung một Firebase
tài nguyên, hãy đăng ký các biến thể với cùng dự án Firebase. Một số ví dụ là blog và ứng dụng web trong cùng một dự án, hoặc cả phiên bản miễn phí và phiên bản trả phí của cùng một ứng dụng trong cùng một dự án.
Nếu bạn có nhiều biến thể bản dựng dựa trên trạng thái phát hành
(thay vì dựa trên hoạt động hoặc quyền truy cập thông thường của người dùng cuối như trên), hãy đăng ký
biến thể với một dự án Firebase riêng biệt. Ví dụ: gỡ lỗi của bạn và
bản phát hành – đăng ký từng bản dựng này trong dự án Firebase của riêng nó.
Các bản dựng dựa trên trạng thái phát hành không được có cùng tài nguyên Firebase
vì việc đó có nguy cơ làm hỏng dữ liệu gỡ lỗi
hoặc thậm chí ghi đè dữ liệu sản phẩm của bạn
.
Các biến thể nền tảng của từng biến thể bản dựng này phải nằm trong cùng một dự án Firebase. Ví dụ: đăng ký cả thiết bị iOS và Android
bản gỡ lỗi trong "nhà phát triển" dự án Firebase vì cả hai đều có thể tương tác với
dữ liệu và tài nguyên ngoài sản phẩm giống nhau.
Tránh mô hình đa khách hàng
Môi trường đa khách hàng có thể dẫn đến những mối lo ngại nghiêm trọng về cấu hình và quyền riêng tư đối với dữ liệu,
bao gồm các vấn đề không mong muốn với việc tổng hợp số liệu phân tích, xác thực dùng chung,
cấu trúc cơ sở dữ liệu quá phức tạp và khó khăn với các quy tắc bảo mật.
Nói chung, nếu một nhóm ứng dụng không chia sẻ cùng một dữ liệu và cấu hình,
hãy cân nhắc việc đăng ký mỗi ứng dụng bằng một dự án Firebase riêng.
Ví dụ: nếu bạn phát triển một ứng dụng nhãn trắng, thì mỗi ứng dụng được gắn nhãn độc lập phải có dự án Firebase riêng và các phiên bản iOS và Android của nhãn đó phải nằm trong cùng một dự án Firebase. Một
ứng dụng được gắn nhãn độc lập (vì lý do bảo mật) không được chia sẻ dữ liệu với
khác.
Các bước tiếp theo
Xem xét
nguyên tắc bảo mật chung
cho các môi trường khác nhau. Bạn muốn đảm bảo rằng mỗi môi trường và
đều được bảo mật.
[null,null,["Cập nhật lần gần đây nhất: 2025-07-25 UTC."],[],[],null,["This page provides general, high-level best practices for setting up Firebase\nprojects and registering your apps with a project so that you have a clear\n[development workflow](/docs/projects/dev-workflows/overview-environments) that\nuse distinct environments. Once you're familiar with the best practices on this\npage, check out our\n[general security guidelines](/docs/projects/dev-workflows/general-security-guidelines).\n| **Key Point:** We recommend reading our guides thoroughly, but here's the top takeaway about development workflows: \n| **Firebase recommends using a *separate* Firebase project for *each* environment\n| in your development workflow.**\n\nUnderstanding the hierarchy of Firebase projects\n\n\nThis diagram shows the basic hierarchy of a Firebase project. Here are the key\nrelationships:\n\n- A **Firebase project** is like a container for all your apps and any resources\n and services provisioned for the project.\n\n- A Firebase project can have one or more **Firebase Apps** registered to it\n (for example, both the iOS and Android versions of an app, or both the free\n and paid versions of an app).\n\n- All Firebase Apps registered to the same Firebase project **share and have\n access to all the same resources and services provisioned for the project**.\n Here are some examples:\n\n - All the Firebase Apps registered to the same Firebase project share the same\n backends, like Firebase Hosting, Authentication, Realtime Database, Cloud Firestore,\n Cloud Storage, and Cloud Functions.\n\n - All Firebase Apps registered to the same Firebase project are associated\n with the same Google Analytics property, where each Firebase App is a\n separate data stream in that property.\n\nWhere does a Google Cloud project fit into this hierarchy?\n\nOne aspect of the Firebase project hierarchy that's not shown in the diagram\nabove is the relationship with a Google Cloud project. **A Firebase project is\nactually just a Google Cloud project that has additional *Firebase-specific*\nconfigurations and services enabled for it.**\nNote that all the apps registered to the same Firebase project also share and\nhave access to all the same Google Cloud resources and services, too.\n\nLearn more about the Firebase and Google Cloud relationship in\n[Understand Firebase projects](/docs/projects/learn-more#firebase-cloud-relationship)\n\nRegistering app variants with Firebase projects **Key Point:** All the apps registered to a Firebase project share and can access the same data as well as the resources and services provisioned for the project, which includes database instances, storage buckets, functions, etc.\n\nHere are some important tips for registering your app variants with a Firebase\nproject:\n\n- Ensure that all apps registered to a Firebase project are **platform variants\n of the same application** from an end-user perspective. Register the iOS,\n Android, and web versions of the same app or game with the *same* Firebase\n project.\n\n- If you have **multiple build variants that could *share the same Firebase\n resources*** , register the variants with the *same* Firebase project. Some\n examples are a blog and a web app in the same project, or both the free and\n paid versions of the same app in the same project.\n\n- If you have **multiple build variants that are *based on release status***\n (rather than on common end-user activity or access, like above), register each\n variant with a *separate* Firebase project. An example is your debug vs\n release build -- register each of these builds in its own Firebase project.\n\n - Builds based on release status should not share the same Firebase resources\n because that risks your debug data polluting or even overriding your prod\n data.\n\n - The *platform* -variants of each of these build variants should be in the\n *same* Firebase project. For example, register both the iOS and the Android\n debug builds in a \"dev\" Firebase project because they can both interact with\n the same non-prod data and resources.\n\n| **Note:** For each Android app, if you provide a SHA-1 key for the app, you need to provide a package name and SHA-1 key combination that is globally unique across all of Google Cloud.\n\nAvoiding multi-tenancy **Key Point:** Connecting several different logically independent apps and/or web sites to a single Firebase project (often called \"multi-tenancy\") is not recommended.\n\nMulti-tenancy can lead to serious configuration and data privacy concerns,\nincluding unintended issues with analytics aggregation, shared authentication,\noverly-complex database structures, and difficulties with security rules.\n\nGenerally, **if a set of apps don't share the same data and configurations,\nstrongly consider registering each app with a different Firebase project.**\n\nFor example, if you develop a white-label application, each independently\nlabeled app should have its own Firebase project, and the iOS and Android\nversions of that label should be in the same Firebase project. Each\nindependently labeled app shouldn't (for privacy reasons) share data with the\nothers.\n\nNext steps\n\n- Review the\n [general security guidelines](/docs/projects/dev-workflows/general-security-guidelines)\n for different environments. You want to make sure each environment and its\n data are secure.\n\n- Review the [Firebase launch checklist](/support/guides/launch-checklist)."]]