Mobile-App-Backend, APIs und Offline-Sync: eine Architektur fuer zuverlaessig funktionierende Apps

Dieser Leitfaden richtet sich an CTOs, technische Leads und Product Owner, die die Serverseite einer App planen. Unser Leitfaden zur mobilen Produktentwicklung behandelt den gesamten Weg von der Discovery bis zur Skalierung in Kuerze; diese Seite geht tiefer auf das Backend, den API-Vertrag und die Offline-Synchronisation ein. Wie die App selbst gebaut wird, wird in Native vs. Cross-Platform Mobile Development verglichen.

In diesem Leitfaden

• Was ein Mobile-Backend leisten muss, was eine Website nicht muss
• Der API-Vertrag fuer mobile Clients
• Offline-Sync: vier Modelle
• Konflikte und wer entscheidet
• Anmeldung, Push und Geraetesicherheit
• Backend-Routen: Alternativen und Auswahlkriterien
• KI-Funktionen und das Backend
• Ein Bauplan
• Wie Netbase Mobile-Backends baut
• Was es als Lieferergebnis gibt und was nicht
• Grenzen dieses Leitfadens
• Haeufig gestellte Fragen
• Naechster Schritt

Was ein Mobile-Backend leisten muss, was eine Website nicht muss

Eine Website aendert sich fuer jeden Besucher, sobald Sie deployen. Eine mobile App nicht: Nutzer aktualisieren, wann sie moechten, und manche tun es nie. Drei Konsequenzen praegen das Backend.

• Viele Client-Versionen gleichzeitig. Der Server muss jede App-Version beantworten, die Sie noch unterstuetzen. Ein umbenanntes Feld oder ein neuer Pflichtparameter kann tausende installierter Apps ueber Nacht unbrauchbar machen.
• Netzwerke, die auf halbem Weg versagen. Eine Anfrage kann den Server erreichen, aber die Antwort auf dem Rueckweg verloren gehen. Die App wiederholt die Anfrage, und ein unachtsames Backend erstellt eine zweite Bestellung oder eine zweite Zahlung.
• Arbeit, die ohne Serververbindung stattfindet. Aussendienst-Mitarbeiter, Reisende und Kaeufer in Kellern oeffnen die App ohne Signal und erwarten, dass sie funktioniert, und dass ihre Aenderungen spaeter ankommen, ohne die Daten anderer zu ueberschreiben.

Der API-Vertrag fuer mobile Clients

Behandeln Sie die API als eigenstaendiges Produkt mit eigenen Regeln, nicht als Nebenprodukt des Web-Frontends.

• Bewusst versionieren. Felder koennen frei hinzugefuegt werden, aber keines darf entfernt oder umbenannt werden, solange eine unterstuetzte App-Version es liest. Grundlegende Aenderungen kommen hinter eine neue Version; veroeffentlichen Sie eine Mindest-App-Version und lassen Sie das Backend aeltere Apps zum Update auffordern.
• Antworten fuer den Bildschirm gestalten. Ein Backend-for-Frontend-Layer, ein schlanker Service, der genau das zusammenstellt, was ein Bildschirm braucht, spart Round-Trips in langsamen Netzwerken und haelt interne Systeme aus dem Blickfeld der App.
• Mit Cursors paginieren. Paginieren Sie Listen mit einem Cursor statt mit einem Offset, damit Datensaetze, die waehrend des Scrollens hinzugefuegt werden, nicht doppelt angezeigt oder uebersprungen werden.
• Creates sicher wiederholbar machen. RFC 9110 definiert POST als nicht idempotent; daher traegt jedes Create-Request einen auf dem Geraet erzeugten Idempotency-Key. Der Server speichert ihn mit dem Ergebnis und gibt bei einer Wiederholung das erste Ergebnis zurueck.
• Nur senden, was das Geraet braucht. Bilder geraetespezifisch in der Groesse anpassen, Antworten komprimieren und nur geaenderte Datensaetze seit dem letzten Sync-Marker der App senden.
• Fehler zurueckgeben, auf die die App reagieren kann. Ein stabiler Fehlercode teilt der App mit, ob sie einen Retry starten, sich neu authentifizieren oder abbrechen soll.

