backend
GraphQL
GraphQL em entrevista testa os trade-offs contra REST: o cliente pede exatamente os campos que quer (acaba com overfetching), mas o servidor herda o problema N+1 nos resolvers (resolvido com DataLoader), caching HTTP deixa de ser trivial, e o rate limiting precisa virar análise de custo de query em vez de contagem de requisições.
Tópicos por senioridade
- Em breve
Perguntas mais cobradas
ver todas →- Médio
O problema N+1 nos resolvers de GraphQL
Resolver de campo aninhado roda 1x por item pai → N queries. DataLoader adia, agrupa todos os ids num `IN (...)`, deduplica e cacheia por request.
- Difícil
Por que caching e rate limiting são mais difíceis em GraphQL
Cache HTTP é por URL+GET; GraphQL é 1 endpoint via POST → cache vai pra aplicação (normalizado no cliente, persisted queries). Rate limit vira análise de custo/complexidade da query, não contagem.
- Médio
Over/underfetching: o que GraphQL resolve e o que ele custa
Cliente pede só os campos que quer, aninhado, numa resposta — mata over e underfetching. Em troca: servidor perde controle do que roda (precisa limite de custo) e erros parciais.
- Médio
Schema-first x code-first
Schema-first: SDL é a fonte da verdade, resolvers têm que casar (contrato legível, mas pode divergir). Code-first: tipos em código geram o SDL (uma fonte, tipos sempre em sincronia, preso à lib).
- Difícil
Erros parciais e o campo `errors` da resposta GraphQL
GraphQL retorna `data` parcial + `errors` (com `path`) em 200 — o cliente checa `errors`, não só o status, e trata por campo. Erros de negócio: pôr num union type de retorno ('errors as data') dá contrato explícito.
- Difícil
Um schema, vários times: schema stitching e federação
Federação: cada serviço define/estende sua parte do schema (subgraph); um gateway compõe tudo e, em runtime, quebra a query em subconsultas e junta. Times independentes, ownership claro; custo de latência e composição.