Backend für Mobile Apps 2025: REST vs GraphQL, Cloud-Services, Skalierung

Die Backend-Architektur ist die unsichtbare Grundlage jeder App. Nutzer sehen sie nicht – aber sie spüren sofort, wenn sie schlecht ist: langsame Ladezeiten, Sync-Probleme, Ausfälle.

In diesem Guide zeige ich Ihnen, wie Sie die richtige Backend-Entscheidung treffen: REST oder GraphQL? Firebase oder eigenes Backend? Serverless oder Container? Und vor allem: Wann welche Entscheidung die richtige ist.

Meine Perspektive: Backend-Architektur ist keine Technologie-Entscheidung, sondern eine Business-Entscheidung. Die Frage ist nicht "Was ist technisch am coolsten?", sondern "Was ermöglicht uns, schnell zu iterieren, zuverlässig zu skalieren, und nachts zu schlafen?" Overengineering kostet genauso viel wie Underengineering – nur anders.

Backend-Grundlagen: Was Mobile Apps brauchen

Bevor wir in Technologien einsteigen: Was muss ein Mobile-Backend eigentlich leisten?

Core-Funktionen

• Authentifizierung: Login, Session-Management, Token-Refresh
• Datenspeicherung: User-Daten, App-Daten, Medien
• Business-Logik: Validierung, Berechnungen, Workflows
• Push Notifications: Server-zu-Client-Kommunikation
• Synchronisation: Offline-Fähigkeit, Konfliktauflösung

Mobile-spezifische Anforderungen

• Bandbreiten-Effizienz: Mobile Netze sind langsam und teuer
• Latenz-Sensitivität: Nutzer erwarten sofortige Reaktion
• Offline-Toleranz: Apps müssen auch ohne Netz funktionieren
• Battery-Awareness: Polling killt Akkus
• Versionskompatibilität: Alte App-Versionen müssen weiter funktionieren

Ein Mobile-Backend ist nicht einfach ein Web-Backend mit einer anderen URL. Die Constraints sind fundamental anders.

REST vs GraphQL: Die API-Entscheidung

Die häufigste Architekturfrage – und die am meisten überschätzte. Beide funktionieren, beide haben Trade-offs.

REST: Der Klassiker

Was es ist: Ressourcen-orientierte API mit HTTP-Verben (GET, POST, PUT, DELETE).

Stärken:

• Einfach zu verstehen, breites Tooling
• HTTP-Caching funktioniert out-of-the-box
• Jeder Entwickler kennt es
• Debugging trivial (curl, Postman)
• Stabile, ausgereifte Ecosystem

Schwächen:

• Over-fetching: Endpoint liefert mehr Daten als benötigt
• Under-fetching: Mehrere Requests nötig für eine View (lösbar mit Composite Endpoints / BFF, z.B. /home liefert exakt die Daten für Home-Screen)
• Versionierung: Breaking Changes erfordern neue API-Versionen
• Dokumentation: Muss separat gepflegt werden (OpenAPI/Swagger)

GraphQL: Der Flexible

Was es ist: Query-Sprache, bei der der Client exakt anfordert, was er braucht.

Stärken:

• Kein Over-/Under-fetching: Exakt die benötigten Daten
• Ein Endpoint: Keine URL-Explosion
• Typed Schema: Selbst-dokumentierend, Type-Safety
• Versionierung einfacher: Felder deprecaten statt API-Versionen
• Ideal für komplexe UIs: Viele verschachtelte Daten in einem Request

Schwächen:

• Komplexität: Mehr Setup, steilere Lernkurve
• Caching schwieriger: HTTP-Caching funktioniert nicht, Client-Caching nötig
• N+1-Problem: Naive Implementierungen sind langsam (DataLoader nötig)
• Security: Query-Komplexität muss begrenzt werden (DoS-Risiko)
• Tooling: Weniger Debugging-Tools als REST

Entscheidungsmatrix

