GitHub

GraphQL entrou no vocabulário de produto como uma promessa sedutora: o cliente pede exatamente os dados de que precisa, nada além, em uma única requisição. Para apps mobile, onde cada byte e cada round-trip de rede contam, soa como a solução perfeita. E em muitos casos é.

O problema é que a conversa sobre GraphQL quase sempre ignora a coluna de custos. A promessa é discutida em detalhe; o preço, raramente. E o preço de GraphQL não está na licença, é open-source, mas em complexidade, em infraestrutura e em tempo de time. Esses custos são reais e decidem se a adoção vale ou vira arrependimento.

Este texto é um checklist para quem está perto de decidir adotar GraphQL em um aplicativo. Antes de migrar, percorra estes pontos. Eles separam a decisão madura do hype caro.

Por que o custo de GraphQL é invisível no começo

GraphQL não cobra licença, então parece grátis. Essa é a armadilha. O custo aparece depois, distribuído em lugares que a decisão inicial não olhou: o tempo para o time aprender, a infraestrutura de cache que fica mais complexa, o esforço de monitorar e proteger queries que podem ficar pesadas.

Diferente de uma assinatura de SaaS, esse custo não vem numa fatura. Vem em velocidade de entrega mais lenta no início, em bugs de performance, em horas de engenharia. Por isso ele escapa da planilha, e por isso o checklist abaixo importa tanto.

Checklist de adoção

Antes de assinar embaixo, responda honestamente a cada item.

O problema que você tem é de fato um problema de GraphQL?

GraphQL brilha quando o app consome dados de muitas fontes, quando telas diferentes precisam de combinações diferentes dos mesmos dados, ou quando o over-fetching de uma API REST está pesando na rede mobile. Se o seu app tem poucos endpoints estáveis e bem desenhados, GraphQL pode ser solução para um problema que você não tem. Custo sem retorno.

O time tem capacidade de aprender?

GraphQL traz conceitos novos: schema, resolvers, o problema de N+1 queries, caching diferente do REST. O custo de aprendizado é real e a curva, não trivial. Se o time é pequeno e está sobrecarregado, esse custo pode atrasar entregas por meses. Inclua a curva de aprendizado na conta, ela é parte do preço.

Você está preparado para o custo de performance no servidor?

A flexibilidade de GraphQL no cliente vira complexidade no servidor. Uma query mal escrita pode disparar dezenas de consultas ao banco, o clássico problema de N+1. Resolver isso exige ferramentas como DataLoader e disciplina de resolvers. Sem isso, GraphQL pode deixar seu backend mais lento, não mais rápido. Esse é um custo de engenharia recorrente.

Como fica o cache?

No REST, o cache de HTTP é maduro e barato, CDNs entendem REST nativamente. No GraphQL, como tudo passa por um único endpoint via POST, o cache tradicional não funciona da mesma forma. Você precisa de caching no nível de cliente (Apollo Client, Relay) e, às vezes, de soluções específicas no servidor. Esse é um custo de infraestrutura e complexidade que o REST não cobra.

Você consegue proteger o endpoint?

A flexibilidade de GraphQL é também uma superfície de ataque. Queries aninhadas profundamente podem ser usadas para sobrecarregar o servidor. Você precisa de limites de profundidade, de complexidade e de rate limiting específicos. No contexto de LGPD, há ainda o cuidado de que um schema mal controlado não exponha dados pessoais que deveriam estar protegidos. Segurança é item obrigatório do checklist, não opcional.

Como precificar a decisão

Some os custos do checklist: tempo de aprendizado do time, esforço de implementação de cache e proteção, complexidade adicional de operação. Compare com o ganho: economia de banda mobile, agilidade de front-end, menos versionamento de API.

Se o seu app sofre de verdade com over-fetching e múltiplas fontes de dados, o ganho supera o custo e GraphQL se paga. Se o seu consumo de dados é simples e estável, o custo supera o ganho, e um REST bem desenhado entrega quase o mesmo valor por uma fração do preço.

A decisão madura não é "GraphQL é melhor". É "GraphQL resolve um problema que tenho, e estou disposto a pagar o preço dele".

O erro mais comum na adoção

O erro recorrente é adotar GraphQL por modismo, não por necessidade. Times migram porque está na moda, pagam todo o custo de complexidade e descobrem que o REST anterior resolvia bem o que precisavam. O custo foi pago; o problema, não existia.

O segundo erro é subestimar o custo operacional contínuo. GraphQL não é "configura e esquece". Exige monitoramento de performance de queries, gestão de schema e atenção à segurança permanentes. Quem adota sem prever esse custo recorrente acaba com um backend frágil e caro de manter.

Você previu o custo de versionamento e evolução?

Um argumento forte a favor de GraphQL é que ele reduz a dor de versionar API. No REST, mudanças costumam exigir novas versões de endpoint, e apps mobile na loja convivem com versões antigas por meses. GraphQL permite evoluir o schema adicionando campos sem quebrar clientes existentes.

Esse é um benefício real e merece entrar no checklist como crédito, não só débito. Para apps mobile, onde você não controla quando o usuário atualiza, essa capacidade de evoluir sem quebrar versões antigas tem valor de negócio concreto: menos forçar atualização, menos suporte a múltiplas versões de API.

Mas há um custo de disciplina embutido. Campos depreciados precisam de uma estratégia de remoção, ou o schema incha com legado que ninguém ousa apagar, o mesmo problema de dívida que afeta feature flags. Sem governança de schema, o benefício de evolução vira passivo de manutenção. O item do checklist, portanto, não é só "GraphQL versiona melhor", e sim "tenho processo para gerir a evolução do schema ao longo do tempo".

A decisão que importa

GraphQL é uma ferramenta excelente para o problema certo e um custo desnecessário para o problema errado. O checklist acima existe para você descobrir em qual caso está antes de pagar a conta, não depois.

Adote se o problema é real, se o time tem fôlego para a curva e se você está pronto para o custo de cache e segurança. Caso contrário, um REST bem feito é mais barato e suficiente. A maturidade está em escolher pela necessidade, não pela manchete.

Se você está avaliando GraphQL para o seu aplicativo e quer percorrer esse checklist aplicado ao seu caso, vale conversar. Há outro artigo no blog sobre GraphQL com exemplos de custo em cenários concretos, além de textos sobre arquitetura de APIs e backend mobile.

GraphQL em aplicativos: custos, preços e um checklist antes de adotar