Was sind Overfetching und Underfetching?

Overfetching ist ein API-Problem, bei dem Antworten mehr Daten liefern als der Client braucht; Underfetching erzwingt zusätzliche Anfragen. Es sind die beiden Zwillings-Fehlermodi fest verdrahteter Antwortformen – der eine verschwendet Bytes, der andere Roundtrips – und die meisten APIs leisten sich beide auf demselben Screen: jede Antwort zu fett, und viel zu viele davon.

Das Wichtigste in Kürze

Ein Screen, drei Arten ihn zu laden

Eine Post-Liste, die jeden Titel mit dem Namen seines Autors rendert:

Overfetching                          Underfetching
GET /posts                            GET /posts            (nur Autoren-IDs)
→ 20 Posts × 40 Felder                GET /users/11  ┐
→ ~160 KB gesendet,                   GET /users/12  │  20 weitere Aufrufe –
  ~6 KB gerendert (96 % ungenutzt)    …              │  der N+1-Wasserfall
                                      GET /users/30  ┘

Die geformte Query
GET /posts?fields=title,summary,author&include=author&limit=20
→ 20 Posts × 3 Felder + ihre Autoren – ein Roundtrip, ~7 KB

Dieselbe geformte Query als SDK-Code – Projektion und Relation in einer Anfrage:

// JavaScript / Node.js — Back4app JS SDK
// One shaped query: no overfetch, no underfetch
const query = new Parse.Query('Post');
query.select('title', 'summary', 'author'); // only what the screen renders
query.include('author');                    // related object, same response
query.limit(20);                            // bounded page
const posts = await query.find();
// 1 round trip — not 1 list call + 20 author calls (N+1)

// Flutter / Dart — Back4app Flutter SDK
// One shaped query: no overfetch, no underfetch
final query = QueryBuilder<ParseObject>(ParseObject('Post'))
  ..keysToReturn(['title', 'summary', 'author']) // only what the screen renders
  ..includeObject(['author'])                    // related object, same response
  ..setLimit(20);                                // bounded page
final response = await query.query();
// 1 round trip — not 1 list call + 20 author calls (N+1)

// iOS / Swift — Back4app Swift SDK
// One shaped query: no overfetch, no underfetch
let query = Post.query()
  .select("title", "summary", "author") // only what the screen renders
  .include("author")                    // related object, same response
  .limit(20)                            // bounded page
query.find { result in
  // 1 round trip — not 1 list call + 20 author calls (N+1)
  if case .success(let posts) = result { render(posts) }
}

// Android / Kotlin — Back4app Android SDK
// One shaped query: no overfetch, no underfetch
val query = ParseQuery.getQuery<ParseObject>("Post")
query.selectKeys(listOf("title", "summary", "author")) // only what the screen renders
query.include("author")                                // related object, same response
query.limit = 20                                       // bounded page
query.findInBackground { posts, e -> if (e == null) render(posts) }
// 1 round trip — not 1 list call + 20 author calls (N+1)

Was ist Overfetching?

Overfetching ist die API-Variante von SELECT *: Der Endpoint liefert seine vollständige, feste Repräsentation, unabhängig davon, was der Aufrufer rendert. Die Kosten stapeln sich in Schichten. Der Server serialisiert Felder, die niemand liest; das Netz transportiert sie – und genau hier leiden Mobilgeräte, denn die Übertragungszeit skaliert mit den Bytes über begrenzte Bandbreite, und jedes überflüssige Kilobyte kostet Datenvolumen und Funk-Akku; dann parst der Client das Ganze, denn die Dekompression passiert vor dem Rendern, und eine aufgeblähte Antwort bleibt aufgeblähte Parse-Arbeit, selbst wenn die Kompression sie auf der Leitung verborgen hat.

Der leisere Kostenpunkt ist die Offenlegung. Ein Antwortfeld, das die UI nie anzeigt, ist immer noch einen Klick in den Entwicklerwerkzeugen davon entfernt, gelesen zu werden – interne Flags, E-Mail-Adressen anderer Nutzer, Margendaten. Die OWASP API Security Top 10 führen das als übermäßige Datenpreisgabe (Broken Object Property Level Authorization): Das Prinzip der geringsten Rechte gilt auch für Antwort-Bodys, und ein Feld, das kein Client sehen sollte, sollte gar nicht erst serialisiert werden.