Kriterium	REST besser wenn...	GraphQL besser wenn...
Team-Erfahrung	Team kennt REST, wenig GraphQL-Erfahrung	Team hat GraphQL-Erfahrung oder Zeit zum Lernen
UI-Komplexität	Einfache CRUD-Operationen	Komplexe, verschachtelte Datenstrukturen
Clients	Ein Client (nur Mobile) oder wenige	Viele Clients mit unterschiedlichen Datenanforderungen
Caching	Aggressive HTTP-Caching nötig	Echtzeit-Daten, wenig Caching
Bandbreite	Bandbreite unkritisch	Jedes KB zählt (Mobile, emerging markets)
Time-to-Market	Schnell liefern, Team kennt REST	Langfristige Flexibilität wichtiger

Kurz gesagt: Starten Sie mit REST, es sei denn, Sie haben konkrete Gründe für GraphQL. Migration später ist möglich.

Cloud-Services im Vergleich

Die Plattform-Entscheidung hat langfristige Konsequenzen: Lock-in, Kosten, verfügbare Features.

Firebase (Google)

Was es ist: Backend-as-a-Service (BaaS) mit Realtime-Fokus.

Komponenten:

• Firestore: NoSQL-Datenbank mit Realtime-Sync
• Authentication: OAuth, Email, Phone, Anonymous
• Cloud Functions: Serverless Backend-Logik
• Cloud Storage: Datei-Uploads
• FCM: Push Notifications
• Hosting, Analytics, Crashlytics, ...

Stärken:

• Extrem schneller Start (Stunden statt Wochen)
• Realtime-Sync out-of-the-box
• Offline-Support eingebaut
• Hervorragende Flutter/Mobile SDKs
• Großzügiges Free Tier

Schwächen:

• Vendor Lock-in: Migration ist aufwändig
• NoSQL-Einschränkungen: Komplexe Queries schwierig
• Kosten bei Scale: Kann teuer werden (Read/Write-basiert)
• EU-Hosting: Je nach Firebase-Service eingeschränkt/kompliziert
• Begrenzte Backend-Logik: Cloud Functions haben Limits

Ideal für: MVPs, Startups, Apps mit Realtime-Anforderungen, kleine Teams

Supabase

Was es ist: Open-Source Firebase-Alternative mit PostgreSQL.

Stärken:

• PostgreSQL: Echte relationale Datenbank, SQL-Power
• Open Source: Self-Hosting möglich
• Row Level Security: Fein-granulare Zugriffsrechte
• Realtime: Ähnlich wie Firestore
• EU-Hosting: Frankfurt-Region verfügbar

Schwächen:

• Jünger als Firebase, weniger ausgereift
• Mobile SDKs weniger mächtig als Firebase
• Offline-Support muss selbst implementiert werden
• Community kleiner

Ideal für: Teams mit SQL-Erfahrung, DSGVO-sensible Apps, relationale Datenmodelle

AWS Amplify

Was es ist: AWS-Frontend für Mobile/Web mit Backend-Services.

Stärken:

• Volle AWS-Power dahinter (wenn nötig)
• GraphQL-API (AppSync) first-class
• Cognito für Enterprise-Auth (SAML, OIDC)
• EU-Regionen verfügbar

Schwächen:

• AWS-Komplexität durchscheint
• Steile Lernkurve
• Debugging kann frustrierend sein
• Kosten-Transparenz schwierig

Ideal für: Enterprise-Apps, AWS-erfahrene Teams, komplexe Auth-Anforderungen

Eigenes Backend (Node, Python, Go, ...)

Was es ist: Selbst entwickeltes Backend auf eigener Infrastruktur oder Cloud.

Stärken:

• Volle Kontrolle: Keine Limits, keine Überraschungen
• Kein Lock-in: Migrieren wohin Sie wollen
• Kostenoptimierung: Bei Scale oft günstiger
• Beliebige Logik: Keine BaaS-Einschränkungen

Schwächen:

• Entwicklungszeit: Alles selbst bauen (Auth, Realtime, ...)
• Ops-Aufwand: Deployment, Monitoring, Security
• Team-Kapazität: Braucht Backend-Entwickler

Ideal für: Komplexe Business-Logik, langfristige Produkte, große Teams

Plattform-Vergleich auf einen Blick

