GraphQL für mobile Apps: Bandbreite und Battery Life optimieren

1. Warum mobile Netzwerke andere Regeln brauchen

Ein Server-zu-Server-Request läuft über eine stabile Kabelverbindung mit praktisch garantierter Bandbreite. Ein mobiles Gerät wechselt dagegen ständig zwischen WLAN, LTE, 5G und Funklöchern, jeder Netzwechsel kostet Zeit und Energie. GraphQL für mobile Apps zu optimieren bedeutet deshalb, zwei Ressourcen gleichzeitig im Blick zu behalten: das übertragene Datenvolumen und die Anzahl der Funkzyklen, die das Mobilfunkmodul aktivieren. Jeder Request, egal wie klein, weckt das Modul aus einem Energiesparzustand auf, das kostet spürbar mehr Akku als die reine Datenübertragung selbst.

Der große strukturelle Vorteil von GraphQL für mobile Apps gegenüber REST liegt im Over-Fetching-Problem. Ein REST-Endpunkt wie /products/42 liefert oft ein komplettes Produktobjekt mit fünfzig Feldern, obwohl der Screen nur vier davon anzeigt. Bei begrenztem mobilen Datenvolumen summiert sich dieser Overhead schnell, besonders bei Listen mit vielen Einträgen. GraphQL erlaubt es, exakt die benötigten Felder anzufordern, was in der Praxis Response-Größen um vierzig bis siebzig Prozent reduzieren kann, je nach Datenmodell.

Dieser Vorteil verpufft aber, wenn GraphQL für mobile Apps naiv eingesetzt wird, etwa mit riesigen Queries, die vorsichtshalber alle möglicherweise benötigten Felder laden, oder mit aggressivem Polling, das den Funkchip alle paar Sekunden aufweckt. Die folgenden Abschnitte zeigen konkrete Patterns, mit denen sich die theoretischen Vorteile von GraphQL tatsächlich in gemessene Bandbreiten- und Akkueinsparungen übersetzen lassen.

2. Query-Design: nur laden, was der Screen wirklich zeigt

Der erste und wichtigste Hebel bei GraphQL für mobile Apps ist Disziplin beim Query-Design. Ein häufiger Fehler in mobilen Teams ist die Wiederverwendung einer großen, generischen Query für mehrere Screens, weil das kurzfristig Entwicklungszeit spart. Das Problem zeigt sich erst in Produktion: Ein Listenscreen, der nur Titel, Thumbnail und Preis braucht, lädt plötzlich Beschreibungstexte, Bewertungen und Metadaten mit, die nirgendwo gerendert werden. Jede Query sollte exakt auf den Screen zugeschnitten sein, der sie verwendet, keinen Bogen mehr.

Fragmente helfen dabei, Wiederverwendung ohne Over-Fetching zu erreichen. Ein ProductCardFragment für die Kachelansicht bleibt bewusst klein, ein separates ProductDetailFragment für die Detailseite lädt zusätzliche Felder nur dort, wo sie gebraucht werden. Bei Bildern lohnt sich zusätzlich, die Bildgröße als Parameter im Schema zu modellieren, sodass der Server bereits passend skalierte Thumbnails ausliefert, statt dass die App ein großes Originalbild herunterlädt und lokal verkleinert.

# BAD: one oversized query reused across list and detail screens,
# loads fields the list screen never renders
query ProductBad($id: ID!) {
  product(id: $id) {
    id
    title
    description
    fullSpecSheet
    reviews { id text rating author { name avatarUrl } }
    priceHistory { date amount }
  }
}

# GOOD: minimal, screen-specific fragment for the list view
fragment ProductCard on Product {
  id
  title
  thumbnailUrl(width: 160)
  priceFormatted
}

query ProductList($first: Int!) {
  products(first: $first) {
    nodes { ...ProductCard }
  }
}

3. Persisted Queries: Query-Text durch eine ID ersetzen

Eine GraphQL-Query kann als Text mehrere Kilobyte groß sein, besonders mit vielen Fragmenten. Bei jedem Request diesen Text erneut über eine mobile Verbindung zu senden, ist reine Verschwendung, der Query-Text ändert sich zwischen Releases praktisch nie. Persisted Queries lösen das: Beim Build wird jede Query gehasht und serverseitig registriert, die App sendet zur Laufzeit nur noch die Hash-ID statt des vollständigen Query-Textes. Der Request schrumpft von mehreren Kilobyte auf wenige Dutzend Byte.

