GitHub

Discutir GraphQL no abstrato leva a conclusões inúteis. "É mais eficiente", dizem os entusiastas. "É mais complexo", respondem os céticos. Os dois estão certos, e por isso a discussão não anda. O custo de GraphQL não é uma propriedade fixa, ele depende inteiramente do tipo de app, do volume de dados e da maturidade do time.

A única forma honesta de entender esses custos é olhar cenários concretos. Onde, exatamente, GraphQL economiza? Onde, exatamente, ele cobra um preço que o REST não cobraria? E quanto isso pesa na conta final?

Este texto percorre três cenários reais de aplicativos para mostrar como a equação de custo de GraphQL muda conforme o caso. Não é teoria, é a anatomia do preço em situações que você reconhece.

Cenário 1: o app de feed social, onde GraphQL economiza

Imagine um app de rede social com um feed que mostra, para cada post, o autor, a foto, os comentários, a contagem de curtidas e se o usuário atual curtiu. Numa API REST tradicional, montar uma tela dessas costuma exigir várias chamadas: uma para os posts, outra para os autores, outra para os comentários.

Em rede mobile instável, cada round-trip extra é latência que o usuário sente. E como o endpoint REST devolve o objeto inteiro, o app baixa campos que nem usa, over-fetching que consome banda do plano de dados do usuário.

GraphQL economiza de verdade aqui. Uma única query traz exatamente os campos que a tela precisa, de todas as entidades, em uma requisição. O ganho em banda e em latência é tangível, e a experiência no mobile melhora visivelmente. Aqui, o custo de complexidade de GraphQL se paga, porque o problema que ele resolve, over-fetching e múltiplas chamadas, é exatamente a dor do app.

O preço pago neste cenário é a curva de aprendizado inicial e a montagem dos resolvers. Mas como o ganho é recorrente, em cada carregamento de feed de cada usuário, o investimento se amortiza rápido.

Cenário 2: o app interno simples, onde GraphQL custa caro à toa

Agora pense num app interno de uma prefeitura para registro de ocorrências de zeladoria urbana. Telas simples, poucos tipos de dado, fluxo direto: listar ocorrências, ver detalhe, criar nova. Pouca variação no que cada tela consome.

Adotar GraphQL aqui é pagar caro por nada. O app não sofre de over-fetching relevante nem de múltiplas fontes de dados. Um REST com meia dúzia de endpoints resolveria com simplicidade, cache de HTTP nativo e uma curva de aprendizado próxima de zero para qualquer dev.

O custo de GraphQL aqui é puro peso: a equipe precisa aprender schema e resolvers, lidar com cache que não funciona como o do REST, e proteger um endpoint flexível que não precisava ser flexível. Tudo isso para um produto cuja complexidade de dados não justifica. É o exemplo clássico de pagar o preço sem receber o benefício.

A lição do cenário: GraphQL não é melhor em absoluto. Para apps de dados simples e estáveis, ele é uma conta a mais sem retorno.

Cenário 3: o e-commerce em crescimento, onde o custo escondido morde

Considere um app de e-commerce que adotou GraphQL na fase certa, mas cresceu rápido. As queries que antes eram leves agora atravessam catálogo, estoque, preços personalizados e recomendações. Um cliente abre a home e dispara uma query que, no servidor, vira dezenas de consultas ao banco, o clássico problema de N+1.

O custo escondido de GraphQL aparece aqui em forma de conta de infraestrutura e de incidentes de performance. O que parecia eficiente no cliente virou pressão no backend. Resolver exige investir em DataLoader para agrupar consultas, em monitoramento de complexidade de queries e em limites de profundidade, um custo de engenharia que não estava na conta inicial.

Há ainda o custo de segurança que cresce com a escala. Um endpoint GraphQL exposto sem limites pode ser usado para queries deliberadamente pesadas que derrubam o servidor. E, no contexto da LGPD, um schema que cresceu sem governança pode acabar oferecendo, por caminhos aninhados, acesso a dados pessoais que deveriam estar restritos. Auditar o schema vira custo recorrente.

A lição: o custo de GraphQL não é só de adoção; é de operação contínua, e ele cresce com o sucesso do app.

O que os três cenários ensinam juntos

Comparando os três, o padrão fica claro. GraphQL economiza quando o problema é over-fetching e múltiplas fontes, o feed social. Custa à toa quando os dados são simples, o app da prefeitura. E cobra um preço crescente de operação quando o app escala sem disciplina, o e-commerce.

O custo, portanto, não é uma característica do GraphQL. É uma função do encaixe entre a ferramenta e o problema, e da maturidade com que o time opera a ferramenta ao longo do tempo.

Um exemplo de custo de migração: o REST que virou GraphQL

Vale um quarto cenário, porque a decisão raramente é GraphQL versus REST num campo aberto, quase sempre é migrar de um REST que já existe. Imagine um app de notícias com uma API REST funcional, que decide migrar para GraphQL por causa do over-fetching no feed.

O custo de migração aqui é frequentemente subestimado. Não é só construir o schema novo; é manter o REST antigo no ar enquanto a base de usuários migra para a versão do app que usa GraphQL. Por meses, a empresa opera duas APIs em paralelo, com dobro de superfície de manutenção e de segurança. Esse custo de transição é real e some das comparações que olham só o estado final.

No exemplo, a equipe descobriria que o ganho de eficiência no feed era genuíno, mas que o período de convivência das duas APIs consumiu mais engenharia do que a otimização do feed jamais economizaria no curto prazo. O investimento só se justificava por uma visão de longo prazo, com mais telas migrando para GraphQL ao longo do tempo.

A lição deste exemplo é que o custo de GraphQL inclui o custo de chegar até ele a partir de onde você está. Migrar um app vivo não é trocar uma peça; é operar dois mundos em paralelo até a transição se completar. Quem decide migrar precisa precificar essa travessia, não apenas o destino.

A conclusão honesta

Não existe "GraphQL é caro" ou "GraphQL é barato". Existe "GraphQL é caro ou barato para o seu caso". Os três cenários mostram que a mesma tecnologia pode ser o melhor investimento ou o pior, dependendo do problema que você tem e de como você a opera.

Antes de decidir, encontre o seu cenário entre os três. Se você se reconhece no feed social, vá em frente. Se está mais perto do app da prefeitura, economize. Se está virando o e-commerce, prepare a conta de operação antes que ela apareça sozinha.

Se você está pesando GraphQL para o seu aplicativo e quer mapear em qual cenário o seu caso se encaixa, vale conversar. Há outro artigo no blog com um checklist de adoção de GraphQL, além de textos sobre performance mobile e arquitetura de APIs.