GraphQL é meio irritante

• GraphQL é ótimo, mas parece um pouco superestimado
• Parece que desenvolvedores iniciantes~intermediários acabam usando GraphQL depois de ver vídeos no YouTube, e isso parece errado
• Vantagens
  • É fácil descrever exatamente os dados que você quer
  • Economiza largura de banda. Dá para buscar de uma vez só exatamente o quanto você precisa
  • É fácil criar documentação para consumidores de dados
  • Dá para usar assinaturas com mais facilidade
  • É possível agrupar chamadas de API
• Desvantagens
  • Na prática, é doloroso de usar. Dependendo do backend, se ele não gerar tudo na sua linguagem, você acaba tendo que gerenciar dois ou mais sistemas de tipos
  • Não oferece suporte a map/tabela/dicionário. Isso é realmente grande. Mesmo sem querer, em algum lugar você vai acabar usando {[key: string] : T}
  • Não existe um método claro para versionamento de API. No fim, você vai acabar com algo como MyQueryV1.01 MyQueryV1.02 MyQueryV1.03
• Se você não está lidando com o conjunto de soluções/problemas que o Facebook tinha em mente para GraphQL, não use GraphQL
• Que palavras sábias outros desenvolvedores sêniores poderiam oferecer para salvar desenvolvedores juniores de cair nesse pântano?

Comentários do HN

• O maior problema do GraphQL é que você precisa trabalhar para se defender de ataques DOS ou de gente tentando baixar o seu banco de dados inteiro.
  • É muito fácil criar consultas que impõem uma carga absurda ao seu sistema.
  • Para ver o tipo de coisa que precisa ser feita, basta olhar para a Shopify. Eles aplicam rate limit com base na quantidade de dados retornados, e também lidam com cursor e paginação. Ao contrário dos exemplos bonitos de GraphQL que aparecem na internet, o esquema deles é enorme e feio
• GraphQL é uma ótima forma de resolver problemas organizacionais que grandes empresas de tecnologia têm
  • Como quando a equipe que mantém a API é diferente da equipe que pede mudanças
  • Se a organização é grande, você pode acabar esperando uma eternidade por mudanças; o GraphQL reduz essa necessidade
  • Se a organização é pequena, não seria melhor simplesmente implementar você mesmo o que está faltando?
• Intencionalmente ou não, GraphQL permite que desenvolvedores front-end se desacoplem das exigências sobre desenvolvedores back-end e se movam mais rápido
  • O desenvolvedor back-end cria o modelo de dados e o expõe via GraphQL, e aí um desenvolvedor front-end que nunca sequer falou com esse back-end já consegue usar imediatamente
  • Dá para mudar na hora o que está sendo consultado e pegar exatamente o que se quer
  • Isso faz todo mundo se mover mais rápido
  • Mas eu, como desenvolvedor back-end, realmente odeio GraphQL

[bichi]

GraphQL é meio irritante. Não chega a ser super irritante, mas incomoda um pouco. Ainda assim, como certamente reduz o custo de comunicação entre os membros da equipe, é mais eficiente usar esse tempo para resolver as partes irritantes. E, sinceramente, também é bem feio. Mesmo assim, eu recomendo usar GraphQL. Até porque ninguém vai concordar com a ideia de usar tRPC. A maioria das pessoas nem chega a usar a tecnologia direito e já se recusa a adotá-la por puro preconceito; para resolver isso, teria que empurrar a decisão com autoridade total. Dá para fazer isso com uma ou duas tecnologias, mas se você sair impondo tudo, perde mais do que ganha, então não dá... No fim, o nível máximo de algo que ainda dá para convencer as pessoas a aceitar é o GraphQL ;; REST de merda, essa sim é uma tecnologia paleolítica ruim que realmente gera um custo de comunicação enorme ;;

[alucard]

Este é o primeiro post no GeekNews que me fez criar uma conta. Respondi na parte The bad.