Wenn dasselbe Backend auch die Website, Partner und interne Systeme bedient, sind die Regeln fuer diese Flows in unserem Leitfaden zur Enterprise-Systemintegration beschrieben.

Offline-Sync: vier Modelle

Waehlen Sie ein Modell je Datentyp: Ein Katalog, ein Entwurfsformular und eine Zahlung benoetigen unterschiedliche Garantien.

• Nur online, mit Read-Cache. Die App zeigt die zuletzt abgerufenen Daten und blockiert Aenderungen im Offline-Modus. Richtig fuer Preise, Lagerbestand und alles, was aktuell sein muss.
• Queued Writes. Aenderungen werden in einer ausgehenden Warteschlange gespeichert und der Reihe nach gesendet, wenn die Verbindung zurueckkommt. Der Offline-First-Leitfaden von Android nennt dieses Muster fuer Daten wie Analytics-Events und Logs.
• Local-First-Daten. Die App liest und schreibt eine lokale Datenbank, und ein Sync-Prozess tauscht Aenderungen mit dem Server aus. Der Leitfaden von Android bezeichnet die lokale Quelle als die massgebliche Quelle der Wahrheit fuer die App; dies eignet sich fuer Notizen, Inspektionen und Felddaten.
• Ein verwalteter Sync-Service. Eine Plattform haelt eine lokale Datenbank und die Serverkopie synchron und uebernimmt die Konfliktbehandlung, zum Preis der Uebernahme ihres Datenmodells.

Der Sync selbst laeuft entweder auf Anfrage (Pull) oder mit Server-Benachrichtigungen an die App ueber Aenderungen (Push); der Leitfaden von Android empfiehlt Pull fuer kurze Offline-Phasen und Push fuer lange Offline-Perioden und zusammenhaengende Daten.

Konflikte und wer entscheidet

Wenn zwei Personen denselben Datensatz aendern, waehrend eine von ihnen offline ist, muss eine Seite gewinnen. Entscheiden Sie das pro Feld, schriftlich, vor dem ersten Build.

• Last Write Wins. Jede Aenderung traegt einen Zeitstempel, und die neuere wird behalten. Einfach und richtig fuer Daten, die einer Person gehoeren, etwa ein Profil oder ein Entwurf.
• Server entscheidet. Das Backend akzeptiert eine Aenderung nur, wenn der Datensatz noch die Version hat, die das Geraet zuletzt gesehen hat; andernfalls zeigt die App den aktuellen Stand und fragt den Nutzer.
• Merge nach Feld. Aenderungen an verschiedenen Feldern bleiben beide erhalten; nur ein Konflikt am selben Feld erfordert eine Regel.
• Niemals offline. Zahlungen, Lagerreservierungen und Genehmigungen werden vom Server online bestaetigt, unabhaengig davon, was der Rest der App tut.

Fuehren Sie ein Server-Sync-Log mit Geraet, Nutzer, Version und Ergebnis, damit der Support erklaeren kann, was mit einem Datensatz passiert ist.

Anmeldung, Push und Geraetesicherheit

Anmeldung. Eine mobile App kann kein Geheimnis bewahren: IETF RFC 8252 klassifiziert native Apps als oeffentliche Clients und verlangt die PKCE-Erweiterung fuer OAuth, wobei die Anmeldeseite im System-Browser statt in einer eingebetteten Web-View geoeffnet wird. Verwenden Sie kurzlebige Access-Tokens mit Refresh-Tokens, die im sicheren Speicher der Plattform aufbewahrt werden, und bieten Sie zusaetzlich biometrisches Entsperren an.

Push. Firebase Cloud Messaging bezeichnet sich selbst als plattformuebergreifende Messaging-Loesung, mit Notification-Messages, die das System anzeigt, und Data-Messages, die die App selbst verarbeitet. Senden Sie Data-Messages, um der App mitzuteilen, dass sie synchronisieren soll, Notifications fuer das, was der Nutzer sehen muss, und fordern Sie die Berechtigung in einem Moment an, den der Nutzer versteht.

