Backend-Integration

Warum Backend-Integration entscheidend ist¶

Eine mobile App ohne Backend-Integration ist eine isolierte Insel. Wert entsteht durch Verbindung — der mobile Client liest Daten aus dem ERP, schreibt ins WMS, synchronisiert mit CRM, empfaengt Benachrichtigungen vom Monitoring. Ohne qualitative Integration ist die mobile App nur ein huebsches Formular.

Integration ist auch die haeufigste Problemquelle. Langsames API, inkonsistente Vertraege, fehlendes Error Handling, Sicherheitsluecken bei der Authentifizierung. Wir bauen eine Integrationsschicht, die schnell, sicher und ausfallresistent ist.

REST API¶

Standard fuer die meisten mobilen Integrationen. Einfach, vorhersagbar, breit unterstuetzt.

API-Design fuer mobile Clients¶

Mobile Clients haben spezifische Anforderungen, die sich von Web-Frontends unterscheiden:

• Minimaler Payload: Mobile Netzwerke sind langsam und teuer. Keine unnoetige Felder, keine verschachtelten Objekte die der Client nicht braucht. Sparse Fieldsets (?fields=id,name,status).
• Paginierung: Cursor-basierte Paginierung fuer stabiles Blaettern bei Datenaenderungen. Offset-basiert fuer einfachere Faelle. Seitengroesse optimiert fuer mobile UI (20-50 Eintraege).
• Caching: ETag und Last-Modified Header. Conditional Requests (If-None-Match, If-Modified-Since). 304 Not Modified spart Bandbreite. Cache-Control fuer explizites TTL.
• Kompression: Gzip/Brotli fuer Response Bodies. Fuer Binaerdaten (Bilder, Dokumente) serverseitiges Resizing nach gewuenschter Aufloesung.

API-Versionierung¶

Mobile Clients koennen nicht alle gleichzeitig aktualisiert werden — ein Benutzer hat moeglicherweise eine monatelang alte Version. Das API muss Rueckwaertskompatibilitaet unterstuetzen:

• URL-Versionierung: /api/v1/orders, /api/v2/orders. Klar, explizit.
• Rueckwaertskompatible Evolution: Neue Felder hinzufuegen, alte nie entfernen. Neue Felder nullable.
• Deprecation Policy: Alte API-Version funktioniert mindestens 6 Monate. Sunset-Header informiert den Client. Analytics zeigt, wie viele Clients die alte Version nutzen.

OpenAPI-Spezifikation¶

API definiert in OpenAPI (Swagger). Aus einer einzigen Spezifikation generieren wir:

• Client-Code: OpenAPI Generator fuer Swift und Kotlin — typsicherer API-Client, kein manuelles Schreiben der Netzwerkschicht
• Dokumentation: Automatisch generiert, immer aktuell
• Mock Server: Frontend-Team entwickelt gegen Mock API ohne auf das Backend zu warten
• Contract Tests: Verifizierung dass die Implementierung der Spezifikation entspricht

GraphQL¶

Wenn der mobile Client flexible Abfragen braucht — verschiedene Bildschirme brauchen verschiedene Daten von denselben Entitaeten.

Wann GraphQL statt REST¶

GraphQL loest zwei REST-Probleme:

1. Over-fetching: Ein REST-Endpunkt gibt das gesamte Objekt zurueck, der Client braucht 3 von 20 Feldern. Mobile Netzwerk uebertraegt unnoetige Daten.
2. Under-fetching: Bestelldetails erfordern Daten von /orders/{id}, /customers/{id}, /products/{ids} — drei Roundtrips. GraphQL loest das in einer Abfrage.

Apollo Client (iOS/Android) mit normalisiertem Cache. Automatische Datendeduplizierung im Cache — Bestelldetail und Bestellliste teilen dieselben Daten. Cache-first-Policy fuer sofortige Antwort, Netzwerk fuer Updates.

Subscriptions fuer Echtzeit¶

GraphQL Subscriptions ueber WebSocket fuer Echtzeitdaten:

• Live-Tracking (Fahrerposition auf Karte)
• Chat-Nachrichten
• Status-Updates (Bestellstatus aendert sich → UI aktualisiert sofort)
• Kollaborative Features

WebSocket und Echtzeit-Kommunikation¶

Fuer Use Cases, bei denen Daten in Echtzeit fliessen und Polling nicht ausreicht.