Kriterium	Firebase	Supabase	AWS Amplify	Eigenes Backend
Time-to-MVP	Sehr schnell	Schnell	Mittel	Langsam
Lernkurve	Flach	Flach	Steil	Variiert
Skalierung	Automatisch	Automatisch	Automatisch	Selbst managen
Lock-in	Hoch	Niedrig	Mittel	Keiner
EU-Hosting	Begrenzt	Ja	Ja	Frei wählbar
Kosten bei 10k MAU	Meist Free	Meist Free	~$50-100	~$50-200
Kosten bei 1M MAU	$500-2000+	$100-500	$500-2000	Variiert stark

Nur Daumenwerte – echte Kosten hängen von Reads/Writes/Egress, Nutzungsmuster und Traffic-Peaks ab.

Für MVPs und erste Versionen ist BaaS (Firebase, Supabase) fast immer der richtige Start. Custom Backend, wenn Sie konkrete Anforderungen haben, die BaaS nicht erfüllt – nicht präventiv.

Serverless vs. Container vs. VM

Falls Sie ein eigenes Backend bauen: Wie deployen Sie es?

Serverless Functions (Lambda, Cloud Functions)

Was es ist: Code, der bei Bedarf ausgeführt wird. Keine Server-Verwaltung.

Stärken:

• Kein Ops-Aufwand
• Automatische Skalierung (0 bis ∞)
• Pay-per-Execution (bei wenig Traffic: billig)

Schwächen:

• Cold Starts: Erste Anfrage langsam (kann 100ms bis >1s sein)
• Execution Limits: Timeout, Memory, Payload-Größe
• Stateless: Kein persistenter Zustand zwischen Calls
• Debugging: Verteiltes System, schwerer nachzuvollziehen
• Kosten bei Scale: Kann bei hohem Traffic teuer werden

Ideal für: Event-driven Workloads, APIs mit variablem Traffic, Webhooks

Container (Docker, Kubernetes, Cloud Run)

Was es ist: Containerisierte Anwendungen, skalierbar und portabel.

Stärken:

• Volle Kontrolle über Runtime
• Keine Cold Starts (bei min. 1 Instance)
• Portabilität (lokal = Cloud)
• Gut für stateful Workloads

Schwächen:

• Mehr Ops-Aufwand (Kubernetes = komplex)
• Kosten auch bei 0 Traffic (min. 1 Instance)
• Skalierung muss konfiguriert werden

Ideal für: APIs mit konstantem Traffic, komplexe Anwendungen, Teams mit Container-Erfahrung

Traditionelle VMs

Stärken:

• Volle Kontrolle
• Vorhersagbare Kosten
• Einfaches Mental-Model

Schwächen:

• Manuelles Skalieren
• Patching, Security-Updates selbst
• Idle-Kosten

Ideal für: Legacy-Systeme, spezielle Anforderungen, Teams ohne Cloud-Erfahrung

Deployment-Entscheidung

Faktor	Serverless	Container	VM
Ops-Aufwand	Minimal	Mittel	Hoch
Skalierung	Automatisch	Semi-Auto	Manuell
Cold Starts	Ja	Optional (min 1)	Nein
Kosten bei wenig Traffic	Sehr niedrig	Niedrig-Mittel	Mittel
Kosten bei viel Traffic	Kann teuer werden	Effizient	Effizient

Praxis-Empfehlung: Starten Sie mit Serverless oder managed Container (Cloud Run, App Runner). Kubernetes erst, wenn Sie konkret wissen, warum Sie es brauchen.

Skalierung: Von 0 auf 1 Million

Skalierung ist kein Feature, das Sie einmal einbauen – es ist eine fortlaufende Architektur-Entscheidung.

Skalierungs-Dimensionen

• Vertical Scaling: Größere Server (einfach, hat Grenzen)
• Horizontal Scaling: Mehr Server (komplexer, unbegrenzt)
• Caching: Weniger Arbeit durch Zwischenspeicher
• CDN: Statische Assets näher am Nutzer
• Database Scaling: Read Replicas, Sharding

Typische Bottlenecks bei Mobile-Backends

1. Datenbank-Queries

• N+1-Problem (besonders bei GraphQL)
• Fehlende Indizes
• Keine Query-Pagination

Lösung: Query-Monitoring, Indexing-Strategie, Cursor-basierte Pagination

2. Unoptimierte Payloads

• Zu große API-Responses
• Bilder nicht optimiert
• Keine Kompression

Lösung: Response-Felder filtern, Bildgrößen anpassen, gzip/brotli