Sicherheit. Der OWASP Mobile Application Security Verification Standard fasst die Kontrollen fuer Storage, Kryptografie, Authentifizierung, Netzwerkkommunikation und Resilienz zusammen. Auf dem Server prueft jeder Endpunkt die Rechte des Nutzers selbst, unabhaengig davon, was die App anzeigt oder verbirgt.

Backend-Routen: Alternativen und Auswahlkriterien

Vier Kriterien entscheiden: Wer besitzt die Daten heute, wie viel des Produkts funktioniert offline, wie viele Systeme muss die App erreichen, und wer betreibt das Backend nachts. Wenn das Backend auch mit einem Store, einem ERP und einem CRM kommunizieren muss, gestalten Sie diese Flows zuerst mit ERP-, CRM- und E-Commerce-Integrationsarchitektur; Netbase's Systems- und API-Integrationsservice baut diesen Layer.

Wie Netbase Mobile-Backends baut

Netbase baut Cross-Platform-Apps mit React Native, einer Rolle, fuer die das Unternehmen seit Langem einstellt, auf dem Stack, der auf unserer Backend-Platforms-Seite beschrieben ist. Teams von 3 bis 30 Personen vereinen Analysten, Architekten, Entwickler, QA und Designer, und die Arbeit beginnt typischerweise innerhalb von 1 bis 2 Wochen nach der Discovery. Die meisten Netbase-Projekte werden auf Festpreisvertraegen geliefert, die nach der Discovery vereinbart werden (siehe dediziertes Team vs. Festpreis), und bei individueller Entwicklung gehoert das erstellte IP dem Kunden. Die Sicherheitspraxis umfasst sichere Code-Reviews, TLS waehrend der Uebertragung und AES im Ruhezustand, rollenbasierte Zugriffskontrolle und MFA fuer Admin-Dashboards. Sehen Sie den Mobile-App-Entwicklungsservice oder den Mobile Product Accelerator, wenn wiederverwendbare Bausteine passen.

Was es als Lieferergebnis gibt und was nicht

• Was es gibt. Der RB-Marketplace-Datensatz beschreibt eine Kunden-Shopping-App, die nach einem API-Audit auf der eigenen API des Marktplatzes aufgebaut wurde, mit Push-Benachrichtigungen, einer mit dem Server synchronisierten Wunschliste und Offline-Browsing, fuer Android mit iOS im erweiterten Scope. Der Dey Page-Datensatz beschreibt eine React Native App fuer iOS und Android auf demselben Backend wie das Web-Verzeichnis, mit Telefon-OTP-Konten, Push und Deep-Links; die Felderfassung mit Offline-Sync laeuft in der mobilen Web-App. Der Reward-Shop-Datensatz beschreibt mobile UI-Komponenten fuer die eigenen Apps des Kunden und die Synchronisation mit den Kundensystemen ueber Webhooks und einen geplanten Sync; der Kunde wird nicht genannt.
• Was es nicht gibt. Keiner dieser Datensaetze veroeffentlicht Downloads, Nutzungsdaten, Verfuegbarkeit, Sync-Volumina oder Fehlerquoten, und der RB-Marketplace-Datensatz nennt kein Framework. Keiner wird als Beweis dafuer angeboten, dass ein Sync-Modell oder eine Backend-Route besser abschneidet.

Grenzen dieses Leitfadens

• Plattformaussagen stammen von den Android-, IETF-, Firebase- und OWASP-Seiten zum Zugriffsdatum; Plattformen aendern sich, pruefen Sie daher die aktuellen Versionen.
• Die Sync-Modelle eignen sich fuer Business-, Commerce- und Field-Apps; Echtzeit-Kollaboration und Spiele erfordern ein eigenes Design.
• Sicherheitspraktiken reduzieren Risiken; sie sind keine Garantie fuer eine bestimmte App oder ein bestimmtes Backend.

Naechster Schritt

Teilen Sie mit, welche Daten Ihre App offline vorhalten muss, von welchen Systemen sie liest und welche App-Versionen bereits im Einsatz sind, und wir vereinbaren ein Loesungsgespraech, um den API-Vertrag und ein Sync-Modell je Datentyp zu erarbeiten. Sie koennen auch den Mobile-App-Entwicklungsservice oder weitere Netbase-Insights ansehen.

Verwandte Leistungen und Lösungen