GraphQL é simplesmente uma linguagem de consulta para APIs. Ela fornece uma descrição completa e compreensível dos dados em sua API e provê aos clientes/front-ends o poder de perguntar exatamente o que eles precisam e nada mais.

GraphQL não é SQL

Você deve estar pensando “Oba! Não vou usar SQL nunca mais na vida”. Calma! GraphQL não tem nada a ver com SQL.

Structured Query Language, ou Linguagem de Consulta Estruturada, ou SQL, é a linguagem de pesquisa declarativa padrão para banco de dados relacional.

Basicamente você vai continuar usando SQL no back-end se o seu banco for relacional. Caso contrário, continuará fazendo as consultas do modo como você faria se a sua API fosse REST.

GraphQL é o “SQL” do front-end

História

Para entender melhor, vamos entender como e porque o GraphQL nasceu.

Nossa querida GraphQL foi criada pelo Facebook em 2012 e lançada publicamente em 2015. Vocês lembram do aplicativo do Facebook antes de 2012? Era horrível. Mas por que era tão ruim?

Lee Byron (dev do Facebook): “Na época, nossos aplicativos para iOS e Android eram invólucros finos em torno das visualizações de nosso website para celular.”

Basicamente uma WebView – eles só fizeram um aplicativo que chamava a URL do Facebook.

Continua Lee Byron: “Como os aplicativos móveis do Facebook se tornaram mais complexos, eles sofreram com um desempenho ruim e, com frequência, travavam.”

Ao iniciar o desenvolvimento de maneira nativa para aplicativos, eles se encontraram, pela primeira vez, precisando de uma API para o feed de notícias. Ficaram frustrados com as diferenças entre os dados que desejavam usar nos aplicativos e as consultas do servidor que eles possuíam. Essa frustração inspirou alguns deles a iniciar o projeto que acabou se tornando GraphQL.

“O GraphQL foi nossa oportunidade de repensar a busca de dados de aplicativos móveis a partir da perspectiva de designers e desenvolvedores de produtos.” [Byron].

Na minha opinião, eles pensaram: “Ah, não, vou ter que fazer EndPoints específicos só para o aplicativo, depois vou ter que dar manutenção em dobro – que preguiça! E se tivesse um jeito de ter um único EndPoint e eu dizer pra ele o que eu quero dele?”.

Assim surgiu a GraphQL

Quais são os problemas do REST?

Definindo, Representational State Transfer, abreviado como REST, é um modelo a ser utilizado para se projetar arquiteturas de software distribuído, baseadas em comunicação via rede.

Múltiplos Endpoints para resolver uma necessidade específica do cliente (underfetching)

Quem nunca precisou montar um tela e teve que chamar duas, três ou mais APIs para acessar os dados que precisava? E pensa na perda de desempenho dessa brincadeira. Você vai fazer várias chamadas para o mesmo servidor.

Endpoints expõem mais dados que os clientes precisam (overfetching)

Isso acontece quando você recebe um objeto e só precisa exibir dois atributos, mas recebe o objeto inteiro com vinte atributos, e isso vai piorando se for uma lista de objetos.

Além da perda de desempenho nessa situação, nós, desenvolvedores, temos que lembrar que os usuários que usam dados móveis estão literalmente pagando por aqueles dados que estamos descartando, então o ideal seria que a gente pudesse consumir somente aquilo que vamos usar.

E como o GraphQL resolve isso?

Uma consulta GraphQL é uma string enviada a um servidor para ser interpretada e preenchida, que retorna o JSON de volta ao cliente.

Como vocês podem perceber, consultas GraphQLs espelham suas respostas. Isso facilita de mais para o desenvolvedor front-end prever o que será retornado na consulta.

Conceitos importantes

• 1. Single Endpoint: costumam ter somente um único Endpoint, o que muda é o conteúdo do artigo da requisição.
• 2. Todas as chamadas são do tipo POST.
• 3. Impõem um contrato bem definido: cliente e servidor devem respeitar uma estrutura bem definida, conhecida como Schema, para troca efetiva de dados. Ou seja, é fortemente tipada.
• 4. Possuem operações de Query e Mutation: query são somente leitura, não modificam os dados, substituem o GET do REST. Já Mutation são operações que alteram os dados. No caso, substituem POST, PUT e DELETE.

Quem está usando?

No mundo:

No Brasil:

No prédio que eu trabalho (trabalho na Objective Solutions):

Prática

Exemplo de projeto para se divertir com o GraphQL: https://graphloc.com/

Considerações finais

Se você precisa de flexibilidade e eficiência, recomendo fortemente que pesquise sobre a ferramenta e como ela pode facilitar o modo como você consome e constrói APIs.

Além de todas as outras vantagens já descritas acima, levanto mais uma: GraphQL também ajuda a diminuir os conflitos entre os desenvolvedor de back-end e os de front-end.

Vida longa ao GraphQL!

Dúvidas, sugestões ou críticas? Deixe nos comentários.

Obrigada!

Referências

• AQUILES, Alexandre. Todo o poder emana do cliente: explorando uma API GraphQL. Acesso em: 17 set. 2018.
• BYRON, Lee. GraphQL: A data query language. Acesso em: 17 set. 2018.
• FACEBOOK. GraphQL: A query language for your API. Acesso em: 18 set. 2018.
• HANASHIRO, Akira. Você conhece o GraphQL e como ele pode te ajudar?. Acesso em: 17 set. 2018.
• SILVEIRA, Paulo; LINHARES, Mauricio; ALIONÇO, Alessio; TRINDADE, Marcio; ROSA, Rafael. Startups, Processos e Mercado Global — Hipsters #55. Podcast. MP3 (50 min). Acesso em: 17 set. 2018.
• SOARES, Ubiratan. Tudo o que você quer saber sobre GraphQL. Acesso em: 17 set. 2018.
• WIKIPÉDIA. Desenvolvido pela Wikimedia Foundation. REST. Acesso em: 17 set. 2018.
• WIKIPÉDIA. Desenvolvido pela Wikimedia Foundation. SQL. Acesso em: 17 set. 2018.

***

Artigo original publicado no Objective e republicado com a autorização do autor: https://www.objective.com.br/graphql-poder-ao-front-end/