Was ist Underfetching?

Underfetching ist der umgekehrte Mangel: Die feste Form des Endpoints trägt zu wenig, also wird der Client zum Integrator – erst die Liste laden, dann den Autor jedes Eintrags, dann vielleicht den Avatar jedes Autors. Jeder zusätzliche Aufruf ist ein vollständiger Roundtrip, und Roundtrips sind die Währung, an der Mobilfunknetze am ärmsten sind: Bei realistischen 100 ms pro Anfrage verbraucht eine Liste mit 20 Einträgen, sequenziell aufgelöst, zwei Sekunden allein für Latenz, bevor auch nur ein Byte Payload gerechnet wurde.

Im großen Maßstab hat dieser Wasserfall einen Namen – das N+1-Problem bei Anfragen: ein Aufruf für N Einträge, N Aufrufe für ihre Details. Die Form ist fraktal; sie taucht überall dort auf, wo eine feste Schnittstelle auf relationale Daten trifft – HTTP-Clients gegen REST-Endpoints, GraphQL-Resolver gegen die Datenbank, ORMs, die sich per Lazy Loading durch eine Schleife hangeln – und die Kur ist immer eine Form von Batching: die N zu einer bündeln.

Overfetching vs. Underfetching

Die Diagnose ist erfreulich mechanisch, und kein Erklärstück sagt es: Öffnen Sie den Netzwerk-Tab auf einem Screen. Viele Anfragen für eine Ansicht bedeuten Underfetching; große Antworten, deren Felder Sie in der UI nicht wiederfinden, bedeuten Overfetching. Endpoint-Analytics verallgemeinern das Audit – p95-Payload-Größe pro Endpoint, Anfragen pro Session und pro Screen.

Beides beheben, ohne REST zu verlassen

Die Migration zu GraphQL ist nicht das erste Mittel; ausgereifte REST-Konventionen decken den größten Teil der Lücke ab:

• Sparse Fieldsets – ein fields-Parameter, der die Repräsentation projiziert: standardisiert als JSON:API Sparse Fieldsets, gespiegelt von Query-Optionen im $select-Stil und den select()-Buildern der SDKs. Die Overfetching-Lösung an der Quelle.
• Expansionsparameter – include=author,comments bettet zugehörige Ressourcen in dieselbe Antwort ein (zusammengesetzte Dokumente) und verwandelt einen N+1-Wasserfall in eine einzige Anfrage. Die Underfetching-Lösung an der Quelle.
• Paginierung – begrenzt die Listendimension des Overfetchings; unbegrenzte Kollektionen sind Payload-Bugs, die mit der Verbreitung wachsen.
• Zweckgebaute und Composite-Endpoints – wenn ein Screen immer dasselbe Aggregat braucht, geben Sie ihm einen Endpoint, der genau dieses Aggregat liefert, serverseitig zusammengesetzt, wo die Latenz zwischen Diensten in Mikrosekunden gemessen wird und nicht in mobilen Roundtrips.
• Ein Backend-for-Frontend – die architektonische Fassung derselben Bewegung: eine dünne Schicht pro Client, die mit großzügigen internen APIs spricht und jedem Frontend genau seine Form serviert (das BFF-Muster von Sam Newman).
• Kompression – ehrlicherweise auf dem letzten Platz: Sie verkleinert die Leitung, nicht die Verschwendung; Parse-Kosten und Offenlegung überleben sie unbeschadet.

Löst GraphQL das Problem?

Größtenteils – und dieses “größtenteils” lohnt sich zu kennen. Selection Sets machen die Feldliste des Clients zur Anfrage selbst, was klassisches Overfetching in Rente schickt, und verschachtelte Queries setzen zusammengehörige Daten in einem Roundtrip zusammen, was klassisches Underfetching in Rente schickt. Genau deshalb beginnt die Debatte GraphQL vs. REST mit diesen beiden Wörtern.