Automatic Persisted Queries, kurz APQ, gehen noch einen Schritt weiter und brauchen keinen separaten Build-Schritt. Beim ersten Aufruf sendet der Client Hash und Query-Text gemeinsam, der Server speichert die Zuordnung, ab dem zweiten Aufruf reicht der Hash allein. Für GraphQL für mobile Apps ist das besonders wertvoll, weil die Einsparung genau bei den Requests greift, die am häufigsten wiederholt werden, etwa beim Pull-to-Refresh einer Liste.

// Apollo Client setup with Automatic Persisted Queries on React Native
import { ApolloClient, InMemoryCache, HttpLink } from '@apollo/client';
import { createPersistedQueryLink } from '@apollo/client/link/persisted-queries';
import { sha256 } from 'crypto-hash';

const persistedQueriesLink = createPersistedQueryLink({ sha256 });
const httpLink = new HttpLink({ uri: 'https://api.mironsoft.de/graphql' });

export const client = new ApolloClient({
  // First request sends hash + query text, later requests send hash only
  link: persistedQueriesLink.concat(httpLink),
  cache: new InMemoryCache(),
});

4. Batching: mehrere Operationen in einem Funkzyklus bündeln

Jedes Aktivieren des Mobilfunkmoduls kostet Energie, unabhängig davon, wie klein die übertragene Datenmenge ist. Wenn ein Screen beim Laden drei separate GraphQL-Requests auslöst, weckt das Gerät den Funkchip dreimal statt einmal auf. Request-Batching bündelt mehrere Operationen in eine einzige HTTP-Anfrage, die der Server dann in einem Rutsch beantwortet. Für GraphQL für mobile Apps ist das einer der wirksamsten Hebel gegen unnötigen Akkuverbrauch, weil die Anzahl der Funkaktivierungen direkt sinkt.

Apollo Client unterstützt Batching über einen konfigurierbaren Zeitfenster-Mechanismus: Requests, die innerhalb weniger Millisekunden ausgelöst werden, sammelt der Client und schickt sie gemeinsam als Array an den Server. Wichtig ist dabei die Balance, ein zu großes Zeitfenster verzögert einzelne Requests spürbar, ein zu kleines Fenster verpasst Batching-Gelegenheiten. In der Praxis funktionieren zehn bis zwanzig Millisekunden für die meisten mobilen Szenarien gut.

// Batch multiple GraphQL operations into a single HTTP request
import { BatchHttpLink } from '@apollo/client/link/batch-http';

const batchLink = new BatchHttpLink({
  uri: 'https://api.mironsoft.de/graphql',
  batchMax: 10,        // max operations per batch
  batchInterval: 15,    // ms window to collect operations before sending
});

export const client = new ApolloClient({
  link: batchLink,
  cache: new InMemoryCache(),
});

// Three separate hooks fired on mount now collapse into ONE radio wakeup
// useQuery(GET_HEADER_DATA)
// useQuery(GET_PRODUCT_LIST)
// useQuery(GET_PROMO_BANNER)

5. Polling, Subscriptions und Push statt ständigem Pull

Polling ist der teuerste Weg, Daten aktuell zu halten. Ein Fünf-Sekunden-Poll-Intervall bedeutet zwölf Funkaktivierungen pro Minute, rund um die Uhr, unabhängig davon, ob sich die Daten überhaupt geändert haben. Für GraphQL für mobile Apps ist die erste Regel deshalb: Polling nur dort einsetzen, wo Echtzeit-Aktualität wirklich nötig ist, etwa bei einem Live-Tracking-Screen, und nirgendwo sonst. Für die meisten Fälle reicht ein Refresh beim App-Wechsel in den Vordergrund völlig aus.

Wo echte Echtzeit gebraucht wird, sind GraphQL Subscriptions über WebSocket meist effizienter als Polling, weil die Verbindung nur einmal aufgebaut wird und danach nur bei tatsächlichen Änderungen Daten fließen. Auf mobilen Geräten hat das allerdings einen Haken: Eine dauerhaft offene WebSocket-Verbindung hält den Funkchip aktiv, statt ihn in einen Energiesparzustand wechseln zu lassen. Für Szenarien mit seltenen, aber wichtigen Updates ist Push über native Mechanismen wie APNs oder FCM oft die energieeffizientere Alternative zu einer dauerhaften GraphQL-Subscription.

6. Kompression und Transport-Feintuning

Ein oft übersehener Hebel bei GraphQL für mobile Apps ist einfache HTTP-Kompression. GraphQL-Responses sind JSON, und JSON komprimiert mit gzip oder brotli typischerweise um sechzig bis achtzig Prozent, besonders bei Listen mit sich wiederholenden Feldnamen. Voraussetzung ist, dass sowohl Server als auch mobiler HTTP-Client Kompression korrekt aushandeln, in der Praxis über den Accept-Encoding-Header und eine passende Server-Konfiguration.

