Qu'est-ce que l'overfetching et l'underfetching ?

L’overfetching est un problème d’API où les réponses contiennent plus de données que nécessaire ; l’underfetching impose des requêtes en plus pour compléter. Ce sont les deux modes de défaillance jumeaux des formes de réponse figées — l’un gaspille des octets, l’autre des allers-retours — et la plupart des API commettent les deux sur le même écran : chaque réponse trop lourde, et bien trop de réponses.

Points clés

Un écran, trois façons de le récupérer

Une liste de posts qui affiche chaque titre avec le nom de son auteur :

Overfetching                          Underfetching
GET /posts                            GET /posts            (IDs d'auteur uniquement)
→ 20 posts × 40 champs                GET /users/11  ┐
→ ~160 KB expédiés,                   GET /users/12  │  20 appels de plus —
  ~6 KB affichés (96% de gaspillage)  …              │  la cascade N+1
                                      GET /users/30  ┘

La requête façonnée
GET /posts?fields=title,summary,author&include=author&limit=20
→ 20 posts × 3 champs + leurs auteurs — un aller-retour, ~7 KB

La même requête façonnée en code SDK — projection et relation en une seule requête :

// 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)

Qu’est-ce que l’overfetching ?

L’overfetching est la version, au niveau de l’API, du SELECT * : l’endpoint renvoie sa représentation figée complète, quoi que l’appelant affiche. Les coûts s’empilent par couches. Le serveur sérialise des champs que personne ne lit ; le réseau les transporte — et c’est là que le mobile souffre, puisque le temps de transfert croît avec le nombre d’octets sur une bande passante contrainte et que chaque kilo-octet superflu consomme du forfait data et de la batterie radio ; puis le client parse le tout, car la décompression a lieu avant le rendu et une réponse obèse reste un travail de parsing obèse, même quand la compression l’a masquée sur le réseau.

Le coût le plus discret, c’est l’exposition. Un champ de réponse que l’UI n’affiche jamais n’est qu’à un clic des outils de développement — flags internes, adresses e-mail d’autres utilisateurs, données de marge. L’OWASP API Security Top 10 le recense comme exposition excessive de données (broken object property level authorization) : le moindre privilège s’applique aux corps de réponse, et un champ qu’aucun client ne devrait voir ne devrait jamais être sérialisé.

Qu’est-ce que l’underfetching ?

L’underfetching est le défaut inverse : la forme figée de l’endpoint transporte trop peu, si bien que le client devient intégrateur — récupérer la liste, puis l’auteur de chaque élément, puis peut-être l’avatar de chaque auteur. Chaque appel en plus est un aller-retour complet, et les allers-retours sont la monnaie dont les réseaux mobiles sont les plus démunis : à 100 ms par requête, chiffre réaliste, une liste de 20 éléments résolue séquentiellement consomme deux secondes rien qu’en latence, avant même le moindre calcul de payload.

À grande échelle, cette cascade porte un nom — le problème des requêtes N+1 : un appel pour N éléments, N appels pour leurs détails. La forme est fractale ; elle réapparaît partout où une interface figée rencontre des données relationnelles — clients HTTP face aux endpoints REST, resolvers GraphQL face à la base de données, ORM qui enchaînent les lazy loading dans une boucle — et le remède est toujours une forme de regroupement des N en un.

Overfetching vs. underfetching

Le diagnostic est heureusement mécanique, et aucun article de vulgarisation ne le dit : ouvrez l’onglet réseau sur un écran. Beaucoup de requêtes pour une seule vue, c’est de l’underfetching ; de grosses réponses dont vous ne retrouvez pas les champs dans l’UI, c’est de l’overfetching. L’analytique par endpoint généralise l’audit — taille de payload p95 par endpoint, requêtes par session et par écran.

Corriger les deux sans quitter REST

La migration vers GraphQL n’est pas le premier recours ; les conventions REST matures couvrent l’essentiel de l’écart :

• Sparse fieldsets — un paramètre fields qui projette la représentation : standardisé sous le nom de sparse fieldsets JSON:API, repris par les options de requête de type $select et les builders select() des SDK. Le correctif de l’overfetching à la source.
• Paramètres d’expansion — include=author,comments embarque les ressources liées dans la même réponse (documents composés), transformant une cascade N+1 en une seule requête. Le correctif de l’underfetching à la source.
• Pagination — borne la dimension « liste » de l’overfetching ; les collections non bornées sont des bugs de payload qui grandissent avec l’adoption.
• Endpoints sur mesure et composites — quand un écran a toujours besoin du même agrégat, donnez-lui un endpoint qui renvoie exactement cet agrégat, assemblé côté serveur, là où la latence entre services se compte en microsecondes et non en allers-retours mobiles.
• Un backend-for-frontend — la version architecturale du même geste : une fine couche par client qui dialogue avec des API internes généreuses et sert à chaque frontend exactement sa forme (le pattern BFF de Sam Newman).
• Compression — honnêtement en dernière place : elle réduit ce qui transite, pas le gaspillage ; le coût du parsing et l’exposition lui survivent intacts.

GraphQL règle-t-il le problème ?

En grande partie — et ce « en grande partie » mérite d’être compris. Les selection sets font de la liste de champs du client la requête elle-même, ce qui met à la retraite l’overfetching classique, et les requêtes imbriquées assemblent les données liées en un aller-retour, ce qui met à la retraite l’underfetching classique. C’est exactement pour cela que le débat GraphQL vs. REST commence par ces deux mots.

Les réserves se trouvent une couche plus bas. Les clients qui copient-collent des requêtes généreuses font de l’overfetching par habitude — rien ne garantit qu’une requête corresponde à ce qu’un composant affiche, à moins que l’équipe n’adopte des fragments par composant. Et une chaîne de resolvers naïve fait de l’underfetching face à la base de données : une requête sur 20 posts avec leurs auteurs devient 1 + 20 lectures en base, sauf si les resolvers regroupent via une couche de loading — le même N+1, déplacé. GraphQL déplace le problème vers une couche que vous contrôlez, ce qui est un vrai progrès ; il ne le supprime pas.

Cas d’usage courants

Là où les deux problèmes (et leurs correctifs) apparaissent en premier :

• Écrans de liste sur mobile — l’overfetching canonique : des lignes complètes expédiées pour afficher trois champs par cellule.
• Écrans de détail avec relations — post + auteur + commentaires : cascades d’underfetching, sauf expansion ou endpoint composite.
• Marchés à réseau lent — les deux problèmes taxés au taux maximal ; les requêtes façonnées comme enjeu d’accessibilité.
• Dashboards — des écrans d’agrégats qui font soit de l’overfetching de lignes brutes, soit de l’underfetching à travers cinq services ; le terrain du BFF.
• API publiques aux consommateurs variés — une forme figée ne peut pas convenir à la fois à un cadran de montre et à une console d’administration ; les paramètres de projection et d’expansion laissent chaque appelant ajuster.

Quel problème avez-vous ? Matrice de décision

Limites et trade-offs

• La projection couple les clients aux listes de champs. Un paramètre fields qui diverge de l’UI provoque des bugs de données manquantes ; des types générés et la revue de code gardent les sélections fidèles.
• L’expansion peut surcorriger. Un include=comments sur une liste très sollicitée peut expédier des mégaoctets de relations embarquées — les réponses étendues ont besoin de leur propre pagination et de limites de profondeur.
• Les endpoints sur mesure se multiplient. Les endpoints par écran corrigent la récupération mais créent une facture de maintenance liée à leur prolifération ; les BFF concentrent cette prolifération dans une couche dont quelqu’un est propriétaire, au prix de devoir l’exploiter.
• La flexibilité côté serveur a un prix. Projection et expansion arbitraires compliquent la mise en cache (chaque forme est une clé de cache) et l’autorisation (chaque combinaison doit pouvoir être servie sans risque).
• Ces problèmes sont aussi des signaux de modélisation. Un écran qui exige un élagage profond ou cinq includes vous dit peut-être que les formes des ressources sont mauvaises — parfois, le remède est le modèle de données, pas la récupération.

Overfetching et underfetching sur Back4app

Back4app est une plateforme open-source de Backend as a Service (BaaS) qui combine une base de données gérée, des API REST et GraphQL générées automatiquement, l’authentification, le stockage de fichiers et des fonctions serverless avec Cloud Code. Les deux correctifs sont livrés comme primitives de requête dans chaque SDK — les onglets de code ci-dessus constituent tout le pattern : select() est le sparse fieldset, include() est le paramètre d’expansion, et ensemble ils transforment une cascade 1 + N en un seul aller-retour façonné vers l’API REST générée automatiquement. Quand les clients veulent un contrôle total sur la forme de la réponse, les mêmes données sont interrogeables via les selection sets GraphQL ; quand un écran a besoin d’un agrégat côté serveur, une fonction Cloud Code est un endpoint composite que vous écrivez dans un seul fichier. La récupération épouse l’écran — par l’idiome, pas par la refonte des endpoints.