3. Fehlende Caching-Strategie

• Jeder Request geht zur Datenbank
• Keine HTTP-Cache-Header
• Kein CDN für statische Inhalte

Lösung: Redis/Memcached, Cache-Control Headers, CDN

4. Synchrone Verarbeitung

• Request wartet auf langsame Operationen
• Email-Versand im Request-Cycle
• Kein Background-Processing

Lösung: Message Queues (SQS, Pub/Sub), Background Jobs

Skalierungs-Strategie nach Phase

Phase	MAU	Fokus	Typische Architektur
MVP	0-1k	Schnell liefern	BaaS (Firebase) oder Single Server
Traction	1k-50k	Stabilität, erste Optimierungen	BaaS oder managed Container
Growth	50k-500k	Caching, CDN, DB-Optimierung	Serverless + Cache + CDN
Scale	500k+	Horizontale Skalierung, Microservices	Container/K8s, Read Replicas, Sharding

Kurz gesagt: Optimieren Sie erst, wenn Sie Probleme haben (oder kurz davor stehen). Monitoring einbauen, Bottlenecks identifizieren, gezielt lösen.

API-Design Best Practices

Versionierung

• URL-basiert: /api/v1/users, /api/v2/users
• Header-basiert: Accept: application/vnd.api+json; version=2
• Empfehlung: URL-basiert für Mobile (einfacher zu debuggen)

Wichtig: Alte Versionen lange unterstützen – Sie kontrollieren nicht, wann Nutzer updaten.

Pagination

• Offset-based: ?page=2&limit=20 – Einfach, aber inkonsistent bei neuen Einträgen
• Cursor-based: ?cursor=abc123&limit=20 – Konsistent, besser für Realtime
• Empfehlung: Cursor-based für Feeds und Listen mit häufigen Updates

Error Handling

Konsistentes Error-Format:

{
  "error": {
    "code": "VALIDATION_ERROR",
    "message": "Email ist ungültig",
    "field": "email",
    "request_id": "abc-123"
  }
}

• HTTP-Status-Codes korrekt nutzen (400, 401, 403, 404, 500)
• Machine-readable Error Codes (für App-Logik)
• Human-readable Messages (für Debugging)
• Request-ID für Support-Fälle

Rate Limiting

• Warum: Schutz vor Abuse, faire Ressourcen-Verteilung
• Response Headers: X-RateLimit-Remaining, X-RateLimit-Reset
• Strategie: Pro User, pro API-Key, pro Endpoint unterschiedlich

Security Essentials

Authentication Patterns

• JWT (JSON Web Tokens): Stateless, skalierbar, aber Token-Revocation schwierig
• OAuth 2.0: Standard für Third-Party-Auth (Google, Apple Sign-In)
• Session-based: Einfacher, aber Server-State nötig

Mobile-spezifisch:

• Refresh-Token-Rotation (Security + UX)
• Biometric als Second Factor (nicht als einziger)
• Secure Storage (Keychain/Keystore)

API-Security Checklist

• ✅ HTTPS everywhere (keine Ausnahmen)
• ✅ Input-Validierung auf Server-Seite
• ✅ SQL-Injection verhindern (Parameterized Queries)
• ✅ Rate Limiting implementieren
• ✅ Sensitive Daten nicht in URLs (Query Params loggen!)
• ✅ CORS korrekt konfigurieren
• ✅ Security Headers setzen
• ✅ Secrets nicht im Code (Environment Variables)
• ✅ Logging: keine Tokens/PII in Logs; Request-ID/Correlation-ID überall

Mobile-spezifische Security

• Certificate Pinning: Schutz vor MITM (aber Update-Strategie bedenken!)
• API-Key Obfuscation: Keys nicht im Klartext im App-Code
• Root/Jailbreak Detection: Für sensible Apps (Banking etc.)
• Code Obfuscation: Reverse Engineering erschweren

Backend-Kosten

Kostenmodelle verstehen

• BaaS (Firebase, Supabase): Pay-per-Operation (Reads, Writes, Storage, Bandbreite)
• Serverless: Pay-per-Invocation + Duration
• Container/VM: Pay-per-Time (auch wenn idle)

Kostenfallen