Die Vorbehalte wohnen eine Schicht tiefer. Clients, die großzügige Queries per Copy-and-paste übernehmen, betreiben Overfetching aus Gewohnheit – nichts erzwingt, dass eine Query zu dem passt, was eine Komponente rendert, solange das Team keine Fragmente pro Komponente einführt. Und eine naive Resolver-Kette betreibt Underfetching gegenüber der Datenbank: Eine Query nach 20 Posts mit ihren Autoren wird zu 1 + 20 Lesevorgängen in der Datenbank, sofern die Resolver nicht über eine Loading-Schicht bündeln – dasselbe N+1, nur umgezogen. GraphQL verschiebt das Problem auf eine Schicht, die Sie kontrollieren, und das ist ein echter Fortschritt; es löscht es nicht.

Typische Anwendungsfälle

Wo die beiden Probleme (und ihre Lösungen) zuerst auftauchen:

• Mobile Listen-Screens – das kanonische Overfetching: vollständige Zeilen übertragen, um drei Felder pro Zelle zu rendern.
• Detail-Screens mit Relationen – Post + Autor + Kommentare: Underfetching-Wasserfälle, sofern nicht expandiert oder zusammengefasst wird.
• Märkte mit langsamen Netzen – beide Probleme zum Höchstsatz besteuert; geformte Queries als Frage der Zugänglichkeit.
• Dashboards – Aggregat-Screens, die entweder rohe Zeilen overfetchen oder über fünf Dienste hinweg underfetchen; BFF-Terrain.
• Öffentliche APIs mit vielfältigen Konsumenten – eine feste Form passt nicht zugleich auf ein Uhren-Display und eine Admin-Konsole; Projektions- und Expansionsparameter lassen jeden Aufrufer nachjustieren.

Welches Problem haben Sie? Eine Entscheidungsmatrix

Grenzen und Trade-offs

• Projektion koppelt Clients an Feldlisten. Ein fields-Parameter, der von der UI abdriftet, verursacht Bugs durch fehlende Daten; generierte Typen und Code-Review halten die Auswahl ehrlich.
• Expansion kann überkorrigieren. Ein include=comments auf einer stark frequentierten Liste kann Megabytes eingebetteter Relationen übertragen – expandierte Antworten brauchen ihre eigene Paginierung und Tiefenlimits.
• Zweckgebaute Endpoints vermehren sich. Endpoints pro Screen beheben das Laden und erzeugen eine Wartungsrechnung durch Endpoint-Wildwuchs; BFFs bündeln diesen Wildwuchs in einer Schicht mit klarem Eigentümer, zum Preis, sie betreiben zu müssen.
• Serverseitige Flexibilität hat einen Preis. Beliebige Projektion und Expansion verkomplizieren das Caching (jede Form ist ein Cache-Schlüssel) und die Autorisierung (jede Kombination muss sicher auslieferbar sein).
• Die Probleme sind auch Modellierungssignale. Ein Screen, der tiefes Beschneiden oder fünf Includes braucht, sagt Ihnen vielleicht, dass die Ressourcenformen falsch sind – manchmal ist die Lösung das Datenmodell, nicht das Laden.

Overfetching und Underfetching mit Back4app

Back4app ist eine Open-Source-Plattform für Backend as a Service (BaaS), die eine verwaltete Datenbank, automatisch generierte REST- und GraphQL-APIs, Authentifizierung, Dateispeicher und Serverless-Funktionen mit Cloud Code kombiniert. Beide Lösungen kommen als Query-Primitive in jedem SDK – die Code-Tabs oben sind das ganze Muster: select() ist das Sparse Fieldset, include() ist der Expansionsparameter, und zusammen verwandeln sie einen 1 + N-Wasserfall in einen einzigen geformten Roundtrip gegen die automatisch generierte REST-API. Wenn Clients die volle Kontrolle über die Antwortform wollen, sind dieselben Daten über GraphQL-Selection-Sets abfragbar; wenn ein Screen ein serverseitiges Aggregat braucht, ist eine Cloud-Code-Funktion ein Composite-Endpoint, den Sie in einer einzigen Datei schreiben. Das Laden passt zum Screen – durch Idiom, nicht durch einen Neuentwurf der Endpoints.