Allgemeine Best Practices zum Einrichten von Firebase-Projekten

Diese Seite bietet allgemeine Best Practices auf hoher Ebene zum Einrichten von Firebase-Projekten und zum Registrieren Ihrer Apps bei einem Projekt, sodass Sie einen klaren Entwicklungsworkflow haben, der unterschiedliche Umgebungen verwendet. Wenn Sie sich mit den Best Practices auf dieser Seite vertraut gemacht haben, sehen Sie sich unsere allgemeinen Sicherheitsrichtlinien an .

Verstehen der Hierarchie von Firebase-Projekten

Diagramm, das die grundlegende Hierarchie eines Firebase-Projekts zeigt, einschließlich des Projekts, seiner registrierten Apps und seiner bereitgestellten Ressourcen und Dienste Dieses Diagramm zeigt die grundlegende Hierarchie eines Firebase-Projekts. Hier sind die wichtigsten Beziehungen:

  • Ein Firebase-Projekt ist wie ein Container für alle Ihre Apps und alle Ressourcen und Dienste, die für das Projekt bereitgestellt werden.

  • Für ein Firebase-Projekt können eine oder mehrere Firebase-Apps registriert sein (z. B. sowohl die iOS- als auch die Android-Version einer App oder sowohl die kostenlose als auch die kostenpflichtige Version einer App).

  • Alle Firebase-Apps, die bei derselben Firebase-Projektfreigabe registriert sind, haben Zugriff auf dieselben Ressourcen und Dienste, die für das Projekt bereitgestellt werden . Hier sind einige Beispiele:

    • Alle im selben Firebase-Projekt registrierten Firebase-Apps nutzen dieselben Backends wie Firebase-Hosting, Authentifizierung, Echtzeitdatenbank, Cloud Firestore, Cloud-Speicher und Cloud-Funktionen.

    • Alle im selben Firebase-Projekt registrierten Firebase-Apps sind mit derselben Google Analytics-Property verknüpft, wobei jede Firebase-App ein separater Datenstrom in dieser Property ist.

Wie passt ein Google Cloud-Projekt in diese Hierarchie?

Ein Aspekt der Firebase-Projekthierarchie, der im obigen Diagramm nicht dargestellt ist, ist die Beziehung zu einem Google Cloud-Projekt. Ein Firebase-Projekt ist eigentlich nur ein Google Cloud-Projekt, für das zusätzliche Firebase-spezifische Konfigurationen und Dienste aktiviert sind. Beachten Sie, dass alle Apps, die für dasselbe Firebase-Projekt registriert sind, auch dieselben Google Cloud-Ressourcen und -Dienste gemeinsam nutzen und darauf zugreifen können.

Erfahren Sie mehr über die Beziehung zwischen Firebase und Google Cloud unter Firebase-Projekte verstehen

Registrieren von App-Varianten bei Firebase-Projekten

Hier sind einige wichtige Tipps zum Registrieren Ihrer App-Varianten bei einem Firebase-Projekt:

  • Stellen Sie sicher, dass alle in einem Firebase-Projekt registrierten Apps aus Sicht des Endbenutzers Plattformvarianten derselben Anwendung sind. Registrieren Sie die iOS-, Android- und Webversionen derselben App oder desselben Spiels mit demselben Firebase-Projekt.

  • Wenn Sie mehrere Build-Varianten haben, die dieselben Firebase-Ressourcen gemeinsam nutzen könnten , registrieren Sie die Varianten bei demselben Firebase-Projekt. Einige Beispiele sind ein Blog und eine Web-App im selben Projekt oder sowohl die kostenlose als auch die kostenpflichtige Version derselben App im selben Projekt.

  • Wenn Sie mehrere Build-Varianten haben, die auf dem Release-Status basieren (und nicht wie oben auf gemeinsamen Endbenutzeraktivitäten oder -zugriffen), registrieren Sie jede Variante bei einem separaten Firebase-Projekt. Ein Beispiel ist Ihr Debug- vs. Release-Build – registrieren Sie jeden dieser Builds in seinem eigenen Firebase-Projekt.

    • Builds, die auf dem Release-Status basieren, sollten nicht dieselben Firebase-Ressourcen gemeinsam nutzen, da dies das Risiko birgt, dass Ihre Debug-Daten Ihre Produktdaten verschmutzen oder sogar überschreiben.

    • Die Plattformvarianten jeder dieser Build-Varianten sollten sich im selben Firebase-Projekt befinden. Registrieren Sie beispielsweise sowohl die iOS- als auch die Android-Debug-Builds in einem „dev“-Firebase-Projekt, da sie beide mit denselben Nicht-Prod-Daten und -Ressourcen interagieren können.

Vermeidung von Mandantenfähigkeit

Mandantenfähigkeit kann zu ernsthaften Konfigurations- und Datenschutzbedenken führen, einschließlich unbeabsichtigter Probleme mit der Analyseaggregation, gemeinsamer Authentifizierung, übermäßig komplexen Datenbankstrukturen und Schwierigkeiten mit Sicherheitsregeln.

Wenn eine Reihe von Apps nicht dieselben Daten und Konfigurationen gemeinsam nutzen, sollten Sie im Allgemeinen dringend erwägen, jede App bei einem anderen Firebase-Projekt zu registrieren.

Wenn Sie beispielsweise eine White-Label-Anwendung entwickeln, sollte jede unabhängig gekennzeichnete App über ein eigenes Firebase-Projekt verfügen, und die iOS- und Android-Versionen dieser Bezeichnung sollten sich im selben Firebase-Projekt befinden. Jede unabhängig gekennzeichnete App sollte (aus Datenschutzgründen) keine Daten mit den anderen teilen.

Nächste Schritte