Teil 3: Datenspeicherung mit Realtime Database und Firestore

Firebase – die Power aus dem Hintergrund

Dr. Veikko Krypczyk, Olena Bochkor

© vectorfusionart/Shutterstock.com

Fast keine App kommt ohne Daten aus. Statt diese lokal auf dem Client zu speichern oder sie auf einem schwergewichtigen SQL Server abzulegen, kommen Clouddienste zum Einsatz. Firebase ermöglicht als leistungsfähiges Backend die Speicherung von Daten mit unterschiedlichen Diensten. Meist genügen etwas Konfigurationsarbeit und die Anpassung des Referenzcodes aus Beispielen. Ein Überblick über die Datenwelt von Firebase und Co.

In dieser Artikelserie geben wir einen Überblick über die Dienste und Leistungen von Firebase als Cloud- und Back­end-Dienst von Google. Nach einem Streifzug durch alle angebotenen Services (Teil 1) und die Funktionen zur Nutzerauthentifizierung (Teil 2) geht es nun um die Kernfunktion der Datenspeicherung.

Artikelserie

Kaum eine App kommt ohne die Speicherung von Daten aus. Für die lokale Zwischenspeicherung oder auch für Nutzungsszenarien ohne einen Austausch der Daten mit anderen Geräten und Nutzern kann eine lokale Datenbank eingesetzt werden. Die Daten werden in diesem Fall lokal auf dem Client, d. h. direkt im Speicher des Smartphones oder Tablets gespeichert. Häufig wird dazu die Datenbank SQLite eingesetzt. SQLite ist eine kleinere, eigenständige und zuverlässige Datenbank. Die zugehörigen Bibliotheken werden in der Programmiersprache C geschrieben. Die Inter­aktion zwischen den Anwendungsprogrammen und der Datenbank erfolgt auf der Basis eines SQL-Dialekts. SQLite ist eine eingebettete Datenbank und wird direkt auf den Geräten, oft mobile Devices, verwendet. Das SQLite-Dateiformat ist stabil, plattformübergreifend und abwärtskompatibel. Die Entwickler der Datenbank haben sich verpflichtet, dieses Format bis mindestens 2050 beizubehalten. Der Code der Datenbank ist Public-Domain und steht zur freien Nutzung bereit. Die Nutzung von SQLite in Apps, zum Beispiel für ­Android, bietet die folgenden Vorteile:

  • Es ist kein unabhängiger Datenbankserver notwendig, d. h. Client und Server (Datenbank) laufen im gleichen Prozess.
  • SQLite steht zur freien Nutzung zur Verfügung. Mit der Einbindung sind keine Einschränkungen bezüglich der Lizenzbestimmungen für die eigene App verbunden.
  • Da SQLite plattformübergreifend funktioniert, kann es auch für einen sehr einfachen Datenaustausch verwendet werden.

Wie man SQLite in Android (Java, Kotlin) einsetzt, wird zum Beispiel in der Android-Developer-Dokumentation unter beschrieben. Über die Klassen des Packages android.database.sqlite erhält man einen Low-Level-Zugriff auf die eingebettete Datenbank und kann dann mit dieser arbeiten, d. h. Daten lesen, schreiben, löschen usw.

Möchte man die Daten jedoch zwischen Geräten und Nutzern teilen, muss man sie auf einem Server ablegen. Dazu bieten sich die Dienste von Firebase an, die wir gleich ausführlicher vorstellen. In vielen Szenarien ist es notwendig, sowohl Daten offline als auch online zu speichern und bei Verfügbarkeit einer Internetverbindung zu synchronisieren. Dazu bietet Firebase mit dem Produkt Firestore einen eigenen Modus, um die Daten für die Zeit ohne Netzwerkzugriff offline zu cachen.

Datenspeicherung mit Google

Google bietet inzwischen eine umfassende Palette an cloudbasierten Datenbankdiensten (Abb. 1). Diese Produkte umfassen eine breite Auswahl an verwalteten Datenbanken (relationale Datenbanken und NoSQL-Datenbanken). Die Angebote sind auf den Enterprise-Markt ausgerichtet und kommen für die Nutzung in mobilen Apps nur bedingt in Frage. Einen kompakten Überblick gibt Tabelle 1. Wir können diese Dienste dann von den nachfolgend im Detail vorgestellten Database Services von Firebase unterscheiden.

Abb. 1: Übersicht über die Cloud-Storage-Produkte von Google

 

