📖Persistenz

Bei mobile Apps möchte man ziemlich schnell Daten speichern können. Sei es eine einfache Einstellung des Users, ganze Liste aus einer Datenbank laden und die App auch Offline benutzen. Es ist somit von sehr zentraler Bedeutung die folgenden Fragestellung bereits von Beginn deines Projekt zu stellen. Es kann auch gut sein, dass dein Anspruch an Persistenz sich mit zunehmenden Anforderungen ändert.

Wichtige Fragestellungen

Online/Offline

Wie muss die Verfügbarkeit meiner App sein? Soll der Benutzer die App hauptsächlich Offline (z.B. also auch ohne Internet-Verbindung) nutzen können oder sind die Daten so zentral gelagert, dass sie nur Online sein können.

Schlechte Netzwerkverbindung

Was wenn die Internet-Verbindung sehr schlecht ist oder gar nicht funktioniert ? Ich spreche hier nicht vom ebenfalls sehr wichtigen Exception-Handling (geht auch etwas ins Thema UX), sondern von den Daten. Macht es Sinn, gewisse oder alle Daten Offline zu halten und mit der Online-Datenbank zu synchronisieren?

Single vs. Multi-User

Sind die App-Daten nur für einen Benutzer gedacht oder sollen mehrere damit arbeiten? Will ich meinen Blog-Eintrag für nur eine Person bearbeitbar machen oder sollen mehrere Personen daran arbeiten können? Was passiert wenn 2 Benutzer gleichzeitig auf die Daten zugreifen möchten.

Es ist von zentraler Bedeutung, dass du als Entwickler dir solchen Fragen stellst und diese vor Go-Live deiner App annimmst.

Eigenes Backend vs. Backend as a Service

Ein Backend as a Service auch BaaS genannt, ist ein Cloud Dienstmodell, dass eine komplette Backend-Infrastruktur zur Verfügung stellt. Somit fallen einige wichtige Entwicklungs-, Hosting- und Wartungsarbeiten und dementsprechend Kosten weg. Solche BaaS stellen eine Vielzahl von Funktionen und Diensten an, darunter Datenbanken, Authentifizierung, Storage, und viele mehr.

BaaS spart Zeit und Geld

Ein BaaS (Backend as a Service) vereinfacht die Entwicklung von Anwendungen, indem es eine vorkonfigurierte Backend-Infrastruktur bietet. Entwickler können dadurch leicht Tabellen erstellen, Datenbanken verwalten und APIs nutzen, ohne ein eigenes Backend programmieren zu müssen. Dies spart Zeit und Geld, da keine separate Backend-Entwicklung und -Koordination notwendig sind. Zudem ermöglicht BaaS die einfache Anpassung von Datenzugriffspunkten mit minimalem Programmieraufwand.

Wird effektiv Geld gespart?

Bei der Nutzung eines Backend as a Service (BaaS) skaliert der Server automatisch mit steigender Last, was die Verwaltung erleichtert. Allerdings können die Kosten für solche Dienste unvorhersehbar sein. Sie steigen je nach Anzahl der Anfragen, benötigtem Speicher und Datentransfer. Im Gegensatz zu dedizierten Servern, bei denen die Kosten fest und kalkulierbar sind, variieren die Preise bei BaaS-Anbietern je nach Nutzung und können daher schwer kalkuliert werden. Die Abrechnungsmodelle unterscheiden sich zudem von Anbieter zu Anbieter.

Sicherheit und Kontrolle

BaaS-Dienste bieten oft wenig Transparenz und Kontrolle über Datensicherung und Ausfallsicherheit. Die genauen Backup-Verfahren sind meist nur im Kleingedruckten beschrieben, und es ist unklar, wie schnell und sicher Daten im Falle eines Ausfalls wiederhergestellt werden. Dies kann besonders kritisch sein, wenn man mit sensiblen Nutzerdaten arbeitet.

Abhängigkeit vom Anbieter

Zusätzlich gibt es mit den verschärften Datenschutzgesetzen die Notwendigkeit Sicherzustellen wo und wie Daten gespeichert werden. Dies muss ebenso pro Anbieter überprüft werden.

Die Wahl des Anbieters birgt Abhängigkeitsrisiken, da ein Wechsel komplex ist und keine Rückwärtskompatibilität gewährleistet. Zudem ist der BaaS-Markt volatil, und Anbieter können schnell verschwinden, was die Langzeitstabilität gefährdet.

Fazit

BaaS-Dienste bieten neben Nachteilen auch Vorteile wie Nutzungsstatistiken, kostenlose Push-Benachrichtigungen und Social-Logins. Die Wahl zwischen BaaS und einem eigenen dedizierten Server hängt von den spezifischen Anforderungen der Anwendung ab. BaaS ist oft eine gute Startlösung für Startups, um schnell und kostengünstig den Markt zu betreten. Langfristig kann jedoch ein eigenes Backend notwendig werden, besonders wenn die Anwendung wächst, spezielle Sicherheitsanforderungen hat oder eine Anbindung an Fremdsysteme benötigt.