Che cosa sono l'overfetching e l'underfetching?

L’overfetching è un problema delle API in cui le risposte portano più dati del necessario; l’underfetching impone richieste in più per averne abbastanza. Sono le due modalità di guasto gemelle delle forme di risposta fisse – una spreca byte, l’altra round trip – e la maggior parte delle API commette entrambe sulla stessa schermata: ogni risposta troppo pesante, e troppe risposte.

Punti chiave

Una schermata, tre modi di recuperarla

Una lista di post che mostra ogni titolo con il nome del suo autore:

Overfetching                          Underfetching
GET /posts                            GET /posts            (solo ID autore)
→ 20 post × 40 campi                  GET /users/11  ┐
→ ~160 KB spediti,                    GET /users/12  │  20 chiamate in più –
  ~6 KB mostrati (96 % di spreco)     …              │  la cascata N+1
                                      GET /users/30  ┘

La query modellata
GET /posts?fields=title,summary,author&include=author&limit=20
→ 20 post × 3 campi + i loro autori – un round trip, ~7 KB

La stessa query modellata in codice SDK – proiezione e relazione in una sola richiesta:

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

Che cos’è l’overfetching?

L’overfetching è la versione del SELECT * a livello di API: l’endpoint restituisce la sua rappresentazione fissa completa, qualunque cosa mostri il chiamante. I costi si impilano a strati. Il server serializza campi che nessuno legge; la rete li trasporta – ed è qui che il mobile soffre, perché il tempo di trasferimento cresce con i byte su una banda limitata e ogni kilobyte superfluo consuma traffico dati a pagamento e batteria per la radio; poi il client analizza tutto quanto, perché la decompressione avviene prima del rendering e una risposta obesa resta un lavoro di parsing obeso anche quando la compressione l’ha nascosta in transito.

Il costo più silenzioso è l’esposizione. Un campo di risposta che la UI non mostra mai è comunque a un clic degli strumenti per sviluppatori – flag interni, indirizzi e-mail di altri utenti, dati sui margini. L’OWASP API Security Top 10 lo censisce come esposizione eccessiva di dati (broken object property level authorization): il privilegio minimo si applica ai corpi delle risposte, e un campo che nessun client dovrebbe vedere non andrebbe serializzato affatto.

Che cos’è l’underfetching?

L’underfetching è la carenza opposta: la forma fissa dell’endpoint porta troppo poco, così il client diventa un integratore – recuperare la lista, poi l’autore di ogni elemento, poi magari l’avatar di ogni autore. Ogni chiamata in più è un round trip completo, e i round trip sono la valuta di cui le reti mobili sono più povere: a 100 ms per richiesta, cifra realistica, una lista di 20 elementi risolta in sequenza consuma due secondi di sola latenza, prima di qualunque calcolo sul payload.

Su larga scala questa cascata ha un nome – il problema delle richieste N+1: una chiamata per N elementi, N chiamate per i loro dettagli. La forma è frattale; riappare dove un’interfaccia fissa incontra dati relazionali – client HTTP verso endpoint REST, resolver GraphQL verso il database, ORM che si trascinano in lazy loading dentro un ciclo – e il rimedio è sempre una forma di batching degli N in uno.

Overfetching vs. underfetching

La diagnosi è per fortuna meccanica, e nessun articolo divulgativo lo dice: basta aprire il pannello di rete su una schermata. Molte richieste per una sola vista significano underfetching; risposte grosse i cui campi non si ritrovano nella UI significano overfetching. L’analisi per endpoint generalizza l’audit – dimensione p95 del payload per endpoint, richieste per sessione e per schermata.

Correggere entrambi senza abbandonare REST

La migrazione a GraphQL non è la prima strada da tentare; le convenzioni REST mature coprono la maggior parte del divario:

• Sparse fieldsets – un parametro fields che proietta la rappresentazione: standardizzato come sparse fieldsets JSON:API, ripreso dalle opzioni di query in stile $select e dai builder select() degli SDK. La soluzione dell’overfetching alla fonte.
• Parametri di espansione – include=author,comments incorpora le risorse collegate nella stessa risposta (documenti composti), trasformando una cascata N+1 in una sola richiesta. La soluzione dell’underfetching alla fonte.
• Paginazione – limita la dimensione “lista” dell’overfetching; le collezioni senza limiti sono bug di payload che crescono con l’adozione.
• Endpoint su misura e compositi – quando una schermata ha sempre bisogno dello stesso aggregato, conviene darle un endpoint che restituisca esattamente quell’aggregato, assemblato sul server, dove la latenza fra servizi si misura in microsecondi e non in round trip mobili.
• Un backend-for-frontend – la versione architetturale della stessa mossa: un livello sottile per client che dialoga con API interne generose e serve a ogni frontend esattamente la sua forma (il pattern BFF di Sam Newman).
• Compressione – onestamente all’ultimo posto: riduce ciò che transita, non lo spreco; il costo del parsing e l’esposizione le sopravvivono intatti.