Cloud-Storage-­Produkt von Google Beschreibung Anwendung
Persistent Disk vollständig verwalteter Blockspeicher, der sich für virtuelle Maschinen und Container eignet Snapshots für Datensicherungen, Laufwerke für virtuelle Maschinen, Freigabe schreibgeschützter Daten auf mehreren virtuellen Maschinen
Cloud Storage skalierbarer, vollständig verwalteter Objekt-/Blob-Speicher Bilder, Videos, Objekte und Blobs (unstrukturierte Daten)
Cloud Bigtable skalierbare, vollständig verwaltete, spalten­orientierte NoSQL-Datenbank, die sich sowohl für zentrale Suchanfragen mit geringer Latenz als auch für vorab berechnete Analysen eignet Lese-/Schreibzugriff mit geringer Latenz, Datenverarbeitung mit hohem Durchsatz, Zeitachsenunterstützung
Cloud Datastore skalierbare, vollständig verwaltete NoSQL-Dokumentendatenbank für Web- und Mobilanwendungen semistrukturierte Anwendungsdaten, hierarchische Daten, langlebige Schlüssel-/Wert-Paare
Cloud SQL vollständig verwalteter MySQL- und PostgreSQL-Datenbankdienst Web-Frameworks, strukturierte Daten
OLTP-Arbeitslasten (Online Transaction Processing), zum Beispiel für Websites, Blogs und Content-Management-Systeme (CMS)
BI-(Business-Intelligence-)Anwendungen, Anwendungen für ERP (Enterprise Resource Planning), CRM (Customer Relationship Management) und E-Commerce
Cloud Spanner relationaler Datenbankdienst mit transaktionaler Konsistenz geschäftskritische Anwendungen, hohe Transaktionsgeschwindigkeiten, Skalierungs- und Konsistenzanforderungen, zum Beispiel für Anwendungen im Einzelhandel
BigQuery skalierbares, vollständig verwaltetes Enterprise Data Warehouse (EDW) mit SQL und schnellen Ad-hoc-Abfragen OLAP-Arbeitslasten im Petabytebereich, Verarbeitung von Big Data, Berichterstattung mit BI-Tools, geeignet für Analyseberichte zu großen Datenmengen, Data Science und erweiterte Analysen, Big-Data-Verarbeitung mit SQL
Drive Enterprise gemeinschaftlicher Bereich zum Speichern, Freigeben und Bearbeiten von Dateien Interaktion von Endnutzern mit Dokumenten und Dateien, gemeinschaftliches Erstellen und Bearbeiten, Synchronisieren von Dateien zwischen Cloud und lokalen Geräten, zum Beispiel geeignet für einen ortsunabhängigen Zugriff auf Dateien über das Web, Anwendungen und Synchronisierungsclients
Produkte von Firebase für mobile Anwendungen
Cloud Storage für Firebase mobiler Zugriff und Webzugriff auf Cloud Storage über eine serverlose Authentifizierung und Autorisierung durch Drittanbieter Bilder, Videos, Objekte und Blobs (unstrukturierte Daten)
Firebase Realtime Database NoSQL-JSON-Echtzeitdatenbank für Web- und Mobilanwendungen Mobil- und Webanwendungen, Echtzeitdatenaustausch
Firebase Hosting Hosting von Web- und Mobilinhalten Landing Pages, umfangreiche JavaScript-Clientanwendungen, statische Websites
Cloud Firestore für Firebase NoSQL-Datenbank für Dokumente, für das Speichern, Synchronisieren und Abfragen von Daten für Mobil- und Webanwendungen Mobil- und Webanwendungen
Livesynchronisierung, offline nutzbar, serverlose Anwendungen

Tabelle 1: Cloud-Storage-Produkte von Google

Den richtigen Cloudspeicherdienst auszuwählen, ist gar nicht so einfach. Damit man im Dschungel der Angebote durchblickt, gibt es eine Entscheidungshilfe in Form eines Flussdiagramms von Google (Abb. 2).

Abb. 2: Entscheidungshilfe für den richtigen cloudbasierten Datenbankdienst

Wesentliche Trennungsmerkmale, die im Entscheidungsbaum dargestellt werden, sind die Eigenschaften „strukturierte Daten“ versus „unstrukturierte Daten“. Für unstrukturierte Daten werden bevorzugt NoSQL-Datenspeicher verwendet. Diese unterscheiden sich im Aufbau und der Nutzung von relationalen Datenbanken (Kasten „Relationale Datenbank vs. NoSQL-Datenbank“).