Echtzeit-Kommunikationsarchitektur¶

Verbindungs-Lebenszyklus: 1. Authentifizierung ueber HTTP (OAuth Token) 2. Upgrade auf WebSocket mit Token 3. Heartbeat (Ping/Pong) fuer Erkennung abgebrochener Verbindungen 4. Automatischer Reconnect mit Exponential Backoff 5. Nachrichten-Queue fuer waehrend des Reconnects gesendete Nachrichten

Socket.IO vs. nativer WebSocket: Socket.IO bietet automatischen Reconnect, Room Management, Fallback auf Long-Polling. Nativer WebSocket fuer leichtgewichtige Szenarien. Wahl abhaengig von Komplexitaet.

Use Cases¶

• Live-Tracking: Fahrer teilt GPS-Position alle 5s. Disposition sieht Position auf Karte in Echtzeit. Geofencing fuer automatische Benachrichtigungen.
• Messaging: In-App Chat, Kundenservice. Typing Indicators, Read Receipts, Zustellungsstatus.
• Kollaboratives Editieren: Mehrere Benutzer bearbeiten dasselbe Dokument. Operational Transform oder CRDT fuer konfliktfreie Synchronisation.
• Live-Dashboards: KPI-Metriken in Echtzeit aktualisiert. Bestellanzahl, Umsatz, Alert-Status.

Authentifizierung und Sicherheit¶

OAuth 2.0 + PKCE¶

Standard fuer mobile Anwendungen. Authorization Code Flow mit PKCE (Proof Key for Code Exchange) — sicherer als Implicit Flow, geeignet fuer Public Clients (mobile Apps koennen Client Secrets nicht sicher speichern).

Token-Management: - Access Token: kurzlebig (15-60 Minuten), im Speicher - Refresh Token: langlebig, im Secure Storage (Keychain/Keystore) - Token-Refresh transparent fuer Benutzer — kein wiederholtes Login - Biometrische Authentifizierung fuer Zugriff auf den Refresh Token

Kommunikationsschutz¶

• TLS 1.3: Gesamte Kommunikation verschluesselt
• Certificate Pinning: App akzeptiert nur Zertifikate mit bestimmtem Public Key. Schutz gegen Man-in-the-Middle auch bei kompromittierter CA
• Zertifikatsrotation: Pinning mit Backup-Pin fuer reibungslose Zertifikatsrotation ohne App-Update
• Request Signing: HMAC-Signatur fuer kritische Operationen (Zahlungen, Genehmigungen)

Secure Storage¶

Tokens, Credentials und sensible Daten niemals im Klartext:

• iOS: Keychain Services mit kSecAttrAccessibleWhenUnlockedThisDeviceOnly
• Android: Android Keystore mit hardware-gestuetzten Schluesseln (StrongBox auf unterstuetzten Geraeten)
• Datenverschluesselung: AES-256 fuer lokale Datenbank mit sensiblen Daten

Error Handling und Resilienz¶

Mobile Netzwerke sind unzuverlaessig. Integration muss resilient sein:

• Retry Policy: Exponential Backoff fuer transiente Fehler (Timeout, 503). Idempotency Key fuer sicheres Retry von Mutationen.
• Circuit Breaker: Nach wiederholten Fehlern stoppt der Circuit Breaker Requests und gibt gecachte Daten zurueck. Recovery Probe prueft periodisch ob das Backend zurueck ist.
• Graceful Degradation: Wenn das Backend nicht verfuegbar ist, arbeitet die App im Offline-Modus. UI kommuniziert Status: „Offline — Daten koennten veraltet sein.”
• Timeout Policy: Connect Timeout 10s, Read Timeout 30s, Write Timeout 30s. Konfigurierbar pro Endpunkt.

Technologie-Stack¶

Networking: URLSession (iOS), OkHttp/Retrofit (Android), Ktor (KMP), Apollo (GraphQL).

Serialisierung: Codable (Swift), kotlinx.serialization, Protocol Buffers, MessagePack.

Auth: AppAuth (OAuth 2.0 + PKCE), Keychain/Keystore, BiometricPrompt/LocalAuthentication.

Echtzeit: Socket.IO, Scarlet (Android), Starscream (iOS), nativer WebSocket.

API-Design: OpenAPI 3.1, GraphQL SDL, Postman/Insomnia, Pact (Contract Testing).

Verwandt mit