Pode haver vantagens e desvantagens vistas separadamente do lado do cliente e do servidor, mas, olhando tudo junto, mesmo entendendo que a maior value proposition é que o schema do GraphQL preenche a camada de abstração que falta entre servidor e cliente, pessoalmente me soa como um papo um pouco antigo dizer que ainda se consideraria REST para um produto comum.
The bad

• It is actually a pain to use, depending on the backend you are using you'll have to manage
  two or more type systems if there are no code first generates in your language
  No fim, em outras palavras, quer dizer que se você usar direito é bom, né? Code generation e coisas do tipo hoje em dia nem são mais um problema, com o tanto que o tooling evoluiu.
• It doesn't support map/tables/dictionaries. This is actually huge. I get that there might be
  some pattern where you don't want to allow this but for the majority of situations working with json api's you'll end up with a {[key: string] : T} somewhere
  Isso também é mencionado em Production Ready, mas parece ser uma questão com a qual nem precisa se preocupar tanto se você aproveitar as vantagens do type system. Em vez de key: string, basta definir os campos exatos.
• No clear path for Api versioning you'll end up with MyQueryV1.01 MyQueryV1.02 MyQueryV1.03
  GraphQL é sem versão por definição....
  Don't use Graphql unless you're managing a solution/problem set that facebook intended graphql for Invest your time in a simpler solution then running to GraphQL first
  Isso soa como dizer que também não se deve usar React a menos que você esteja resolvendo exatamente o tipo de problema que o Facebook queria resolver.

[bichi]

Olá, ótimas colocações. Será que não poderíamos nos conhecer? Precisamos de pessoas que pensem assim. Está sendo muito difícil convencer outras pessoas (membros da equipe).

[alucard]

kkk vi o comentário tarde..!! Eu uso o apelido Alucard no Slack do GraphQL Korea :)

[sixmen]

Adotamos GraphQL relativamente no começo, e naquela época havia muitas explicações focadas em backend. Por isso, acho que acabou ficando a percepção de que seria algo bom para o backend.

Depois de quebrar bastante a cabeça testando várias coisas, quando pessoas que entraram na empresa depois ou candidatos em entrevistas perguntam, costumo explicar que, para o backend, é difícil, mas, para o frontend, é bom. :)

[bbulbum]

#Mas eu, como desenvolvedor de backend, realmente odeio GraphQL
Concordo...

[ifmkl]

A expressão "a ferramenta certa para o lugar certo" é exatamente o que me vem à mente.

[kbumsik]

Intencionalmente ou não, o GraphQL permite que os desenvolvedores de frontend se desacoplem das demandas sobre os desenvolvedores de backend e avancem mais rápido

Esse é o motivo para usar GraphQL. A própria especificação do GraphQL deixa claro que ele é para o frontend 1
Eu também comecei a usar GraphQL em uma nova startup, e com certeza parece que a frequência com que preciso me comunicar com engenheiros de frontend por causa da API diminuiu em relação a antes.

Antes de usar GraphQL de verdade, havia problemas que eu nem imaginava e que acabam sendo meio dolorosos do ponto de vista de um engenheiro de backend, mas ainda assim parece muito melhor do que quebrar a cabeça tentando desenhar bem uma API REST.

[hwasurr]

Nenhuma tecnologia é perfeita, certo! Acho que vale considerar adotar uma tecnologia se ela for necessária a ponto de compensar o custo de lidar com suas desvantagens, ou se resolver algum outro problema maior. Afinal, a adequação de uma tecnologia/ferramenta sempre depende da situação de quem a usa.

Por outro lado, também acho que um dos motivos de o GraphQL ser criticado é porque ele passa/vende(?) uma imagem de que é "fácil".

[jjpark78]

Lembro que, quando o GraphQL surgiu no começo e estávamos tocando um projeto de POC, não existia nenhum engine que suportasse multipart direito, então foi bem sofrido..

[gjen6s]

Eu também já pensava há bastante tempo que, quando via GraphQL sendo usado em projetos pequenos, isso não seria especificação demais? Parece que todo mundo pensa parecido.

[xguru]

Só traduzi os primeiros comentários. Há mais de 400 comentários, então é difícil até ler todos.