• Firebase Reads: Listener + Queries zählen schnell hoch
• Egress-Kosten: Daten, die das Datacenter verlassen, kosten
• Serverless bei Scale: Viele kleine Functions summieren sich
• Nicht-genutzte Ressourcen: Staging-Umgebungen, alte VMs

Kosten-Optimierung

• Monitoring first: Erst verstehen, wo Kosten entstehen
• Caching: Cache-Hit = kein Backend-Call = keine Kosten
• Right-sizing: Nicht mehr Ressourcen als nötig
• Reserved Capacity: Bei vorhersagbarem Traffic günstiger

Beispielrechnung: App mit 50.000 MAU

Komponente	Firebase	Supabase + Serverless	Custom (Cloud Run)
Database	~$50-100	~$25-50	~$30-60
Auth	Free	Free	~$10-20
Compute	~$20-50 (Functions)	~$20-40	~$40-80
Storage	~$10-20	~$10-20	~$10-20
Gesamt/Monat	~$80-170	~$55-110	~$90-180

Stark vereinfacht. Echte Kosten hängen von Nutzungsmuster, Datenmenge, Traffic-Peaks ab.

BaaS ist bei kleinem Scale oft günstiger durch niedrige Fixkosten. Bei großem Scale kann Custom Backend günstiger sein – aber nur, wenn Sie die Ops-Kosten einrechnen.

Migration und Refactoring

Wann migrieren?

• BaaS-Limits erreicht (Query-Komplexität, Kosten)
• Compliance-Anforderungen (EU-Hosting, Audits)
• Vendor-Lock-in wird zum Risiko
• Team ist gewachsen, kann Custom Backend maintainen

Migrations-Strategien

Strangler Pattern:

• Neue Features auf neuem Backend
• Alte Features schrittweise migrieren
• Kein Big Bang

API-Gateway dazwischen:

• Clients sprechen mit Gateway
• Gateway routet zu Alt- oder Neu-Backend
• Transparente Migration

Backward Compatibility

• Alte App-Versionen müssen weiter funktionieren
• API-Versionen parallel betreiben
• Deprecation-Warnings in Responses
• Analytics: Wie viele Nutzer auf alten Versionen?

Ich baue Backends so, dass sie skalieren können – aber nicht müssen. Das heißt: Saubere Architektur, keine Premature Optimization, klare Migration-Pfade.

Fazit: Backend als Enabler

Das beste Backend ist das, über das Sie nicht nachdenken müssen – weil es einfach funktioniert.

Die wichtigsten Takeaways:

1. Starten Sie einfach: BaaS für MVP, Custom wenn nötig
2. REST reicht meist: GraphQL nur bei konkretem Bedarf
3. Skalieren Sie später: Premature Optimization killt Velocity
4. Security von Anfang an: Client ist feindliches Territorium
5. Kosten monitoren: Überraschungen vermeiden
6. Migration einplanen: Aber nicht over-engineeren

Die Backend-Entscheidung sollte Ihre Feature-Entwicklung beschleunigen – nicht bremsen. Wählen Sie die einfachste Lösung, die Ihre Anforderungen erfüllt.

---

Backend-Architektur ist ein Thema, bei dem Erfahrung zählt – nicht Theorie. Ich habe Backends gebaut, die mit 10 Nutzern gestartet sind und auf 500.000+ skaliert haben. Die Fehler habe ich gemacht, damit Sie sie nicht machen müssen.

Mein Angebot: Schicken Sie mir drei Dinge:

1. Ihre aktuelle Architektur (oder Ihr Plan, falls Greenfield)
2. Ihre erwarteten Nutzerzahlen (aktuell + 12 Monate)
3. Ihre Constraints (Budget, Team, Compliance, Timeline)

Dann bekommen Sie eine kurze Einschätzung, ob Ihre Architektur passt – oder wo Risiken lauern.

📧 E-Mail: die@entwicklerin.net 🌐 Website: www.app-entwicklerin.de

---

Über die Autorin: Carola Schulte entwickelt seit 25+ Jahren Business-Apps für DAX-nahe Konzerne und mittelständische Unternehmen. Backend-Architektur ist kein Selbstzweck – sondern die Grundlage für schnelle Feature-Entwicklung und ruhige Nächte.