App-Backend: Firebase (BaaS) oder eigenes Backend?

Jede mobile App hat ein Backend; die Frage ist nicht, ob es eines gibt, sondern wer es baut. Kurz gesagt: Für ein MVP, das ein einzelnes Team entwickelt, mit wenigen Geschäftsregeln und einfachem Datenmodell, ist ein Backend-as-a-Service (BaaS) wie Firebase oder Supabase der schnellste Weg. Gibt es mehrere Clients (Mobil plus Web-Panel plus Drittanbieter), Geschäftsregeln, die auf dem Server laufen müssen, Integrationen wie ERP oder E-Rechnung, relationale Auswertungen und Pflichten dazu, wo die Daten liegen, braucht es ein eigenes Backend. In den meisten Unternehmensprojekten ist die richtige Antwort hybrid: Firebase für Push, Absturzberichte und Analytics, die eigene API für Kerndaten und Geschäftsregeln. Dieser Beitrag beschreibt, wie wir diese Entscheidung in Projekten für mobile Apps treffen.

Was leistet ein Backend für eine mobile App?

Die App auf dem Telefon ist nur die Oberfläche; alles Dauerhafte lebt auf einem Server. Das Backend übernimmt diese Aufgaben:

• Authentifizierung und Sitzungen: Wer ist der Nutzer, von welchem Gerät hat er sich angemeldet, wann endet die Sitzung.
• Datenspeicherung und Abfragen: Bestellungen, Nachrichten, Profile, einschließlich zweier Nutzer, die denselben Datensatz gleichzeitig ändern.
• Geschäftsregeln: Preisberechnung, Bestandsabzug, Freigabeabläufe, Limitprüfungen. Diese auf dem Client auszuführen ist eine Sicherheitslücke.
• Dateien und Medien: Foto-Upload, Skalierung, Zugriffsrechte.
• Benachrichtigungen und geplante Jobs: Push, E-Mail, nächtliche Berichte.
• Integrationen: Zahlungsanbieter, Versand, Buchhaltung, ERP; die Schlüssel dieser Verbindungen dürfen nicht im App-Paket liegen.

Ein Backend-Dienst deckt den ersten, zweiten und vierten Punkt sehr gut ab, den dritten und sechsten nur mit zusätzlichem Code. Auf dieser Lücke baut die Entscheidung auf.

Was BaaS (Firebase, Supabase) liefert und was nicht

Firebase ist ein von Google gehostetes Dienstpaket: Authentication, Firestore (Dokumentdatenbank), Storage, Cloud Functions, Cloud Messaging (Push), Crashlytics und Analytics. Supabase baut ein ähnliches Paket auf PostgreSQL auf und ist Open Source. In beiden verwalten Sie keine Server; die App verbindet sich per SDK direkt mit der Datenbank, Zugriffsregeln werden auf Dienstseite definiert. Der Gewinn ist klar: eine erste Version in Tagen statt Wochen, keine Authentifizierung und keine Echtzeit-Synchronisation selbst schreiben, keine Skalierung bedenken. Was fehlt, zeigt sich später im Projekt: Firestore kennt keine Joins und keine Massenauswertungen, das Datenmodell wird um Bildschirme herum gebaut und jeder neue Bildschirm strapaziert es; mehrstufige Geschäftsregeln bedeuten trotzdem Cloud Functions; die Daten in ein anderes System zu überführen ist möglich, aber der Weg von einer Dokument- zu einer relationalen Struktur ist ein eigenes Projekt. Supabase löst das erste Problem mit einer relationalen Datenbank, die Frage nach Geschäftsregeln und Integrationen bleibt aber dieselbe.

Der entscheidende Unterschied: Wo laufen die Geschäftsregeln?

