Por que caching e rate limiting são mais difíceis em GraphQL
Pergunta
Por que as estratégias de caching HTTP e de rate limiting que funcionam em REST não se traduzem direto pra GraphQL?
Resposta esperada
Caching: REST usa GET com URLs distintas por recurso, então caches HTTP (CDN, browser, proxy) funcionam de graça por URL + `Cache-Control`/ETag. GraphQL manda quase tudo por POST num único endpoint, com o que se quer no corpo — o cache HTTP por URL não serve. Soluções ficam na aplicação: cache por objeto normalizado no cliente (Apollo/urql), persisted queries pra viabilizar GET+CDN, ou cache no servidor por resolver. Rate limiting: contar requisições não faz sentido quando uma requisição pode pedir 3 campos ou 50.000 registros aninhados. Você precisa de análise de custo/complexidade da query (profundidade máxima, custo por campo, número de nós) e limitar por 'orçamento' de custo, não por contagem.
Por que perguntam isso
Pergunta sênior. Termos que indicam experiência: 'persisted queries', 'query cost analysis', 'depth limiting'.