GraphQL vs REST

APIs REST expõem recursos em URLs fixas, de modo que uma tela que precisa de dados do usuário, das publicações desse usuário e dos comentários dessas publicações precisa disparar três requisições HTTP sequenciais: GET /users/42, GET /users/42/posts, GET /posts/7/comments. Cada resposta traz todos os campos definidos pelo servidor, comumente 10 a 20 campos por objeto, quando o cliente pode precisar de apenas 3 ou 4. O excesso de dados se multiplica em redes móveis, e a estrutura em cascata (cada requisição bloqueada pela resposta anterior) acrescenta latência proporcional ao tempo de ida e volta — tipicamente 50 a 150 ms por salto em uma conexão 4G.

O GraphQL colapsa as três requisições em um único POST /graphql contendo uma consulta tipada que nomeia exatamente os campos necessários. A camada de resolvers do servidor distribui a consulta às fontes de dados em paralelo, retornando uma única resposta JSON com a forma desejada. A contrapartida é que o cache HTTP via GET (CDN e navegador) deixa de se aplicar sem o uso de Consultas Persistidas Automáticas (APQ), pois corpos de POST não são cacheados por padrão. O problema N+1 migra do cliente (múltiplas buscas) para o servidor (chamadas de resolver por item) e deve ser resolvido com ferramentas de agrupamento como o DataLoader do Facebook, que consolida N consultas individuais ao banco em uma única chamada com cláusula IN. A introspecção de tipos, os contratos de esquema fortemente tipados e as relações em grafo tornam o GraphQL atraente para equipes de produto com muitas superfícies consumidoras, mas adicionam uma sobrecarga de governança de esquema ausente em APIs REST simples.