O que são overfetching e underfetching?

Overfetching é o problema de API em que respostas carregam mais dados do que o cliente precisa; underfetching força requisições extras para obter o bastante. São os modos de falha gêmeos dos formatos de resposta fixos — um desperdiça bytes, o outro desperdiça round trips — e a maioria das APIs comete os dois na mesma tela: cada resposta gorda demais, e respostas demais.

Principais pontos

Uma tela, três formas de buscá-la

Uma lista de posts que renderiza cada título com o nome do autor:

Overfetching                          Underfetching
GET /posts                            GET /posts            (só IDs de autor)
→ 20 posts × 40 campos                GET /users/11  ┐
→ ~160 KB enviados,                   GET /users/12  │  mais 20 chamadas —
  ~6 KB renderizados (96% desperdício)  …            │  a cascata N+1
                                      GET /users/30  ┘

A query moldada
GET /posts?fields=title,summary,author&include=author&limit=20
→ 20 posts × 3 campos + seus autores — um round trip, ~7 KB

A mesma query moldada como código de SDK — projeção e relação em uma requisição:

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

O que é overfetching?

Overfetching é a versão de camada de API do SELECT *: o endpoint retorna sua representação fixa completa, independentemente do que o chamador renderiza. Os custos se empilham em camadas. O servidor serializa campos que ninguém lê; a rede os carrega — e é aí que o mobile sofre, já que o tempo de transferência escala com bytes sobre banda limitada e cada kilobyte desnecessário gasta franquia de dados e bateria de rádio; depois o cliente parseia tudo, porque a descompressão acontece antes da renderização e uma resposta inchada é trabalho de parsing inchado mesmo quando a compressão a escondeu na rede.

O custo mais silencioso é a exposição. Um campo de resposta que a UI nunca mostra continua a um clique das ferramentas de desenvolvedor de ser lido — flags internas, e-mails de outros usuários, dados de margem. O OWASP API Security Top 10 rastreia isso como exposição excessiva de dados (broken object property level authorization): o menor privilégio se aplica a corpos de resposta, e um campo que nenhum cliente deveria ver não deveria nem ser serializado.

O que é underfetching?

Underfetching é a deficiência oposta: o formato fixo do endpoint carrega de menos, então o cliente vira um integrador — busca a lista, depois o autor de cada item, depois talvez o avatar de cada autor. Cada chamada extra é um round trip completo, e round trips são a moeda de que as redes móveis são mais pobres: a uns realistas 100 ms por requisição, uma lista de 20 itens resolvida sequencialmente gasta dois segundos só de latência, antes de qualquer conta de payload.

Em escala, essa cascata tem nome — o problema de requisições N+1: uma chamada para N itens, N chamadas para seus detalhes. O formato é fractal; recorre onde quer que uma interface fixa encontre dados relacionais — clientes HTTP contra endpoints REST, resolvers GraphQL contra o banco de dados, ORMs abrindo caminho com lazy loading dentro de um loop — e a cura é sempre alguma forma de agrupar os N em um.

Overfetching vs. underfetching

O diagnóstico é misericordiosamente mecânico, e nenhum explainer de ranking diz isso: abra a aba de rede em uma tela. Muitas requisições para uma view é underfetching; respostas grandes cujos campos você não encontra na UI é overfetching. Analytics de endpoint generalizam a auditoria — tamanho de payload p95 por endpoint, requisições por sessão por tela.

Corrigindo os dois sem sair do REST

A migração para GraphQL não é o primeiro recurso; convenções REST maduras cobrem a maior parte da distância:

• Sparse fieldsets — um parâmetro fields que projeta a representação: padronizado como sparse fieldsets do JSON:API, espelhado por opções de query no estilo $select e pelos builders select() dos SDKs. A solução do overfetching na origem.
• Parâmetros de expansão — include=author,comments embute recursos relacionados na mesma resposta (documentos compostos), convertendo uma cascata N+1 em uma requisição. A solução do underfetching na origem.
• Paginação — limita a dimensão de lista do overfetching; coleções sem limite são bugs de payload que crescem com a adoção.
• Endpoints sob medida e compostos — quando uma tela sempre precisa do mesmo agregado, dê a ela um endpoint que retorna exatamente esse agregado, montado no servidor, onde a latência entre serviços é de microssegundos, não de round trips móveis.
• Um backend-for-frontend — a versão arquitetural do mesmo movimento: uma camada fina por cliente que fala com APIs internas generosas e serve a cada frontend exatamente o seu formato (o padrão BFF de Sam Newman).
• Compressão — honesto último lugar: encolhe a transmissão, não o desperdício; custo de parsing e exposição sobrevivem intactos.

O GraphQL resolve o problema?

Em grande parte — e o “em grande parte” vale a pena conhecer. Selection sets tornam a lista de campos do cliente a própria requisição, o que aposenta o overfetching clássico, e queries aninhadas montam dados relacionados em um round trip, o que aposenta o underfetching clássico. É exatamente por isso que o debate GraphQL vs. REST começa com essas duas palavras.

As ressalvas moram uma camada abaixo. Clientes que copiam e colam queries generosas overfetcham por hábito — nada garante que uma query casa com o que um componente renderiza, a menos que o time adote fragments por componente. E uma cadeia ingênua de resolvers underfetcha contra o banco de dados: uma query de 20 posts com autores vira 1 + 20 leituras no banco, a menos que os resolvers agrupem através de uma camada de loading — o mesmo N+1, realocado. O GraphQL move o problema para uma camada que você controla, o que é progresso genuíno; ele não o apaga.

Casos de uso comuns

Onde os dois problemas (e suas soluções) aparecem primeiro:

• Telas de lista no mobile — o overfetch canônico: linhas completas enviadas para renderizar três campos por célula.
• Telas de detalhe com relações — post + autor + comentários: cascatas de underfetch, a menos que expandidas ou compostas.
• Mercados de rede lenta — os dois problemas taxados na alíquota máxima; queries moldadas como acessibilidade.
• Dashboards — telas agregadas que ou overfetcham linhas brutas ou underfetcham através de cinco serviços; território de BFF.
• APIs públicas com consumidores diversos — um formato fixo não serve um mostrador de relógio e um console admin; parâmetros de projeção e expansão deixam cada chamador ajustar.

Qual problema você tem? Matriz de decisão

Limitações e trade-offs

• Projeção acopla clientes a listas de campos. Um param fields que deriva da UI causa bugs de dados faltantes; tipos gerados e review mantêm as seleções honestas.
• Expansão pode corrigir demais. include=comments em uma lista quente pode enviar megabytes de relações embutidas — respostas expandidas precisam de paginação e limites de profundidade próprios.
• Endpoints sob medida se multiplicam. Endpoints por tela consertam a busca e criam uma conta de manutenção de proliferação de endpoints; BFFs concentram essa proliferação em uma camada com dono, ao custo de operá-la.
• Flexibilidade no servidor tem preço. Projeção e expansão arbitrárias complicam o cache (cada formato é uma chave de cache) e a autorização (toda combinação precisa ser segura de servir).
• Os problemas também são sinais de modelagem. Uma tela que precisa de cortes profundos ou cinco includes pode estar dizendo que os formatos dos recursos estão errados — às vezes a solução é o modelo de dados, não a busca.

Overfetching e underfetching no Back4app

O Back4app é uma plataforma open-source de Backend as a Service (BaaS) que combina banco de dados gerenciado, APIs REST e GraphQL geradas automaticamente, autenticação, armazenamento de arquivos e funções serverless com Cloud Code. As duas soluções vêm como primitivos de query em todos os SDKs — as abas de código acima são o padrão inteiro: select() é o sparse fieldset, include() é o parâmetro de expansão, e juntos transformam uma cascata 1 + N em um round trip moldado contra a API REST gerada automaticamente. Quando os clientes querem controle total do formato da resposta, os mesmos dados são consultáveis via selection sets do GraphQL; quando uma tela precisa de um agregado no servidor, uma função de Cloud Code é um endpoint composto que você escreve em um arquivo. A busca casa com a tela — por idioma, não por redesenho de endpoints.