Relationale Datenbank vs. NoSQL-DatenbankDer Ort, an dem die Daten gesammelt werden, wird als Datenbank bezeichnet. In welcher Form die Daten in der Datenbank abgelegt werden, muss definiert und beschrieben werden (Metadaten). Eine relationale Datenbank ist eine auf Tabellen basierende Datenbank, die auf dem relationalen Datenbankmodell beruht. Das bedeutet, dass die Daten einer Tabelle mit einem eindeutigen Schlüssel (Primärschlüssel) ausgestattet sind. Die Beziehungen zwischen den Tabellen wird über die Kombination Primär- und Fremdschlüssel hergestellt. Die Abfragesprache der Datenbank ist meist SQL. Trotz unterschiedlicher SQL-Dialekte ist die Syntax zwischen den Datenbanksystemen ähnlich. Eine relationale Datenbank ist die am meisten genutzte Datenbank im Umfeld von Geschäftsanwendungen. Der Grund: Viele typische Datenszenarien lassen sich gut durch eine Datenstruktur in Tabellenform abbilden.

Dennoch können nicht alle Anforderungen der Datenspeicherung gut durch relationale Datenbanken gelöst werden. Steht die Struktur der Daten nicht von Beginn an fest oder möchte man vermehrt auch unstrukturierte Daten, zum Beispiel Dokumente, ablegen, dann sind sogenannte NoSQL-Datenbanken oft der bessere Weg. NoSQL-Datenbanken arbeiten weitgehend ohne Schema und meist dokumentenbasiert, d. h. alle Informationen werden in Dokumenten gespeichert. NoSQL ist als „Not only SQL“ zu verstehen. In NoSQL-Datenbanken werden die Daten nicht in Tabellen gespeichert. Sie werden stattdessen in Key-Value-Paare eingeteilt. Das bedeutet, dass der Datensatz aus einem Key und einem Value besteht. Die Keys sind eindeutig. Man kann sie mit den Primärschlüsseln in relationalen Datenbanken vergleichen.

Ein weiteres wichtiges Kriterium ergibt sich aus der clientseitigen Verwendung des Speicherdiensts. Sofern man ihn aus einer Anwendung für die mobilen Geräte verwendet, wird er in der Regel mit Hilfe eines SDKs angesprochen. Gegenüber einer generischen Schnittstelle reduziert ein SDK die Arbeit für den Speicherdienst erheblich. Statt umfassender allgemeiner Datenbankabfragen können Standardanforderungen an die Datenbank, wie Lesen, Schreiben und Löschen, mit Hilfe von Methoden aus Klassen erledigt werden. Die Speicherdienste für den Einsatz auf mobilen Geräten werden unter den Services von Firebase von Google zusammengefasst. Wir wollen uns deshalb jetzt näher mit Firebase Realtime Database und Cloud Firestore for Firebase beschäftigen.

Datenspeicherung mit Firebase

Die Firebase Realtime Database ist eine in der Cloud gehostete Datenbank und über das Dashboard von Fire­base zu erreichen und zu administrieren. Die Daten werden als JSON gespeichert und in Echtzeit mit jedem verbundenen Client synchronisiert. Bei plattformübergreifenden Apps, die mit iOS-, Android- und JavaScript-SDKs erstellt sind, wird eine Instanz einer Echtzeitdatenbank gemeinsam von allen Clients genutzt. Auf diese Weise erhalten alle Clients automatisch die Updates auf den neuesten Stand der Daten. Der Zugriff auf die Datenbank wird direkt über clientseitigen Code ermöglicht. Die Daten werden auch lokal gespeichert, damit ist eine Offlineverarbeitung möglich. Wenn das betreffende Gerät die Verbindung wiederherstellt, synchronisiert die Echtzeitdatenbank die lokalen Datenänderungen mit den Remote-­Aktualisierungen, die stattgefunden haben, während der Client offline war. Mögliche Datenkonflikte werden automatisch aufgelöst. Mit Hilfe der Firebase Realtime Database Security Rules legt man fest, wie die Daten strukturiert werden. Bei der Integration in die Firebase-Authentifizierung können Entwickler bestimmen, wer auf welche Daten zugreifen darf. Die Implementierung läuft nach den folgenden Schritten ab:

  1. Erstellen Sie die Realtime Database References
  2. Stellen Sie die Daten bereit
  3. Aktivieren Sie Offline Persistence
  4. Sichern Sie Ihre Daten

