Firebase projeleri oluşturmak için genel en iyi uygulamalar
Koleksiyonlar ile düzeninizi koruyun
İçeriği tercihlerinize göre kaydedin ve kategorilere ayırın.
Bu sayfada, Firebase'i ayarlamak için genel ve üst düzey en iyi uygulamalar yer almaktadır.
ve uygulamalarınızı bir projeye kaydettirmek
geliştirme iş akışını
farklı ortamlar kullanır. Bu konudaki en iyi uygulamaları öğrendiğinizde,
daha fazla bilgi edinmek için
genel güvenlik yönergelerine bakın.
Firebase projelerinin hiyerarşisini anlama
Bu şema, bir Firebase projesinin temel hiyerarşisini gösterir. Önemli adımlar
ilişkiler:
Firebase projesi tüm uygulamalarınız ve kaynaklarınız için bir kapsayıcı gibidir
hizmetleri kapsar.
Bir Firebase projesine kayıtlı bir veya daha fazla Firebase Uygulaması olabilir
(örneğin, bir uygulamanın hem iOS hem de Android sürümleri)
ya da hem ücretsiz hem de ücretsiz
bir uygulamanın ücretli sürümleri)
Aynı Firebase projesine kayıtlı tüm Firebase uygulamaları paylaşmak ve
proje için sağlanan tüm kaynak ve hizmetlere erişim
Aşağıda bazı örnekler verilmiştir:
Aynı Firebase projesine kayıtlı tüm Firebase uygulamaları aynı şeyi paylaşır.
Firebase Hosting, Authentication, Realtime Database, Cloud Firestore gibi arka uçlar
Cloud Storage ve Cloud Functions.
Aynı Firebase projesine kayıtlı tüm Firebase uygulamaları aynı Google Analytics mülküyle ilişkilendirilir. Bu mülkte her Firebase uygulaması ayrı bir veri akışıdır.
Google Cloud projesi bu hiyerarşide nerede yer alır?
Diyagramda gösterilmeyen, Firebase proje hiyerarşisinin bir yönü
yukarıdaki bir Google Cloud projesiyle ilişkidir. Firebase projeleri,
Aslında sadece Firebase'e özel ek içeren bir Google Cloud projesi
yapılandırmaları ve hizmetleri alabilirsiniz.
Aynı Firebase projesine kayıtlı tüm uygulamaların aynı zamanda
aynı Google Cloud kaynaklarına ve hizmetlerine de erişebilirler.
Firebase projelerini anlama başlıklı makalede Firebase ve Google Cloud ilişkisi hakkında daha fazla bilgi edinin.
Firebase projeleriyle uygulama varyantlarını kaydetme
Uygulama varyantlarınızı Firebase'e kaydettirmeyle ilgili bazı önemli ipuçlarını aşağıda bulabilirsiniz
proje:
Bir Firebase projesine kaydedilen tüm uygulamaların platform varyantı olduğundan emin olun
(ör. son kullanıcı bakış açısıyla) iOS'i kaydedin,
Aynı uygulama veya oyunun aynı Firebase ile Android ve web sürümleri
belirler.
Aynı Firebase kaynaklarını paylaşabilecek birden fazla derleme varyantınız varsa varyantları aynı Firebase projesine kaydedin. Biraz
aynı projede bir blog ve web uygulaması ya da hem ücretsiz hem de
aynı projede aynı uygulamanın ücretli sürümlerini kullanabilirsiniz.
Sürüm durumuna (yukarıdaki gibi ortak son kullanıcı etkinliği veya erişimine göre değil) dayalı birden fazla derleme varyantınız varsa her varyantı ayrı bir Firebase projesine kaydedin. Hata ayıklama ve yayın derlemeniz buna örnek gösterilebilir. Bu derlemelerin her birini kendi Firebase projesine kaydedin.
Sürüm durumuna dayalı derlemeler aynı Firebase kaynaklarını paylaşmamalıdır
Çünkü hata ayıklama verilerinizin kirlenmesine ve hatta ürününüzü geçersiz kılmasına
dışı verilerdir.
Bu derleme varyantlarının her birinin platform varyantları aynı Firebase projesinde olmalıdır. Örneğin, hem iOS hem de Android'i
"dev" içindeki hata ayıklama derlemeleri çünkü iki kullanıcı da etkileşime geçebildiğinden
aynı üretim dışı verileri ve kaynakları içerir.
Çok kiracılı yapıdan kaçınma
Çok kiracılı yapı, yapılandırma ve veri gizliliği konusunda ciddi sorunlara yol açabilir.
analiz toplama, paylaşılan kimlik doğrulama ve
ve güvenlik kurallarıyla ilgili zorluklar üzerine
çalışmak için kullanır.
Genel olarak, bir grup uygulama aynı verileri ve yapılandırmaları paylaşmıyorsa her uygulamayı farklı bir Firebase projesine kaydetmenizi önemle tavsiye ederiz.
Örneğin, beyaz etiketli bir uygulama geliştirirseniz bağımsız olarak etiketlenen her uygulamanın kendi Firebase projesi olmalıdır ve bu etiketin iOS ve Android sürümleri aynı Firebase projesinde olmalıdır. Bağımsız olarak etiketlenen her uygulama, gizlilik nedeniyle diğer uygulamalarla veri paylaşmamalıdır.
Sonraki adımlar
Şu göz atın:
genel güvenlik yönergelerini
farklı ortamlar için kullanılabilir. Her bir ortamın ve bu ortamın
emin olmanız gerekir.
[null,null,["Son güncelleme tarihi: 2025-07-25 UTC."],[],[],null,["# General best practices for setting up Firebase projects\n\nThis 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\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\n### Where 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\n-----------------------------------------------\n\n| **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\n### Avoiding multi-tenancy\n\n| **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\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)."]]
Bu şema, bir Firebase projesinin temel hiyerarşisini gösterir. Önemli adımlar
ilişkiler: