REST vs GraphQL: o custo real de cada um
· 7 min
O debate REST vs GraphQL costuma girar em torno de ergonomia pro desenvolvedor, mas as trocas de performance dos dois lados são concretas e frequentemente subestimadas.
O problema que o GraphQL realmente resolve
REST sofre de over-fetching e under-fetching: formatos de resposta fixos por endpoint forçam o cliente ou a receber campos que não usa, ou a fazer várias idas e vindas pra montar o que precisa. GraphQL resolve exatamente isso, deixando o cliente escolher os campos por requisição.
O preço: N+1 controlado pelo cliente
Uma query GraphQL pode pedir relações aninhadas em qualquer profundidade, e a menos que os resolvers do servidor façam batching (como com DataLoader), cada campo aninhado pode disparar uma query por item do nível acima, o mesmo N+1 que ORMs já sofrem, só que agora o formato da consulta (e portanto qual fanout ela dispara) é decidido pelo cliente a cada requisição, muito mais difícil de prever e cachear do lado do servidor.
Cache HTTP fica mais difícil
REST se apoia em cache de HTTP (GET + URL como chave de cache, amigável a CDN) que não se traduz direto pro GraphQL, já que a maior parte do tráfego GraphQL é POST com corpo de query. Cachear exige ou queries persistidas, ou um cache de aplicação com chave composta pela query resolvida mais as variáveis.
Como equilibrar isso na prática
O custo do GraphQL é administrável com batching de resolvers, limites de profundidade/complexidade de query pra barrar consultas aninhadas patológicas, e queries persistidas pra recuperar cacheabilidade, mas nada disso é de graça, é trabalho de engenharia que REST não exige por padrão.