Die Realtime Database ist die ursprüngliche Datenbank von Firebase. Es handelt sich um eine effiziente Lösung mit geringer Latenz für mobile Apps. Der Speicherdienst Cloud Firestore ist die neue Datenbank für die Entwicklung mobiler Apps. Technisch basiert sie auf einem neuen Datenmodell. Cloud Firestore bietet außerdem umfangreichere, schnellere Abfragen und skaliert besser als die Realtime Database. Sowohl Realtime Database als auch Cloud Firestore sind jeweils NoSQL-Datenbanken. Tabelle 2 stellt Realtime Database und Cloud Firestore einander gegenüber.

Realtime Database Cloud Firestore
Datenmodell speichert Daten als einen großen JSON-Baum speichert Daten in Dokumenten, die in Sammlungen organisiert sind
Realtime- und Offline­support Offlineunterstützung für mobile Clients nur für iOS und Android verfügbar über das SDK Offlineunterstützung für iOS-, Android- und Webclients
Abfragen Abfragen mit eingeschränkter Sortier- und Filterfunktionalität indizierte Abfragen mit Sortier- und Filterfunktion
Schreiben und ­Transaktionen grundlegende Schreib- und Transaktionsvorgänge erweiterte Schreib- und Transaktionsoperationen
Skalierbarkeit skaliert nicht automatisch skaliert automatisch
Sicherheit Realtime Database Rules sind die einzige Sicherheitsoption Mobile und Web SDKs verwenden Cloud Firestore Security Rules, Server SDKs verwenden Identity and Access Management (IAM)
Preise Gebühren nur für Bandbreite und Speicher in erster Linie fallen Gebühren für Vorgänge an, die in der Datenbank ausgeführt werden (Lesen, Schreiben, Löschen), und in geringerem Maße für Bandbreite und Speicherplatz

Tabelle 2: Gegenüberstellung von Realtime Database und Cloud Firestore

Für den Einsatz in der Praxis ergibt sich daher, dass man beide Datenspeicherdienste für viele Anforderungen einsetzen kann. Google empfiehlt in der Dokumentation, für neue Projekte Cloud Firestore einzusetzen. Es handelt sich um den neueren technischen Ansatz, der besser skaliert und mehr Konfigurationsoptionen bietet. Eine zwingende Migration von Projekten mit Realtime Database auf Cloud Firestore ist im Moment jedoch nicht notwendig oder gar zwingend.

Das Datenmodell von Firestore

Eine NoSQL-Datenbank sieht – wie bereits ausgeführt – keine Speicherung in Tabellen vor. Stattdessen werden Dokumente verwendet, die in Collections organisiert sind. Wie muss man sich das genau vorstellen? Jedes Dokument enthält eine Reihe von Schlüssel-Wert-Paaren. Alle Dokumente müssen in Collections aufbewahrt werden. Dokumente können Sub-Collections und verschachtelte Objekte enthalten, die beide primitive Felder wie Zeichenfolgen oder komplexe Objekte wie Listen enthalten können. Die Speichereinheit ist das Dokument. Ein Dokument ist ein Datensatz, der Felder enthält, die Werten zugeordnet sind. Jedes Dokument wird durch einen Namen identifiziert. Ein Beispiel: Das Dokument User enthält die Felder Vorname, Nachname und Geburtsdatum und hat einen Namen (Key) zur Identifikation. Komplexe, verschachtelte Objekte in einem Dokument werden als Maps bezeichnet. Dokumente haben damit eine gewisse Ähnlichkeit mit dem JSON-Datenformat.

Mehrere Dokumente werden zu Collections zusammengefasst. Beispielsweise könnte eine Collection die Auflistung der verschiedenen Benutzer enthalten, die jeweils durch ein Dokument dargestellt werden. Die Datenbank ist schemalos, d. h. es wird nicht festgelegt, welche Datentypen Sie in diesen Feldern speichern. Dokumente in derselben Collection können alle unterschiedliche Felder enthalten oder unterschiedliche Datentypen in diesen Feldern speichern. Dennoch ist es empfehlenswert, mit einer einheitlichen Abbildung der Datenrepräsentation zu arbeiten.

Der Zugriff auf die Dokumente erfolgt über einen Schlüssel. Diese Schlüssel der Dokumente in einer Collection sind eindeutig. Sie können Ihre eigenen Schlüssel, beispielsweise Benutzer-IDs, bereitstellen (und müssen dann selbst für Eindeutigkeit sorgen) oder durch Cloud Firestore automatisch zufällige IDs erstellen lassen. Letzteres geschieht, wenn Sie ein Dokument mittels der Methode add(…) einer Collection hinzufügen. Beachten Sie: Eine Collection muss man nicht anlegen oder löschen. Fügt man ein Dokument hinzu, wird eine Collection generiert. Sind alle Dokumente entfernt, existiert die Collection nicht mehr.

