It’s #FrontendFriday – Cloud Firestore & Cloud Storage & Realtime Database

Zu Beginn kurz, warum die Firebase-Speicherlösungen so interessant sind:

• Serverless architecture: Wir benötigen keine eigenen Server, müssen kein eigenes Backend schreiben. Unsere Anwendung spricht direkt mit der Datenbank (oder anderen Firebase Lösungen)
• Real-Time Data Syncing: Daten können innerhalb von Millisekunden an eigene oder, je nach Anwendungsfall, auch an weitere Geräte synchronisiert werden
• Offline cache: Sollte man Internetzugriff verlieren, so cached das SDK die Daten lokal und synchronisiert sie beim Wiederherstellen der Verbindung wieder
• Firebase ecosystem:  Normalerweise würde man Datenbank A nutzen, als Backend Lösung B, die Authentifizierung mit C abbilden, usw. und dies alles miteinander integrieren. Firebase bietet hier alles aus einer Hand an, was es viel einfacher macht

Speichermöglichkeiten

Firebase bietet drei Lösungen an:

• Cloud Firestore [1]: Cloud NoSQL database
• Realtime database [2]: Cloud NoSQL database
• Cloud Storage for Firebase [3]: Cloud object storage

Welche wir davon für unseren Einsatzzweck nutzen sollen, betrachten wir in den folgenden Kapiteln.

Was wollen wir speichern?

Um zu entscheiden, welche Speicherlösung wir wählen, müssen wir wissen, was wir speichern möchten.

• Nutzer generierte Dateien wie Audio, Video, Bilder
  • Hierfür nutzen wir den Cloud Storage for Firebase
• Daten, die sich in einer JSON-Struktur abbilden lassen
  • Hier kann der Cloud Firestore wie auch die Realtime database genutzt werden

Cloud Firestore vs. Realtime database

Welche der beiden Möglichkeiten wir nutzen sollen, hängt von einigen Kriterien ab. Eine Auswahl davon ist:

• Zugriff auf die Daten hauptsächlich lesend oder schreibend?
• Wie groß muss ich skalieren können?
• Welche Verfügbarkeit muss die Datenbank haben?
• Wie komplex ist mein Datenmodell?

Um hier eine Entscheidung zu treffen, bietet Firebase eine Hilfe an, die basierend auf einigen Fragen, die passende Datenbank findet: „Cloud Firestore or Realtime Database“ [4]. Sollte hier keine große Abhängigkeit zu einer Lösung offensichtlich werden, können die unterschiedlichen Preismodelle noch ein Faktor sein.

Sicherheit

Wir haben bisher über das Speichern von Daten gesprochen, aber wie schaut es mit der Absicherung des Zugriffs von unberechtigten Personen aus? Normalerweise müsste hier ein Backend den Zugriff auf die Datenbank absichern und nur Daten anbieten, für die der Nutzer berechtigt ist. Eine Absicherung auf Client Seite ist nicht zielführend, da dieser manipuliert werden könnte (never trust the client).

Das Backend stellt hier die Speicherlösung selbst dar, die mit Firebase Security Rules abgesichert werden kann. Diese unterstützen alle Firebase Speicherlösungen. Die Syntax und Möglichkeiten der Zugriffsbeschränkung hängt hier im Detail aber von der genutzten Speicherlösung ab.

Seid gespannt auf den nächsten Blogpost zum Thema Firebase.

Hier gehts zum vorherigen Blogpost

Links