Quando o REST foi criado no ano 2000, o ritmo de desenvolvimento era outro e as aplicações eram relativamente mais simples, isso explicava o porquê de o REST ser bom para realizar ajustes em muitas das aplicações existentes.

Ele ofereceu conceitos relevantes sobre design de APIs como servidores apátridas e acesso estruturado aos recursos. Contudo, hoje as APIs, ativos de muitas empresas, se tornaram ainda mais complexas e orientadas a dados que sofrem influência dos seguintes fatores:

• O aumento do mobile gerou a necessidade de um carregamento de dados mais eficiente. 
• Uma variedade de clientes diferentes: o REST não facilita a construção de uma API quando levamos em conta a estrutura de dados fixos que é retornada 
• Expectativas para um desenvolvimento mais rápido de recursos: Para fazer uma mudança no lado do cliente em REST, muitas vezes temos de ajustar o lado do servidor para oferecer suporte, retardando as iterações do produto.

Mais de 10 anos depois é desenvolvido o GraphQL uma alternativa moderna à arquitetura baseada em REST. Inicialmente desenvolvido pelo Facebook, o GraphQL buscava superar os desafios enfrentados pelas APIs REST existentes.

A empresa criou o idioma de consulta em 2015 e agora é gerenciada pela GraphQL Foundation. Hoje, muitas pessoas implementaram a especificação em diferentes linguagens de programação, sendo que mais comuns o suportam.

Ainda assim, vale lembrar que REST continua sendo muito usado em aplicações. 

Como podemos definir GraphQL?

Engana-se quem pensa ser um banco de dados, um framework ou mesmo de uso exclusico para HTTP/APIs. Na verdade, GraphQL é uma Declarative Query Language, em outras palavras, é linguagem de consulta e ambiente de execução voltado para APIs, sendo seu principal objetivo o fornecimento dos dados exatos solicitados por clientes, ou seja, é especificação para interações client/server.

O GraphQL pode ser utilizado independente de data store e da plataforma. Logo, ele não está vinculado a nenhum banco de dados ou mecanismo de armazenamento específico, mas é apoiado pelo código e dados existentes.

Conceitos principais:

• Você é quem especifica exatamente quais dados ele precisa, não recebendo nada mais e nada menos do que o solicitado;
• Facilita a agregação de dados de múltiplas fontes;
• Usa um sistema de tipos para descrever dados;
• Todas as chamadas são do tipo POST;
• Contrato bem definido: cliente e servidor devem respeitar uma estrutura bem definida, conhecida como Schema, para troca efetiva de dados;
• Possui 3 operações: Query é somente leitura e não modifica os dados, Mutation representa as operações que alteram os dados e a Subscription é um mecanismo integrado que realiza notificações ao cliente sempre que alguma modificação dos dados for feita, ou seja, uma Mutation;
• Os tipos de dados são bem definidos, reduzindo as falhas de comunicação entre o cliente e servidor.

Sua finalidade é tornar as APIs mais rápidas e intuitivas para os desenvolvedores, já que facilita a consulta de dados de diferentes fontes em uma única chamada de API e torna flexível a manutenção das APIs no momento de adicionar ou preterir campos, sem afetar as consultas existentes. As APIs que oferecem uma interface GraphQL para dados de consulta são conhecidas por APIs GraphQL.

Outra característica importante do GraphQL é que você pode recuperar vários dados de entidades em uma única chamada de API. Como na API do produto, se você precisar de dados do cliente, você pode criar um schema para ambos e recuperá-los em uma chamada.

Comparando GraphQL e REST

Como alternativa à arquitetura REST, o GraphQL permite que desenvolvedores construam solicitações para extrair os dados de várias fontes em uma única chamada. Esse já uma de suas primeiras diferenças e por assim dizer vantagem em relação ao REST.

Na busca de dados com uma API REST o desenvolvedor geralmente coleta os dados acessando vários endpoints. Por exemplo, um endpoint para buscar os dados iniciais do usuário, um segundo para retornar todas as postagens desse mesmo usuário e até um terceiro endpoint que retorna uma lista de seguidores do usuário.

Já na API GraphQL estamos falando de um único endpoint e da obtenção de muitos recursos em um único pedido. O desenvolvedor simplesmente envia uma única consulta ao servidor GraphQL que inclui os requisitos de dados concretos. Em seguida, o servidor responde com um objeto JSON onde esses requisitos são cumpridos.

Flexibilidade de dados:

Uma das questões envolvendo o REST é a flexibilidade do dado sendo transmitido. Quando diferentes usuários, com diferentes necessidades consomem a API é possível que isso gere alguns fenômenos que podem ser prejudiciais do ponto de vista do cliente:

•  Under-fetching: Ausência de dados na consulta, ou seja, você precisa realizar outras chamadas para cumprir o seu propósito.
•  Over-fetching: Excesso de dados na consulta.

Iterações rápidas de produtos no Front-end:

Um padrão comum das APIs REST é sobre a estrutura de endpoints, ela é feita segundo as visualizações que de dentro do seu aplicativo. Algo positivo já que possibilita que o cliente consiga todas os dados necessários para uma visão específica. Tudo isso, apenas acessando o endpoint correspondente.

No entanto, essa abordagem não permite iterações rápidas nos passos seguintes. Ao longo de cada modificação realizada na interface do usuário, enfrentamos um risco elevado de que agora tenhamos mais (ou menos) dados necessários do que antes. O resultado disso será um reajuste no back-end a fim de que ele dê conta das novas necessidades de dados, prejudicando no fim das contas a produtividade e a capacidade de incorporar o feedback do usuário em um produto.

Para situações como essa, optar pelo GraphQL, com sua natureza mais flexível, podemos fazer estas alterações sem qualquer trabalho extra no servidor.

Outro ganho para desenvolvedores front-end são as bibliotecas de clientes do GraphQL (como Apollo e Relay). Através delas desenvolvedores recebem recursos comocache ou atualizações de interface do usuário em tempo real. Tal suporte favorece a produtividade entre os desenvolvedores front-end e a aceleração no desenvolvimento de produtos. Com o GraphQL, podemos redesenhar completamente a interface do usuário de um aplicativo sem precisar tocar no back-end.

Análises perspicazes no Back-end:

O GraphQL oferece insights mais finos quanto aos dados solicitados no back-end. Conforme cada cliente especifica as informações de seu interesse, é possível ter uma compreensão profunda de como os dados disponíveis estão sendo utilizados. O benefício está no suporte para a evolução de uma API na depreciação de campos específicos que não são mais solicitados por nenhum cliente.

Com o GraphQL, o desenvolvedor também pode monitorar o desempenho de baixo nível das solicitações que são processadas pelo servidor.

Práticas indicadas

Pense em gráficos, não em endpoints – Diferente de API tradicionais, o GraphQL expõe todas as informações por meio de um único endpoint. Logo sua meta com essa linguagem deve ser elaborar um gráfico unificado e coeso, que possibilite aos usuários desenvolverem subconjuntos desse gráfico, e assim construírem novas experiências de produto.

Descreva os dados, não a exibição – Verifique se sua API não está interligada demais às demandas de sua interface inicial. Por exemplo, se você está criando um API para aplicativo iOS, posteriormente você pode utilizá-la em outros dispositivos. No momento de criar consultas, concentre-se mais nos dados subjacentes, do que na maneira como ele é representado em sua aplicação.

Oculte detalhes de implementação – O GraphQL é uma costura entre seus dados e os detalhes de seu armazenamento e recuperação. Se você fornece muitas informações em uma única resposta, então algum cliente pode utilizar os dados extras para propósitos pessoais, resultando em sua quebra de base de código no instante em que a implementação muda nos bastidores.

Trabalhando com dados legados – Dê preferência com elaborar GraphQL schemas descrevendo como seus clientes usam os dados, no lugar de se espelhar em um schema do banco de dados legado. Isso por que você pode se deparar com fontes de dados legados que não refletem bem como os clientes consomem os dados. Dessa forma, construa um schema que expresse “o quê” em vez de “como”.

Caminho promissor

Desde sua criação o GraphQL trouxe muitos benefícios aos desenvolvedores e as APIs modernas, seja por permitir que o usuário defina o que o servidor deve retornar como resposta ou por todas as suas ferramentas, como as subscriptions.

Vale destacar que o GraphQL não é a solução para todos os seus problemas nem todos, caso você precise uma API versionada ou de maior controle sobre o que é exposto para seus clientes, talvez REST ou até mesmo SOAP possam resolver melhor a situação.

Entanto, não há como negar que ele é um padrão que vem sendo amplamente aceito pela comunidade. O GraphQL já começou transformar a maneira como as empresas pensam em criar aplicativos, sendo utilizado por times de diferentes tamanhos, em muitos ambientes e idiomas a fim dealimentar aplicativos móveis, sites e APIs.

A partir dele desenvolvedores front-end estão livres para consultar os dados que desejam, e os desenvolvedores back-end podem desacoplar as necessidades de aplicativos de clientes de suas arquiteturas de sistema back-end. Assim, não é difícil imaginar que o GraphQL veio para ficar no dia a dia de muitos desenvolvedores.