Por que abandonei o GraphQL depois de 6 anos

• Depois de usá-lo por 6 anos, desde 2018, eu era um verdadeiro fã de GraphQL, mas agora estou cético.
• Quero explicar por que não recomendo mais GraphQL e o que considero alternativas melhores.

Superfície de ataque

• O GraphQL expõe uma linguagem de consulta, o que traz o risco de ampliar a superfície de ataque.
• Problemas relacionados à autorização são especialmente importantes.
  • É necessário fazer verificações de autorização adequadas para todos os campos.
  • Em APIs REST, é mais simples verificar a autorização por endpoint.

Autorização

• É preciso verificar as permissões do usuário para todos os campos.
• Em APIs REST, é mais simples verificar a autorização por endpoint.

Limitação de taxa

• Consultas GraphQL não têm limite de tamanho, então podem sobrecarregar bastante o servidor.
• Uma forma de lidar com isso é estimar a complexidade da consulta e limitar consultas que ultrapassem certa complexidade.
• Em APIs REST, é mais simples limitar a quantidade de requisições.

Parsing de consultas

• Strings de consulta malformadas podem consumir memória excessiva do servidor.
• Uma forma de lidar com isso é definir um número máximo de erros para interromper o parsing.

Desempenho

Busca de dados e o problema de N+1

• Resolvedores de campo podem chamar fontes de dados externas várias vezes.
• É possível resolver isso usando o padrão Dataloader.
• No REST, é mais simples resolver o problema de N+1 no controlador.

Autorização e o problema de N+1

• O código de autorização pode causar o problema de N+1.
• No REST, esse problema não ocorre.

Acoplamento

• Em codebases GraphQL, a lógica de negócio fica fortemente acoplada à camada de transporte.
• Testes de integração são necessários, e a depuração é difícil.

Complexidade

• Os vários métodos para resolver problemas de segurança e desempenho do GraphQL aumentam a complexidade da codebase.
• Soluções REST geralmente são mais simples.

Alternativas

• A recomendação é usar APIs REST em JSON com OpenAPI 3.0+.
• Se houver clientes escritos em linguagens com tipagem estática, o OpenAPI pode ser uma escolha melhor.
• O OpenAPI pode gerar automaticamente código de cliente com segurança de tipos.

Opinião do GN⁺

• O GraphQL é poderoso, mas exige muito esforço para resolver problemas de segurança e desempenho.
• APIs REST são relativamente simples e, em muitos casos, podem ser mais adequadas.
• O OpenAPI pode aumentar a produtividade de desenvolvimento ao oferecer segurança de tipos e ferramentas automatizadas.
• Ao adotar GraphQL, é preciso considerar com bastante cuidado as questões de segurança e desempenho.
• É importante comparar as vantagens e desvantagens de REST e GraphQL para escolher a tecnologia mais adequada ao projeto.

[savvykang]

Por que abandonei o GraphQL depois de 6 anos

[yangeok]

Vem aí a era do grande boom do RPC

[ahwjdekf]

Pois é... não dá para sair abraçando e idolatrando qualquer coisa só porque apareceu algo fancy.. agora é a vez do ORM. A sua hora também não está longe...

[rockmkd]

ORM existe há mais de 20 anos...

[cometkim]

Em 2018, PQ já nem era tão novo assim (na verdade, isso já era recomendado desde que o GraphQL foi anunciado pela primeira vez), então é surpreendente que nem tenham tentado por 6 anos...

[surfindia]

É difícil implementar o GraphQL inteiro manualmente, por todos os motivos mencionados acima, tanto em termos de complexidade quanto de estabilidade. Acho que o ideal é desenvolver colocando uma camada como o hasura ou o postgraphile sobre o banco de dados e, conforme a necessidade, adicionar a essa camada tanto GraphQL quanto REST.

[GN⁺]

Comentários do Hacker News

• Depois de adotar GraphQL, enfrentei muitos problemas. Por causa de questões de controle de acesso e desempenho, não quero mais usá-lo. Pode ser bom se for usado só no frontend, mas a integração com o backend é complexa.
• Depois de aprender REST primeiro e usar gRPC, achei atraente ter uma API com segurança de tipos. O GraphQL não traz muitos benefícios e só é útil quando funciona como um banco de dados.
• Trabalhei em dois projetos com GraphQL; no começo, eles começaram pequenos, mas ficaram complexos com o tempo. É difícil depurar e surgem problemas de desempenho. REST e RPC são mais simples e fáceis de manter.
• Como fundador da Hasura, vi a evolução do uso de GraphQL. É muito difícil construir GraphQL sem uma camada de dados. Usar GraphQL em cima de REST é ineficiente. O principal caso de uso do GraphQL é quando há vários consumidores de dados.
• Engenheiros de frontend armazenam consultas em uma biblioteca central e as reutilizam, o que é o mesmo que usar GraphQL como se fosse REST.
• Pela experiência de usar OpenAPI, GraphQL, JSON/HTTP e gRPC, limitar as consultas GraphQL pode aliviar problemas de desempenho e segurança. Buf Connect é o ponto de equilíbrio mais adequado para a maioria dos projetos.
• Pela experiência de usar GraphQL no Facebook, muita gente não tem os problemas que o GraphQL tenta resolver. O Facebook usa GraphQL para lidar com versionamento e modelos de objetos complexos.
• O GraphQL funciona bem no Facebook porque todos os usuários estão autenticados, e a segurança está embutida em todos os campos. Se houver uma SPA e exigência de login, GraphQL pode ser útil.
• Quando usei GraphQL, pareceu bom no início, mas no fim exigiu muito trabalho extra e duplicação. Teria sido melhor começar com endpoints do tipo JSON-RPC e adicionar os recursos necessários.
• Ao usar GraphQL em um projeto pequeno, quase tudo foi bom. Usei Apollo Client e graphql-codegen para gerar tipos e funções para Vue 3. Houve alguns problemas, mas ele captura muitos erros no nível de tipos.