O GraphQL é uma linguagem de consulta de código aberto e um tempo de execução no lado do servidor que define como os clientes devem interagir com as interfaces de programação de aplicativos (APIs).
GraphQL oferece uma alternativa eficiente e mais flexível à transferência de estado representacional (REST) e às APIs RESTful, solucionando algumas limitações do REST. Por exemplo, ao fornecer a capacidade de direcionar recursos com mais precisão por meio de uma única consulta.
GraphQL usa uma sintaxe intuitiva que permite aos clientes enviar uma única consulta GraphQL para uma API e receber exatamente os dados necessários (em vez de acessar endpoints complexos com muitos parâmetros). Essa obtenção de dados mais eficiente pode melhorar o desempenho do sistema e a facilidade de uso para desenvolvedores.
Isso torna o GraphQL particularmente útil para construir APIs em ambientes complexos com requisitos de front-end em rápida mudança. Nem as APIs REST nem as GraphQL são inerentemente superiores; são ferramentas diferentes, adequadas para tarefas distintas.
No início da década de 2010, o Facebook estava passando por um crescimento e transformação massivos. Mas uma base de usuários em crescimento e um ambiente de aplicativo móvel cada vez mais complexo tornaram sua abordagem RESTful existente insustentável, já que ela exigia múltiplas idas e voltas a diferentes endpoints de API para buscar todos os dados necessários da consulta.
As APIs REST não estavam equipadas para lidar com interfaces de usuário complexas e orientadas por dados, e frequentemente enfrentavam problemas de latência e ineficiências de dados, especialmente para usuários móveis com planos de dados limitados ou caros.
Em resposta a esses desafios, engenheiros do Facebook desenvolveram o GraphQL (junto com a plataforma de aplicação de página única React), lançando-o como uma solução de código aberto em 2015. Por fim, o Facebook transferiu o serviço para a GraphQL Foundation, que inclui empresas membros como AWS, Gatsby, Intuit e IBM, em 2018.
Os recursos declarativos de obtenção de dados de uma arquitetura GraphQL giram em torno de vários componentes e processos principais, cada um com um papel específico no tratamento e processamento de dados.
Eles incluem:
O GraphQL depende de um sistema de tipos robusto, no qual todos os tipos de dados são registrados na linguagem de definição de esquema (SDL) do GraphQL. Esquemas digitados determinam os tipos de dados que podem ser consultados na API, as relações entre esses tipos e as operações disponíveis para o usuário.
Em outras palavras, elas definem os recursos da API e a forma dos dados com os quais os clientes podem interagir. A configuração desse esquema determina, em última instância, como a API pode ser usada. À medida que as consultas chegam, o esquema é utilizado para validação da requisição e a API GraphQL executa apenas as consultas validadas.
Cada campo em um esquema é respaldado por um resolvedor que preenche os dados e determina a resposta para um conjunto de campos. Os resolvedores, que podem recuperar dados a partir de um banco de dados, de um serviço em nuvem ou de praticamente qualquer outra fonte, fornecem instruções para transformar uma operação GraphQL (por exemplo, uma consulta, uma mutação ou uma assinatura) em dados.
Quando um campo de consulta é iniciado, o sistema gera uma chamada para o resolver correspondente para gerar o próximo valor. Se um campo gerar um valor escalar (como uma string ou número), a execução será concluída. Se um campo gerar um valor de objeto, a consulta conterá mais campos para esse objeto. Esse processo continua até ficarem somente campos escalares.
Os resolvers também facilitam a formatação de dados e ajudam o sistema a unir informações de várias fontes de dados.
Uma consulta de dados é a solicitação feita pelo cliente ao servidor GraphQL; ela especifica quais dados o cliente deseja buscar. As consultas são definidas no tipo de consulta, que é um objeto especial no código que define o ponto de entrada de nível superior para cada solicitação que os clientes podem executar no servidor. Cada tipo de consulta também define o nome e o tipo de retorno de cada ponto de entrada.
Quando chega uma consulta, o GraphQL a valida em relação às definições do esquema e, se a consulta for válida, a executa. Normalmente a estrutura de uma consulta é igual à estrutura de dados de resposta, tornando os requisitos de dados explícitos e previsíveis.
As mutações são operações GraphQL que criam, atualizam ou excluem dados no servidor. Elas são análogas às operações POST, PUT, PATCH e DELETE em APIs RESTful. Embora os usuários possam acessar algumas consultas sem autenticação, mutações sempre exigem autenticação (por exemplo, por meio de um token de API).
Semelhante ao funcionamento das consultas, as mutações do GraphQL são validadas em relação ao esquema e suas definições. Após a mutação ser validada e iniciada, o servidor retorna uma resposta em JSON.
Mantenha-se atualizado sobre as tendências mais importantes (e intrigantes) do setor em IA, automação, dados e muito mais com o boletim informativo Think. Consulte a Declaração de privacidade da IBM.
Embora as APIs GraphQL tenham surgido como uma alternativa mais eficiente e flexível, o REST há muito tempo é o padrão para arquiteturas de APIs. REST é um estilo arquitetônico estruturado para aplicações de hipermídia em rede, projetado para usar um protocolo de comunicação cliente/servidor sem estado, com cache (geralmente HTTP).
Fazer a escolha entre GraphQL e REST trata-se, em sua maior parte, de determinar qual ferramenta é mais adequada para a tarefa em questão. Tanto o GraphQL quanto o REST permitem que os clientes se comuniquem com servidores e solicitem dados, mas há diferenças essenciais que explicam a proliferação dos sistemas GraphQL.
As APIs REST são projetadas em torno de recursos (por exemplo, qualquer tipo de objeto, dado ou serviço acessível ao cliente) e funcionam com diferentes endpoints (URLs) para cada recurso. Elas utilizam uma estrutura de dados fixa para determinar o formato e o tamanho dos recursos que fornecem aos clientes.
Quando o cliente solicita um recurso, o servidor retorna um conjunto completo de dados com todas as informações associadas a esse recurso. Se o cliente precisa apenas de um subconjunto dos dados, ainda assim recebe todos os dados (over-fetching); se o cliente precisa de dados que abrangem vários recursos, muitas vezes precisa fazer várias chamadas de API devido à recuperação insuficiente de dados na solicitação inicial (under-fetching).
O GraphQL, no entanto, utiliza um único endpoint que apresenta uma descrição completa e compreensível dos dados. Consultas GraphQL podem acessar propriedades de recursos e seguir referências entre recursos. Isso permite que o cliente obtenha todos os dados necessários de uma única carga de solicitação de API e evite problemas de busca excessiva (over-fetching) e insuficiente (under-fetching).
Em uma arquitetura RESTful, alterar a estrutura dos dados frequentemente exige que as equipes versionem a API para evitar erros no sistema e interrupções no serviço para o usuário.
Isso significa que os desenvolvedores precisam criar um novo endpoint sempre que alteram a estrutura, resultando em múltiplas versões da API e complicando o processo de manutenção.
O GraphQL elimina a necessidade de versionamento, porque os clientes podem especificar seus requisitos na consulta. Se novos campos forem adicionados ao servidor, os clientes que não precisam desses campos não serão afetados. Por outro lado, se os campos forem preteridos, os clientes poderão continuar a solicitá-los até que atualizem suas consultas.
APIs REST utilizam códigos de status HTTP para indicar o status/sucesso de uma solicitação. Cada código de status tem um significado específico. Uma solicitação bem-sucedida retorna um código de status 200, enquanto um erro do cliente pode retornar um código de status 400 e um erro do servidor pode retornar um código de status 500.
O GraphQL lida com erros de forma diferente. Toda solicitação, independentemente de resultar ou não em erro, retorna um código de status 200 OK. Os erros não são comunicados por meio de códigos de status HTTP; em vez disso, o sistema comunica os erros no corpo da resposta, junto com os dados.
Essa abordagem exige que os clientes analisem o corpo da resposta para determinar se a solicitação foi bem-sucedida, o que pode tornar a depuração de APIs GraphQL um pouco desafiadora.
REST não conta com suporte integrado para atualizações em tempo real. Se um aplicativo da web ou móvel precisar de funções em tempo real com uma API REST, os desenvolvedores geralmente terão que implementar técnicas como long-polling (em que o cliente pesquisa repetidamente o servidor para receber novos dados), eventos enviados pelo servidor e WebSockets, o que pode aumentar a complexidade do aplicativo.
No entanto, o GraphQL inclui suporte nativo para atualizações em tempo real por meio de assinaturas. As assinaturas mantêm uma conexão constante com o servidor, permitindo que o servidor envie atualizações ao cliente sempre que eventos específicos ocorrerem e permitindo que os clientes se mantenham atualizados com os dados relevantes da API.
O ecossistema REST está bem estabelecido, com uma ampla variedade de ferramentas, bibliotecas, frameworks e tutoriais disponíveis para desenvolvedores. No entanto, trabalhar com APIs REST frequentemente exige que as equipes naveguem por diversos endpoints e compreendam as convenções e os padrões específicos de cada API.
O GraphQL é relativamente novo, mas o ecossistema GraphQL cresceu enormemente desde sua introdução, com diversas ferramentas e bibliotecas disponíveis tanto para o desenvolvimento de serviços no front-end quanto no back-end.
Ferramentas como GraphiQL, Apollo Studio e GraphQL Playground oferecem ambientes de desenvolvimento integrados (IDEs) poderosos no navegador para explorar e testar APIs GraphQL. Além disso, o GraphQL tem forte suporte para geração de código, o que pode simplificar o desenvolvimento no lado do cliente.
APIs REST dependem de mecanismos de cache HTTP, como ETags e cabeçalhos modificados por último. Embora eficazes, as estratégias de cache podem ter implementação complexa e podem não otimizar o desempenho de maneira uniforme em todos os casos de uso.
As APIs GraphQL podem ser mais difíceis de armazenar em cache devido à natureza dinâmica das consultas. No entanto, o uso de consultas persistidas, cache de resposta e cache do lado do servidor pode mitigar esses desafios e fornecer estratégias eficientes de cache para arquiteturas GraphQL.
Desde a transição do GraphQL para a GraphQL Foundation, desenvolvedores criaram implementações para diversas linguagens de programação, incluindo JavaScript, Python, Ruby e PHP, entre outras. As APIs GraphQL foram adotadas por inúmeras empresas, como Github, Pinterest, PayPal, Shopify, Airbnb e muitas outras, permitindo que mais clientes simplifiquem a especificação de dados, reduzam a transmissão excessiva ou inadequada de dados na rede e melhorem a capacidade geral de busca de dados.1
Além disso, empresas e desenvolvedores estão promovendo a federação aberta de arquiteturas GraphQL. Na sua iteração atual, a federação GraphQL reúne serviços GraphQL separados e os agrega em uma única API GraphQL, que serve como ponto de entrada para todos os dados de back-end subjacentes e facilita a recuperação de dados com uma única solicitação. No entanto, a implementação da federação é exclusiva de um único fornecedor.
Como resposta, os defensores do GraphQL advogam por uma federação democratizada, que facilite a agregação de dados tanto de APIs GraphQL quanto de APIs que não são GraphQL, em vez de uma agregação exclusiva de GraphQL.2
Crie APIs seguras e flexíveis com mais rapidez e menos código, unificando dados para acelerar o desenvolvimento e a inovação.
Conecte, automatize e quebre silos de dados para liberar inovação e velocidade com integração segura e unificada.
Maximize o valor da nuvem híbrida na era da IA agêntica. Acelere a transformação, modernize as aplicações e automatize a TI para gerar eficiência, sustentabilidade e inovação mais rápida.
1 IBM acquires GraphQL startup StepZen to step up its game in API Management, TechCrunch, 8 de fevereiro de 2023
2 Why GraphQL Needs an Open Federation Approach, The New Stack, 16 de novembro de 2023