GraphQL —A flexibilidade do formato de dados

Photo by Clint Adair on Unsplash

Já faz algum tempo que a arquitetura REST está consolidada. Para muitos, já faz parte do dia-a-dia desenvolver aplicações RESTful. Contudo, nos últimos anos o GraphQL vem tomando cada vez mais força. Desde o seu lançamento em 2015, ele não parou de crescer no interesse da comunidade de desenvolvedores. É possível observar isso nos gráficos abaixo:

Figura 1 — Crescimento de interesse visualizado no Google trends

Figura 2 — Crescimento de interesse visualizado no Stackoverflow trends

Alguns dizem que é bom, outros que não é. Acredito que você — assim como eu — deve estar se perguntando sobre o que é o GraphQL e como ele é diferente da abordagem tradicional (REST). O objetivo deste post é desmitificar o que é essa tecnologia tão falada e quando ela pode ser útil.

O que é?

Criado pelo Facebook, o GraphQL é uma sintaxe que descreve uma maneira de solicitar dados. Ele é geralmente utilizado para entregar dados, do servidor para o cliente. O GraphQL tem três principais características:

• Ele permite que o cliente especifique exatamente os dados que ele quer.
• Torna mais fácil agregar dados de várias fontes.
• Usa um sistema de tipos para descrever os dados.

Com o GraphQL, o usuário pode fazer uma única chamada para buscar todas as informações que precisa. Diferente do que acontece na arquitetura REST, que é necessário fazer várias requisições para buscar as mesmas informações.

Na prática, uma consulta usando GraphQL é uma string enviada e interpretada pelo servidor, que após processar retorna o JSON no formato solicitado. Na Figura 3 é possível visualizar um exemplo:

Figura 3 — Exemplo do GraphQL em funcionamento.

Analisando a query de consulta e o seu retorno, é possível notar alguns aspectos do GraphQL:

Ele define um formato dos dados: É possível notar que as queries do GraphQL espelham a sua resposta. Isso permite a previsão da forma dos dados retornados de uma consulta, facilitando a vida do desenvolvedor que consome.

Ele é hierárquico: O GraphQL possui uma natureza hierárquica. Ele segue naturalmente os relacionamentos entre os objetos. Nos caso, que um serviço RESTful iria existir diversas requisições, resultando no uso intensivo de recursos.

Ele é fortemente tipado: Cada nível de uma consulta GraphQL corresponde a um tipo específico e cada um descreve o conjunto de campos disponíveis. Semelhante ao SQL, isso permite que ele forneça mensagens de erro descritivas antes de executar uma consulta.

Ele é introspectivo: Um serviço GraphQL pode ser consultado para os tipos que ele suporta. Com isso, temos uma plataforma que torna possível construir ferramentas que consultem essas informações. Um exemplo disso é o GraphiQL (Ferramenta demonstrada na Figura 3). O GraphiQL ajuda os desenvolvedores a aprender e explorar uma API rapidamente sem precisar usar o cURL.

Ele não precisa de versionamento: O formato dos dados devolvidos é determinada inteiramente pela consulta do cliente, Então os servidores se tornam mais simples e fáceis de generalizar. Quando você adiciona novos recursos do produto, campos adicionais podem ser adicionados ao servidor, deixando os clientes existentes sem serem afetados. Quando você está desativando recursos antigos, os campos do servidor correspondentes podem ser preteridos, mas continuam funcionando. Esse processo gradual e compatível com versões anteriores elimina a necessidade de um número de versão incremental.

Quem está usando?

Quando estou estudando tecnologias que são hype, sempre gosto de dar uma olhada na aceitação da comunidade. Uma das maneiras de analisar isto é observando quais as empresas que estão utilizando.

O próprio site graphql.org tem uma lista com incontáveis empresas. Já o site stackshare fez um compilado com diversas empresas que substituíram suas APIs REST por GraphQL. O interessante é que para cada empresa é explicado a razão da migração.

O que é o StackShare? Para quem não conhece ainda, eu aconselho dar uma olhada. Ele é um site que permite que as empresas compartilharem com o mundo o stack de tecnologias que elas estão usando atualmente.

O outro lado da moeda

Photo by Ryan Thomas Ang on Unsplash

Até o momento, vimos que o GraphQL tem muitas vantagens. Contudo, é interessante tomar cuidado para não pensar nele como uma bala de prata. Afinal, como qualquer outra tecnologia, ele também possui as suas inconveniências. Os tópicos abaixo mostram algumas das desvantagens do uso do GraphQL:

Consultas complexas: Observando as perguntas do stackoverflow e quora é comum perceber confusões sobre o GraphQL ser um substituto para banco de dados, mas ele é apenas uma linguagem de consulta. Geralmente, quando uma consulta precisa ser resolvida com dados, uma implementação do GraphQL realizará o acesso ao banco de dados. Sendo assim, o GraphQL não elimina os gargalos de desempenho quando você precisa acessar vários campos (por exemplo: autores, artigos, comentários) em uma consulta. Se a solicitação foi feita em uma arquitetura RESTful ou GraphQL, os diversos recursos e campos ainda precisam ser recuperados de uma fonte de dados. Como resultado, surgem problemas quando um cliente solicita muitos campos aninhados de uma só vez. Os desenvolvedores front-end nem sempre estão cientes do trabalho que um aplicativo do servidor precisa executar para recuperar dados, portanto, deve haver um mecanismo como profundidade máxima de consulta, ponderação de complexidade de consulta, evitando recursão ou consultas persistentes para interromper solicitações ineficientes do outro lado.

Limitar recursos: Outro problema é referente a limitação de recursos. Enquanto no REST é simples dizer que “permitimos apenas tantas requisições por dia”, no GraphQL é mais difícil fazer tais especificações. Já que somente limitar o número de recursos não é o bastante. Um usuário esperto pode fazer uma query complexa que pega tudo de uma vez (e sobrecarrega o seu servidor). Sendo assim, as APIs que precisam deste recurso, acabam por ter que implementar algo completamente próprio (olha o exemplo do GitHub API).

Caching: Implementar um cache simplificado com o GraphQL é mais complexo do que implementá-lo no REST. No REST, os recursos são acessados com URLs, assim é possível armazenar em cache algum recurso, porque você tem o URL como identificador. No GraphQL, isso se torna complexo porque cada consulta pode ser diferente, embora opere na mesma entidade. Você só pode solicitar apenas o nome de um autor em uma consulta, mas deseja saber o endereço de e-mail na próxima. É aí que você precisa de um cache mais refinado no nível do campo, que pode ser difícil de implementar. No entanto, a maioria das bibliotecas construídas em cima do GraphQL já oferece mecanismos de cache.

Conclusão

Bom, o primeiro aprendizado aqui foi que GraphQL é uma sintaxe e não é uma ferramenta ou biblioteca (apesar de existirem diversas bibliotecas que auxiliam na sua implementação). Outro ponto interessante a se notar é que o GraphQL não exclui o REST. Se você quiser, pode criar o seu sistema de queries próprio usando REST, o restdb.io fez isso. O que o Facebook fez no GraphQL foi criar um padrão a ser seguido e que foi bem aceito pela comunidade. A proposito, o Netflix também tem algo parecido, o Falcor (certamente estudarei ele no futuro também).

No próximo post, vou fazer um tutorial de GraphQL usando Go como a linguagem para a API. Neste post quero explorar também a sintaxe própria do GraphQL.

Se quiser trocar uma ideia ou entrar em contato comigo, pode me achar no Twitter(@e_ferreirasouza) ou Linkedin.

Grande abraço e até a próxima!