Für die Query-Richtung, also den Request selbst, lohnt sich zusätzlich der Wechsel von GET mit Query-String zu POST mit JSON-Body bei sehr langen, nicht-persistierten Queries, weil manche mobile Netzwerke und Proxys lange URLs schlecht behandeln. Wer HTTP/2 oder HTTP/3 einsetzen kann, profitiert zusätzlich von Multiplexing, mehrere GraphQL-Requests über dieselbe Verbindung sparen den Overhead eines erneuten TLS-Handshakes.

7. Cache-first-Strategien gegen unnötige Requests

Der günstigste Request ist der, der gar nicht erst gestellt wird. Apollo Client und Relay bieten normalisierte Caches, die Objekte anhand ihrer ID über mehrere Queries hinweg wiederverwenden. Für GraphQL für mobile Apps bedeutet das: Ein Produkt, das bereits in der Listenansicht geladen wurde, muss beim Öffnen der Detailseite nicht erneut vollständig angefragt werden, der Cache liefert die bereits bekannten Felder sofort, während im Hintergrund nur die fehlenden Detailfelder nachgeladen werden.

Cache-Policies wie cache-and-network zeigen sofort die zwischengespeicherten Daten und aktualisieren im Hintergrund, während cache-first Requests komplett vermeidet, solange gültige Daten vorliegen. Die richtige Policy hängt vom Datentyp ab: Für sich selten ändernde Stammdaten wie Kategorien ist cache-first mit langer Time-to-live sinnvoll, für Preise oder Lagerbestände ist cache-and-network der bessere Kompromiss zwischen Aktualität und Sparsamkeit.

8. Messen statt Raten: Bandbreite und Akku wirklich beobachten

Alle Optimierungen an GraphQL für mobile Apps sind wertlos, wenn niemand ihre Wirkung misst. Auf iOS liefert Instruments mit dem Energy-Log-Template detaillierte Einblicke, wann und wie oft das Netzwerkmodul aktiv war. Auf Android zeigt Battery Historian den Energieverbrauch pro App-Komponente über Zeit. Beide Tools machen sichtbar, ob eine Optimierung wie Batching tatsächlich die Anzahl der Funkaktivierungen reduziert hat, statt sich auf Vermutungen zu verlassen.

Für die Bandbreitenseite reicht oft schon ein einfacher Vergleich der übertragenen Bytes vor und nach einer Optimierung, etwa über die Netzwerk-Inspektoren in Flipper oder Charles Proxy. Ein sinnvolles Ziel für GraphQL für mobile Apps ist, die durchschnittliche Response-Größe pro Screen-Aufruf als Metrik im Monitoring festzuhalten, ähnlich wie Ladezeiten, damit Regressionen bei neuen Features sofort auffallen, statt erst durch Nutzerbeschwerden über hohen Datenverbrauch entdeckt zu werden.

9. Mobile GraphQL-Strategien im Vergleich

Nicht jede Optimierung passt zu jedem Szenario. Die folgende Übersicht ordnet die wichtigsten Patterns nach Wirkung auf Bandbreite, Akkulaufzeit und Implementierungsaufwand.

In der Praxis lassen sich diese Patterns kombinieren, ohne dass sie sich gegenseitig ausschließen. Ein sinnvoller Startpunkt für GraphQL für mobile Apps ist meist schlankes Query-Design und Cache-Policies, weil beide Aufwand und Wirkung gut ausbalancieren, Persisted Queries und Batching folgen danach als zweite Ausbaustufe.

10. Zusammenfassung

GraphQL für mobile Apps zu optimieren heißt, Bandbreite und Akkulaufzeit als gleichrangige Metriken neben Ladezeit zu behandeln. Schlanke, screenspezifische Queries mit Fragmenten verhindern Over-Fetching, Persisted Queries reduzieren den Request selbst auf wenige Byte, Batching bündelt mehrere Operationen in einen einzigen Funkzyklus. Polling sollte auf echte Echtzeit-Fälle beschränkt bleiben, für alles andere reichen Refresh-Trigger oder Push-Benachrichtigungen.

Cache-first-Strategien mit normalisierten Caches vermeiden Requests komplett, wenn Daten bereits vorliegen, und Kompression reduziert die Größe dessen, was übertragen werden muss. Der wichtigste Punkt bleibt Messung: Ohne Energy-Log-Profiling auf echten Geräten und Bandbreiten-Monitoring pro Screen bleibt jede Optimierung an GraphQL für mobile Apps eine Vermutung statt eines belegten Ergebnisses.

11. FAQ: GraphQL für mobile Apps