Im BaaS-Modell schreibt die App direkt in die Datenbank. Das ist die schnellste und zugleich gefährlichste Eigenschaft. Berechnet in einer Bestell-App das Telefon die Summe und schreibt sie nach Firestore, kann jeder, der die App öffnet, diese Summe ändern und absenden; Sicherheitsregeln prüfen Feldtypen und Eigentum, aber eine Regel wie „die Summe muss der Summe aus Preis mal Menge über alle Positionen entsprechen“ lässt sich kaum lesbar formulieren. Die Lösung ist, den Schreibvorgang in eine Serverfunktion zu verlegen:

// Cloud Function: die Summe kommt nicht vom Client, sie wird auf dem Server berechnet
import { onCall, HttpsError } from 'firebase-functions/v2/https';
import { getFirestore } from 'firebase-admin/firestore';

export const createOrder = onCall(async (req) => {
  if (!req.auth) throw new HttpsError('unauthenticated', 'Anmeldung erforderlich');

  const db = getFirestore();
  const items = req.data.items as { productId: string; qty: number }[];

  return db.runTransaction(async (tx) => {
    let total = 0;
    for (const item of items) {
      const snap = await tx.get(db.doc('products/' + item.productId));
      if (!snap.exists) throw new HttpsError('not-found', 'Unbekanntes Produkt');
      const product = snap.data()!;
      if (product.stock < item.qty) {
        throw new HttpsError('failed-precondition', 'Bestand reicht nicht');
      }
      total += product.price * item.qty; // Preis aus dem Datensatz, nicht vom Telefon
      tx.update(snap.ref, { stock: product.stock - item.qty });
    }
    const ref = db.collection('orders').doc();
    tx.set(ref, { userId: req.auth!.uid, items, total, createdAt: new Date() });
    return { orderId: ref.id, total };
  });
});

Sobald Sie diese Funktion schreiben, schreiben Sie ein Backend; nur das Hosting liegt bei Google. Mit wachsender Zahl der Geschäftsregeln vermehren sich die Funktionen, gemeinsamer Code und Testaufbau brauchen ein Gerüst, und das Projekt wird zu einem eigenen Backend, ohne dass es jemand entschieden hätte. Deshalb beginnt die Entscheidung nicht mit „Firebase oder eigener Server“, sondern mit „wie viele meiner Geschäftsregeln müssen auf dem Server laufen“. Die Sicherheitsprinzipien der mobilen Seite behandeln wir in Sicherheit mobiler Apps, das API-Design in REST oder GraphQL.

Ein Backend-Dienst beseitigt Geschäftsregeln nicht, er ändert nur, wo sie geschrieben werden. Übersteigt die Zahl der Regeln, die auf dem Server laufen müssen, eine Handvoll, beginnt der gewonnene Zeitvorsprung, sich zurückzuzahlen.

Was treibt die Kosten?

BaaS wird nach Nutzung abgerechnet: Lese- und Schreibvorgänge, Speicher und Funktionsaufrufe. Ein eigenes Backend hat feste Server- und Wartungskosten. Wir nennen keine Zahlen, denn die beiden Rechnungen werden von unterschiedlichen Dingen getrieben, und das zu wissen ist wichtiger als die Zahl. Eine BaaS-Rechnung wächst mit dem Datenmodell, nicht mit der Nutzerzahl: Liest ein Listenbildschirm bei jedem Öffnen hundert Dokumente, hängen die täglichen Lesevorgänge pro Nutzer am Design dieses Bildschirms, und das ist nach dem Start der teuerste Fehler, den man beheben kann. Die Kosten eines eigenen Backends wachsen nicht mit dem Transaktionsvolumen, sondern mit der Zeit des Teams, das es schreibt und wartet. Die jährlichen Posten haben wir in Wartungskosten mobiler Apps aufgeschlüsselt; für das Entwicklungsbudget siehe Kosten der App-Entwicklung.

Gehören die Daten Ihnen? Portabilität und Standort