Mittels Referenzen kann man im Quellcode Dokumente identifizieren und mit diesen arbeiten. Ein einfaches Beispiel: DocumentReference myDocument­Ref = db.collection("users").document("klaus"); Wir bekommen einen Zugriff auf das Dokument klaus aus der Collection users. Über Sub-Collections kann man Dokumente hierarchisch organisieren. Firestore kommt mit einer Vielzahl von Datentypen zurecht. Zur Erinnerung: Da die NoSQL-Datenbank schemalos arbeitet, müssen Sie im Vorfeld keine Struktur vorgeben. Sie können Daten mit den folgenden Datentypen speichern: Arrays, Boolean, Bytes, Data and Time, Floating-Point Number, Geographical Point, Integer Map (Schlüssel-Wert-Kombinationen), Null, Referenzen (auf Dokumente und Collections) und Textstrings.

Firebase nicht nur für Android

Auch wenn Firebase und Android aus einem Hause stammen und beide Produkte sehr gut aufeinander abgestimmt sind – zum Beispiel durch eine schnelle Integration in Android Studio – ist die Verwendung keine Einbahnstraße. Ein Blick in die Dokumentation zeigt: es gibt entsprechende Software Development Kits (SDKs) für alle gängigen Systeme, d. h. Android, iOS und Java­Script. Es stehen aber auch SDKs für C++ und Unity zur Verfügung. Auch eine generische Verwendung über ein RESTful Interface ist möglich. Damit kann man die Speicherdienste von Firebase geräte- und plattformübergreifend einsetzen. Das können zum Beispiel gemischte Systemumgebungen und Anwendungen für mobile Apps sein. Dort muss man heute i. d. R. sowohl Android- als auch iOS-Devices gleichermaßen unterstützen. Auch ein Einsatz im Enterprise-Umfeld ist möglich, denn dort kommen neben mobilen Geräten oft auch Web- und Desktopclients hinzu. Hier wird man dann zum Beispiel das RESTful Interface nutzen.

Wo liegen die Daten?

Die Daten liegen in der Cloud, genauer: auf den Servern von Google. Die Dokumentation sagt dazu: „Bevor Sie Cloud Firestore verwenden, müssen Sie einen Speicherort für Ihre Datenbank auswählen. Speichern Sie Ihre Daten in der Nähe der Benutzer und Dienste, die sie benötigen, um die Latenz zu verringern und die Verfügbarkeit zu erhöhen.“

Neben Multi-Region Location können Sie die Speicherung auch in Regional Locations veranlassen. Zur Auswahl stehen dann Nordamerika, Südamerika, Europa (London, Frankfurt, Zürich), Asien und Australien. Der Standort beantwortet noch nicht die Frage, ob die strengeren Datenschutzbestimmungen der EU-Datenschutzgrundverordnung damit eingehalten werden. Eine umfassende Recherche führt zu folgender Aussage von Google: „Firebase is GDPR-ready“. Wenn Sie als Entwickler/Betreiber einer App Firebase verwenden, ist Google in der Regel ein Datenverarbeiter und verarbeitet die personenbezogenen Daten in Ihrem Namen. Für die Firebase Dienste gelten i. d. R. die Nutzungsbedingungen der Google Cloud Platform (GCP).

Wie ist das zu werten? Die Datenspeicherung kann man lokal verorten. Für Firebase gelten die Datenschutzbestimmungen von Google. Die Plattform unterstützt es, die Bestimmungen der DSGVO umzusetzen. Das geschieht beispielsweise, indem offengelegt wird, welche Daten in welcher Form für die Verarbeitung gespeichert werden. Ebenso werden für die Firebase-Dienste die Einhaltung von ISO- und SOC-Bestimmungen nachgewiesen. In der Dokumentation finden sich beispielsweise Hinweise zur praktischen Umsetzung der so genannten Opt-in-Verfahren. Diese sorgen dafür, dass der Nutzer explizit vor der Nutzung eines Service mit Datenverarbeitung zustimmen muss. Ein Beispiel: Für die Übermittlung der Daten zur App-Analyse, wie Crash Reporting der Analytics, muss der Nutzer explizit (Opt-in) zustimmen.

