GraphQL: é o “assassino” da API REST?

Após a implementação do suporte a GraphQL no Parse, muitas pessoas me procuraram com algumas perguntas, algumas delas preocupadas com o futuro da API REST.
Será que o GraphQL vai “matá-la”?
O que acontecerá com meus métodos da API REST? Preciso reescrever meu código?

Neste artigo, abordarei essas questões, mas a resposta curta é: não, você não precisa se preocupar porque o GraphQL não vai “matar” a API REST e você também não precisa se preocupar em reescrever seus métodos de API REST que já estão funcionando.

Então, qual é o problema com o GraphQL?

Um equívoco que a maioria das pessoas que me procuram tem é que o GraphQL não está aqui para substituir todo o backend.

O GraphQL não vai substituir o back-end. Nem o front-end.

O GraphQL é uma linguagem de consulta, uma forma de especificar para sua API quais informações você está procurando e um tempo de execução que obterá essas informações a partir de seus dados pré-existentes.

É apenas uma maneira diferente (melhor, eu diria) de informar ao seu aplicativo exatamente o que você precisa saber e, em seguida, receber essas informações.

Você não precisa se preocupar com os métodos da API REST já existentes e em funcionamento. Eles continuarão funcionando como estão agora, mesmo que você adote o GraphQL. A única coisa a observar é que o GraphQL só é executado no Parse 3.5.0 e posterior, portanto, se você estiver vindo do Parse 2.x ou anterior, isso também implicará na mudança da estrutura de código do Parse.

Portanto, se estiver usando o Parse 3.0 ou superior, não precisa se preocupar. Basta escolher uma versão superior à 3.5.0 e você estará pronto para começar.
Se estiver usando o Parse 2.X, terá que refazer alguns códigos.

E por que GraphQL se minha API REST já está funcionando?

Essa pergunta também aparece muito e eu realmente acredito que há algumas vantagens importantes em escolher o GraphQL em vez da API REST.

No curto prazo, se você já tem seu aplicativo escrito usando a API REST e ele está satisfazendo todas as suas necessidades, não há motivo para migrar para o GraphQL e reescrever o código apenas por essa razão.

Por outro lado, se você está começando agora ou prevê um aplicativo em evolução, que ganhará complexidade e quer estar pronto para uma manutenção simplificada no futuro, o GraphQL pode realmente agregar e trazer muito valor.

Você disse valor?

Sim, eu disse.

O GraphQL tem algumas vantagens importantes que simplificam o desenvolvimento do código, a manutenção ao longo do tempo e podem até mesmo ajudá-lo a economizar na transferência de dados! Sim! Você leu certo.

Vamos ver item por item:

• Simplificar o desenvolvimento de código

  No início, quando você está começando a usar o GraphQL, talvez tenha que produzir um pouco mais de código. Não deixe que isso o assuste.
  O GraphQL tornará suas consultas mais simples de escrever, especialmente se você usar nosso Console GraphQL. Usar os esquemas que o Parse cria automaticamente e publicar métodos genéricos e específicos para consultas e mutações em todas as suas classes economizará muito tempo. E eu quero dizer muito mesmo.
  Documentação? Não tem problema. Nós também cuidamos disso. E ela também é gerada automaticamente.
  Além disso, com o GraphQL, seus desenvolvedores poderão contar com esses esquemas gerados pelo Parse, de modo que saberão de antemão quais são os métodos disponíveis, os parâmetros de cada método e também quais são os retornos disponíveis (saídas). Não é mais necessário adivinhar ou perguntar aos outros usuários o que o método faz, quais parâmetros são necessários ou o que ele retorna. Está tudo lá para você.

• Simplifique a manutenção

  A manutenção com o GraphQL é muito, muito fácil. Como as chamadas para a API são essencialmente as mesmas, alterar apenas a consulta ou a mutação que você passa, adicionar ou remover valores ou parâmetros retornados é tão fácil quanto alterar a consulta ou a mutação para recebê-los ou entregá-los.
  Não é necessário alterar muitas chamadas, blocos ou promessas. Altere a consulta ou a mutação: PRONTO!

• Economize na transferência de dados

  Depois de algum tempo trabalhando na Back4app, é bastante comum ajudar os clientes a otimizar seu código para obter respostas mais rápidas. E de todos os problemas que encontro nos códigos dos clientes, a grande maioria se deve à recuperação de dados de que o aplicativo não precisa naquele momento.
  Um erro muito comum ao lidar com a API REST ou mesmo com as estruturas Parse é recuperar as informações completas de um objeto e, em seguida, usar apenas parte dessas informações. Por exemplo:
  Você tem uma classe chamada Person com algumas propriedades: nome, telefone, endereço, número do seguro social, e-mail, entre outras.
  Normalmente, as pessoas que usam a API REST ou as estruturas Parse tentam consultar o objeto Person completo, recuperando todas as suas propriedades e, em seguida, usando apenas uma ou duas delas.
  Com o GraphQL, como você deve especificar exatamente as informações que precisa recuperar, o desenvolvedor não tem a chance de recuperar informações desnecessárias, o que resulta em cargas úteis muito menores, o que se traduz em respostas mais rápidas, menor consumo de planos de dados e menos tráfego de saída em geral. Não é incrível?

Experimente

A melhor maneira de ver os benefícios que o GraphQL pode trazer para seu processo de desenvolvimento é experimentá-lo.
Aqui estão alguns cenários com os quais você pode brincar e ver como ele se comporta:

• Tente criar uma consulta GraphQL e não especifique exatamente o que você deseja recuperar

  Você não conseguirá fazer isso. Ele pedirá obrigatoriamente que você especifique o que deseja e recuperará apenas isso. Nada mais.
  Se você ou seus desenvolvedores se esquecerem de fazer isso, o GraphQL não os deixará escapar.

Não sei o que estou recuperando

Aí está!

• Tentar alterar um objeto usando uma consulta

  Não. Você quer mudar alguma coisa? Use o método correto: Mutação.
  Se você ou seus desenvolvedores usarem o método errado, o GraphQL não permitirá que eles prossigam.

Uma consulta para alterar dados? Não, não, não!

A mutação lhe dá cobertura!

• Vários objetos, várias consultas? Não, não! UMA consulta!

  O GraphQL facilita muito a recuperação de informações sobre vários objetos com apenas uma consulta, simplificando o desenvolvimento e tornando o código menos propenso a erros.
  Imagine que você tenha uma classe Person e que uma pessoa possa ter um cachorro, da classe Dog. Você precisa recuperar informações de ambas as classes: o nome e a idade da pessoa e o nome e a raça do cachorro. Fácil assim:

Controle de versão? Para quê?

O código de controle de versão é tãããão 2018.
Adicione novos campos à sua consulta. As chamadas antigas ainda funcionarão:

Isso funciona

Isso também funciona. As chamadas para o tipo antigo continuarão funcionando.

Você disse campos obsoletos? Também é fácil:

Conclusão

O GraphQL não está aqui para matar nada. Ele está aqui para trazer uma nova maneira de fazer coisas antigas. Melhor, mais rápida, mais amigável à manutenção e menos propensa a erros.

Ele o manterá no caminho certo quando você escorregar. Ele lhe dirá o que você pode e o que não pode fazer.

Juntamente com o Parse e os métodos gerados automaticamente (tanto genéricos quanto específicos) e a documentação, ele fará com que você aprenda a usar o Parse facilmente.

Se você nunca experimentou, deveria. Todas as crianças descoladas estão usando.

Se você quiser saber mais sobre GraphQL vs. REST, confira nosso post no Medium.