GraphQL risolve il problema?

In gran parte – e quel “in gran parte” vale la pena di capirlo. I selection sets fanno dell’elenco di campi del client la richiesta stessa, il che mette in pensione l’overfetching classico, e le query annidate assemblano i dati collegati in un round trip, il che mette in pensione l’underfetching classico. È esattamente per questo che il dibattito GraphQL vs. REST comincia da queste due parole.

Le riserve stanno un livello più sotto. I client che copiano e incollano query generose fanno overfetching per abitudine – niente garantisce che una query corrisponda a ciò che mostra un componente, a meno che il team non adotti frammenti per componente. E una catena di resolver ingenua fa underfetching verso il database: una query su 20 post con i loro autori diventa 1 + 20 letture su database, se i resolver non raggruppano attraverso un livello di loading – lo stesso N+1, spostato. GraphQL sposta il problema in un livello sotto il proprio controllo, e questo è un progresso autentico; non lo elimina.

Casi d’uso tipici

Dove i due problemi (e le loro soluzioni) si presentano per primi:

• Schermate di lista su mobile – l’overfetching canonico: righe complete spedite per mostrare tre campi per cella.
• Schermate di dettaglio con relazioni – post + autore + commenti: cascate di underfetching, salvo espansione o endpoint composito.
• Mercati a rete lenta – i due problemi tassati all’aliquota massima; le query modellate come questione di accessibilità.
• Dashboard – schermate di aggregati che fanno overfetching di righe grezze oppure underfetching attraverso cinque servizi; il terreno del BFF.
• API pubbliche con consumatori eterogenei – una forma fissa non può andare bene sia a un quadrante di orologio sia a una console di amministrazione; i parametri di proiezione ed espansione lasciano a ogni chiamante la messa a punto.

Quale dei due problemi c’è? Matrice decisionale

Limiti e trade-off

• La proiezione accoppia i client agli elenchi di campi. Un parametro fields che diverge dalla UI provoca bug di dati mancanti; tipi generati e revisione del codice tengono allineate le selezioni.
• L’espansione può correggere troppo. Un include=comments su una lista molto sollecitata può spedire megabyte di relazioni incorporate – le risposte espanse hanno bisogno di una paginazione propria e di limiti di profondità.
• Gli endpoint su misura si moltiplicano. Gli endpoint per schermata risolvono il recupero ma creano una fattura di manutenzione legata alla loro proliferazione; i BFF concentrano quella proliferazione in un livello di cui qualcuno è proprietario, al prezzo di doverlo gestire.
• La flessibilità sul server ha un prezzo. Proiezione ed espansione arbitrarie complicano la cache (ogni forma è una chiave di cache) e l’autorizzazione (ogni combinazione deve poter essere servita senza rischi).
• Questi problemi sono anche segnali di modellazione. Una schermata che richiede sfoltimenti profondi o cinque include sta forse dicendo che le forme delle risorse sono sbagliate – a volte il rimedio è il modello dei dati, non il recupero.

Overfetching e underfetching su Back4app

Back4app è una piattaforma open-source di Backend as a Service (BaaS) che combina database gestito, API REST e GraphQL generate automaticamente, autenticazione, archiviazione di file e funzioni serverless con Cloud Code. Entrambe le soluzioni arrivano come primitive di query in ogni SDK – le schede di codice qui sopra sono tutto il pattern: select() è lo sparse fieldset, include() è il parametro di espansione, e insieme trasformano una cascata 1 + N in un solo round trip modellato verso l’API REST generata automaticamente. Quando i client vogliono il controllo completo della forma della risposta, gli stessi dati sono interrogabili attraverso i selection sets di GraphQL; quando una schermata ha bisogno di un aggregato sul server, una funzione Cloud Code è un endpoint composito che si scrive in un solo file. Il recupero sposa la schermata – per idioma, non per riprogettazione degli endpoint.