Letztendlich müssen die Nutzer von Firebase, d. h. die Entwickler und Betreiber der Apps, die Prozesse der Datenverarbeitung transparent machen und dann prüfen, ob je nach Brisanz der Daten eine Speicherung in der Google Cloud zulässig ist. Im Einzelfall wird man hier rechtlichen Rat einholen müssen.

Jenseits von Firebase

Auch wenn diese Artikelserie die Services von Firebase vorstellt, gibt es natürlich Alternativen. Darauf hatten wir bereits im ersten Teil hingewiesen. Für die Aufgaben der Datenspeicherung sind die Dienste des Azure Portals von Microsoft weitgehend vergleichbar. Um den direkten Vergleich zu bekommen, möchten wir diese hier kurz als Alternative vorstellen. Der passende Service heißt bei Azure „Mobile Apps“. Darunter werden umfassende Funktionen für Apps zusammengefasst: Speicherung der Daten in der Cloud, Useridentifikation mit der Möglichkeit, Identity Provider, wie zum Beispiel Facebook, zu nutzen und der Einsatz von Push Notifications. Bleiben wir bei den Funktionen zur Datenspeicherung. Azure bietet dazu mehrere Optionen. Zum einen kann man einen SQL Server nutzen und ihn auch als Azure-Dienst in der Cloud ausführen. Mit Azure Blob Storage steht ein weiterer Dienst bereit, um unstrukturierte Daten als Objekte (Blobs) zu speichern. Im Blob Storage können alle Arten von Text- oder Binärdaten gespeichert werden, beispielsweise ein Dokument oder eine Mediendatei. Der Speicherdienst Table Storage speichert strukturierte NoSQL-Daten und bietet einen Schlüssel-/Attributspeicher mit einem schemalosen Design.

Grundsätzlich umfasst die Entwicklung zwei Bereiche: zum einen die Programmierung des Clients für die mobilen Plattformen, zum anderen die Programmierung des Backends, u. a. mit der Datenzugriffsschicht. Das Backend wird komplett über das Dashboard online im Browser konfiguriert. Table Storage bietet die Wahl zwischen .NET- und Node.js Backends. Clientseitig erfolgt der Zugriff über das Azure SDK und den individuellen Endpunkt. Auch hier gilt (wie bei Firebase von ­Goo­gle): Die Dienste von Azure geben sich erfreulicherweise sehr kommunikativ. Neben dem hauseigenen Windows (C#) werden ebenso Android mit Java, iOS mit Swift und JavaScript-basierte Applikationen unterstützt. Für alle Plattformen stehen Bibliotheken zur Einbindung zur Verfügung.

Fazit

Die Google-Cloud-Lösung Firebase ist eine Sammlung von leistungsfähigen Services für mobile Apps. Zwei Kernfeatures, Authentifizierung und Datenspeicherung haben wir ausführlicher vorgestellt. Firebase kann mit einem fairen Preismodell punkten, die meisten Dienste kann man in der kostenfreien Variante Spark Plan (Free) ausprobieren. Die Speicher- und Transfergrenzen sind in diesem Angebot ausreichend, um produktive Projekte auf dieser Basis zu realisieren. Firebase hat sich – wie die Dienste anderer Cloudanbieter auch – für die Nutzung auf anderen Plattformen und Geräten jenseits von An­droid, Java/Kotlin und Android Studio geöffnet.

Benötigen Sie für Ihr nächstes Mobile-App-Projekt ein leistungsfähiges Backend, sollte Firebase auf jeden Fall mit in die Auswahl kommen.

Weitere Informationen zu diesen und anderen Themen der IT finden Sie unter http://larinet.com.

Geschrieben von
Dr. Veikko Krypczyk
Dr. Veikko Krypczyk
Dr. Veikko Krypczyk studierte und promovierte in Betriebswirtschaftslehre mit dem Schwerpunkt Wirtschaftsinformatik. Er ist Entwickler und Fachautor. Aktuell beschäftigt er sich mit der App-Programmierung für Windows Phone und Android.
Olena Bochkor
Olena Bochkor
Olena Bochkor studierte Betriebswirtschaftslehre u. a. mit dem Schwerpunkt Wirtschaftsinformatik. Weitere Informationen zu diesen und anderen Themen der IT finden Sie unter http://it-fachartikel.de.
Kommentare

Hinterlasse einen Kommentar

avatar
4000
  Subscribe  
Benachrichtige mich zu: