GraphQL é uma linguagem de consulta de código aberto para APIs que pode buscar dados de várias fontes em uma chamada de API. Ele também atua como um tempo de execução do lado do servidor para atender consultas com dados existentes. O GraphQL prioriza fornecer ao cliente apenas os dados solicitados, ao mesmo tempo em que fornece uma descrição completa dos dados da API, além de facilitar o dimensionamento e a evolução das APIs.
O GraphQL foi projetado com flexibilidade, velocidade e desenvolvedores em mente. Com o GraphQL, os desenvolvedores podem criar APIs da maneira que acharem melhor e, então, usar uma especificação GraphQL para garantir que as APIs sejam funcionais para os clientes.
Um dos principais conceitos de uma consulta GraphQL é que os dados que você recebe são previsíveis. Em vez de sequências de código excedente, o que é retornado é exatamente o que foi solicitado. Essa busca declarativa de dados é especialmente útil em dispositivos móveis, onde a largura de banda é limitada. Os aplicativos que usam GraphQL também são estáveis e rápidos porque controlam os dados solicitados e recebidos, em vez do servidor. Eles também são rápidos mesmo em conexões de rede lentas, porque uma única solicitação pode retornar vários itens solicitados de uma só vez.
Com base na simplificação de dados do GraphQL, as APIs são organizadas por tipos e campos em vez de pontos de extremidade. Isso significa que todos os dados podem ser acessados em um único ponto de extremidade, permitindo que os aplicativos solicitem apenas o que é necessário. Ao reduzir a complexidade operacional, o GraphQL se encaixa no fluxo de trabalho de uma solução de conectividade de API simplificada.
Em 2012, a Meta (na época Facebook) precisava de uma API de busca de dados que fosse poderosa o suficiente para seus aplicativos móveis do Facebook . Liderado por Lee Byron, o Facebook desenvolveu o GraphQL como uma forma de simplificar a busca de dados – especificamente, da perspectiva de designers e desenvolvedores de produtos. O GraphQL foi usado internamente pelo Facebook e depois lançado publicamente e disponibilizado como código aberto em 2015. Seguindo a trajetória de muitos outros projetos de código aberto, em 2019 o projeto GraphQL migrou para sua própria GraphQL Foundation , hospedada pela Linux Foundation .
O GraphQL foi projetado como uma alternativa à arquitetura REST . As APIs REST padrão exigem o carregamento de informações de vários URLs por meio de solicitações HTTP GET separadas. Com as APIs GraphQL, todos os dados são recuperados por meio de uma única solicitação POST. Enquanto REST e GraphQL retornam respostas no formato JSON, GraphQL se concentra em otimizar e consolidar dados.
O GraphQL oferece suporte a solicitações de dados detalhadas e oferece aos clientes mais controle sobre quais informações são enviadas. O cliente envia uma consulta GraphQL no formato de uma solicitação POST, à qual o servidor retorna uma resposta no formato JSON. O GraphQL não requer uma arquitetura de aplicativo específica, pode ser implantado em vários ambientes (incluindo um ambiente de desenvolvimento integrado [IDE]) e pode ser usado com ferramentas de gerenciamento de API existentes ou sobre APIs REST existentes.
Alguns termos-chave dentro do GraphQL incluem:
Um recurso exclusivo do GraphQL é que as respostas espelham a estrutura da consulta (que é definida pelo esquema). Isso simplifica a análise para o cliente porque o formato da resposta do servidor é completamente previsível.
A natureza hierárquica do GraphQL segue relacionamentos entre objetos e funciona bem em interfaces de usuário hierárquicas. Ele também é fortemente tipado, o que significa que cada nível de consulta corresponde a um tipo. Esses tipos então definem um conjunto de campos. Isso é semelhante ao SQL, onde mensagens de erro descritivas são exibidas antes de concluir uma consulta.
Resolvedores são os principais módulos arquitetônicos que conectam campos, arestas, mutações, consultas e assinaturas do GraphQL a fontes de dados (e microsserviços).
Você pode aprender como criar resolvedores para fontes de dados da AWS neste tutorial do GraphQL .
Uma coisa que torna as consultas GraphQL únicas são as respostas espelhadas. Os dados retornados de uma consulta se tornam previsíveis, porque você sabe que eles corresponderão ao formato da solicitação da API. Quando o formato dos dados retornados segue a consulta do cliente, os servidores se tornam simplificados.
Um grande benefício do GraphQL é que extensões estão disponíveis para fornecer recursos que não estão disponíveis no REST. Outras vantagens do GraphQL incluem o seguinte.
Um esquema GraphQL define uma única fonte de verdade em aplicativos GraphQL, fornecendo um local principal onde todos os dados são descritos. Embora o esquema GraphQL seja geralmente definido no servidor, os clientes ainda podem consultar e gravar dados com base no esquema.
Em arquiteturas REST, o overfetching pode rapidamente se tornar um problema: o aplicativo (backend) define os dados disponíveis para cada recurso e retorna tudo em sua resposta, mesmo que o cliente (frontend) precise apenas de um único elemento. As chamadas GraphQL acontecem em uma única viagem e fornecem aos clientes os dados solicitados sem qualquer busca excessiva.
Como os tipos de dados são fortemente definidos, a comunicação entre cliente e servidor é mais clara no GraphQL do que no REST. Essa estrutura subjacente também significa que clientes complexos não são necessários para chamar um servidor GraphQL. Para saber mais e ver o código em ação, leia sobre clientes e servidores na página oficial do GraphQL .
Um conjunto de princípios e ferramentas de design, a API Federation torna possível expor serviços dentro de um contexto limitado como uma API consistente para usuários, ao mesmo tempo em que permite que os serviços dentro desse contexto evoluam sem restrições. O GraphQL oferece um método para federar toda a API e evoluir sem interromper consultas anteriores, o que o torna escalável – e essa escalabilidade é uma das razões pelas quais o GraphQL é usado por muitas empresas.
A natureza introspectiva do GraphQL permite recuperar o esquema GraphQL de uma API GraphQL. Os clientes também podem solicitar uma lista de tipos de dados disponíveis, o que é ideal para gerar documentação automaticamente e para testar ou recuperar esquemas de vários microsserviços.
Embora existam muitos motivos para adotar o GraphQL, também há algumas desvantagens que você deve conhecer. Por exemplo, não é tudo pronto para uso – bibliotecas especiais são necessárias para consumir a API de outra pessoa. E, no geral, GraphQL requer suporte de ferramentas mais pesado do que REST.
As desvantagens do GraphQL em comparação com o REST incluem o seguinte.
Para desenvolvedores acostumados com APIs REST, o GraphQL apresenta uma curva de aprendizado mais íngreme. Ele também pode alterar o fluxo de trabalho – equipes de API que usam GraphQL também devem escrever esquemas GraphQL sustentáveis. Dito isso, se você estiver começando do zero, o GraphQL pode ser fácil de aprender e usar porque solicitações e respostas têm a mesma estrutura.
O GraphQL pode exigir novas estratégias de gerenciamento de API, enquanto as APIs REST tendem a se encaixar em modelos de gerenciamento de API existentes. É importante considerar isso, pois adicionar uma nova estratégia de gerenciamento de API pode aumentar as despesas gerais.
O armazenamento em cache é menos direto no GraphQL do que no REST, onde as solicitações geralmente usam um método HTTP (GET, POST, PUT ou DELETE). Uma solicitação GraphQL padrão é POST, que não pode ser armazenada em cache no nível HTTP. O armazenamento em cache também pode se tornar complexo no GraphQL porque ter um único ponto de extremidade significa que a URL desse ponto de extremidade produz múltiplas respostas variáveis não armazenáveis em cache (bom para buscar dados, ruim para armazenamento em cache). Os desenvolvedores de servidores acabam criando consultas diferentes, mesmo que cada um opere dentro do mesmo objeto. Dito isso, muitas bibliotecas GraphQL oferecem mecanismos de cache prontos para uso.