Jedes Projekt auf einem BaaS sollte drei Fragen vorab beantworten. Erstens: In welchem Land liegen die Daten? Firebase-Projekte lassen eine Region wählen, aber die Übermittlung personenbezogener Daten ins Ausland ist nach dem türkischen Datenschutzrecht (KVKK) eine eigene Pflicht, die über die Datenschutzerklärung und, wo nötig, eine ausdrückliche Einwilligung abzudecken ist (dieser Beitrag ist keine Rechtsberatung). Zweitens: Wie werden die Daten exportiert? Den Weg von einer Dokument- zu einer relationalen Datenbank beschreiben wir in Datenmigration; er ist machbar, aber ein um Bildschirme herum gebautes Datenmodell wird beim Übergang in Tabellen neu entworfen. Drittens: Was passiert, wenn der Dienst eine Funktion einstellt? Firebase Dynamic Links wurde abgeschaltet, und die davon abhängigen Apps haben ihre Link-Infrastruktur neu aufgebaut. Das macht den Dienst nicht schlecht; es zeigt, dass eine Produktentscheidung des Anbieters Ihr Produkt erreichen kann. Halten Sie die Ausstiegskosten schriftlich fest, bevor Sie einen kritischen Ablauf an einen einzigen Anbieter binden.

Der Entscheidungstest: drei Fragen

Beantworten Sie mindestens zwei der folgenden Fragen mit „ja“, gehören die Kerndaten in ein eigenes Backend:

• Werden außer der App weitere Clients die Daten nutzen: ein Web-Admin-Panel, ein Händlerportal, eine Drittanbieter-API, eine Buchhaltungs- oder ERP-Integration?
• Gibt es Geschäftsregeln, die auf dem Server laufen müssen: Preis- und Rabattberechnung, Bestandsreservierung, Freigabeabläufe, Limitprüfungen, geordnete Transaktionen?
• Wird relationales Reporting benötigt: Umsatz nach Zeitraum, Durchschnitt je Nutzer, Managementberichte über mehrere Tabellen?

Eine vierte Frage gilt auf beiden Wegen: Können Sie die Daten heute mit einem einzigen Befehl exportieren? Falls nicht, lösen Sie zuerst das, unabhängig vom gewählten Modell. Bei weniger als zwei „ja“, und besonders wenn Sie eine erste Version schnell auf den Markt bringen und die Nachfrage messen wollen, ist BaaS der richtige Start; den MVP-Umfang beschreiben wir in Was ist ein MVP. Steht eine Datenbankwahl an, hilft PostgreSQL oder MySQL.

Das Hybridmodell: beides zusammen nutzen

In der Praxis ist dies der häufigste Aufbau: Firebase Cloud Messaging für Push, Crashlytics für Absturzberichte, Analytics für die Nutzung; die eigene API für Identität, Kerndaten und Geschäftsregeln. In diesem Modell verbindet sich die App nie mit Firestore; Firebase liefert nur die Hilfsdienste auf Geräteseite. Die Push-Einrichtung behandeln wir in Push-Benachrichtigungen, das Design, das ohne Verbindung weiterarbeitet, in Offline-first-Apps. Das Hybridmodell hat eine Bedingung: Die Grenze muss ausdrücklich sein. Welche Daten Firebase gehören und welche der API, muss vom ersten Tag an schriftlich feststehen; sonst liegt dieselbe Information an zwei Orten, und niemand weiß, welche stimmt.

Fazit

Firebase und ähnliche Dienste sind echte Werkzeuge, die die erste Version einer App beschleunigen; das Problem ist nicht das Werkzeug, sondern die nicht getroffene Entscheidung. Wenn eine Geschäftsregel auf den Server muss, ein zweiter Client kommt oder der erste Managementbericht verlangt wird, ist das Projekt bereits ein eigenes Backend geworden, und das geplant zu tun ist günstiger als zufällig. Schreiben Sie uns über das Angebotsformular, um zu klären, welche Daten Ihrer App wohin gehören; die drei Fragen oben beantworten wir im ersten Gespräch gemeinsam.