Publicado: 8 de dezembro de 2023
contribuidores: Chrystal R. China, Michael Goodwin
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).
Usando uma sintaxe intuitiva que permite aos usuários fazerem solicitações de API em uma única linha ou algumas linhas (em vez de acessar endpoints complexos com muitos parâmetros), as tecnologias GraphQL tornam mais fácil gerar e responder a consultas de API. GraphQL representa uma evolução em relação às arquiteturas RESTful tradicionais.
No início dos anos , o Facebook estava enfrentando um enorme crescimento e transformação. Mas uma base de usuários crescente e um ambiente de aplicativo móvel cada vez mais complexo tornaram sua abordagem RESTful existente — que exigia várias viagens de ida e volta para diferentes pontos de extremidade para buscar todos os dados de consulta necessários — insustentável.
As APIs REST (Representational State Transfer) e RESTful não estavam preparadas 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 e/ou caros.
Diante desses desafios, os engenheiros do Facebook desenvolveram o GraphQL (junto com a plataforma de aplicativos de página única React), lançando-o como uma solução de código aberto em 2015. Por fim, o Facebook migrou o serviço para a Fundação GraphQL, que inclui empresas membros como AWS, Gatsby, Intuit e IBM, em 2018.
Saiba como detalhar silos de dados e, ao mesmo tempo, escrever menos código com APIs altamente responsivas do GraphQL.
O IBM API Connect ganha os principais reconhecimentos.
Os recursos de busca de dados declarativos da arquitetura GraphQL giram em torno de vários componentes e processos-chave, cada um desempenhando um papel único no tratamento e processamento de dados.
São elas:
O GraphQL depende de um sistema de tipos forte, onde todos os tipos de dados são registrados na linguagem de definição de esquema do GraphQL (SDL). Esquemas digitados ditam os tipos de dados que podem ser consultados na API, bem como as relações entre os 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.
Cada campo em um esquema é apoiado por um resolver que preenche os dados e determina a resposta a um conjunto de campos. Resolvers, que têm a capacidade de obter dados de um banco de dados, de um serviço de nuvem ou de praticamente qualquer outra fonte, fornecem instruções para transformar uma operação GraphQL (por exemplo, uma consulta, mutação ou assinatura) em dados.
Quando um campo de consulta é executado, o sistema gera uma chamada para o resolver correspondente para produzir o próximo valor. Se um campo produzir um valor escalar (por exemplo, uma string ou número), a execução será concluída. Se um campo produzir um valor de objeto, a consulta conterá mais campos para esse objeto. Esse processo continua até que apenas campos escalares sejam deixados.
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; Ele especifica quais dados o cliente deseja buscar. Quando uma consulta chega, o GraphQL a valida em relação às definições de esquema e, supondo que a consulta seja válida, a executa. A estrutura de uma consulta normalmente espelha a estrutura dos dados de resposta, tornando os requisitos de dados explícitos e previsíveis.
As mutações são operações do GraphQL que criam, atualizam ou excluem dados no servidor. Elas são análogas às operações POST, PUT, PATCH e DELETE nas APIs RESTful.
Assim como as 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 executada, o servidor retorna uma resposta JSON.
Embora as APIs do GraphQL tenham surgido como uma alternativa mais eficiente e flexível, REST e RESTful foram por muito tempo o padrão para arquiteturas de API. A REST API é um estilo arquitetural estruturado para aplicativos hipermídia em rede, projetado para utilizar um protocolo de comunicação cliente-servidor, onde as respostas podem ser armazenadas temporariamente para uso posterior, sem a necessidade de revalidação com o servidor (geralmente usando HTTP).
Embora o GraphQL e o REST possibilitem a comunicação entre clientes e servidores para solicitar dados, suas distinções fundamentais explicam por que os sistemas GraphQL estão se tornando tão difundidos.
REST APIs são projetadas em torno de recursos (por exemplo, qualquer tipo de objeto, dados ou serviço acessível ao cliente) e funcionam com endpoints (URLs) diferentes para cada recurso. Eles usam uma estrutura de dados fixa para determinar a forma e o tamanho dos recursos que fornecem aos clientes.
Quando o cliente solicita um recurso, o servidor envia todos os dados associados a esse recurso. Se um cliente precisar apenas de um subconjunto dos dados, ainda assim receberá todos os dados (sobrecarregamento); se o cliente precisar de dados que abrangem vários recursos, muitas vezes terá que fazer várias chamadas de API devido à recuperação inadequada de dados na solicitação inicial (subrecarregamento).
O GraphQL, por outro lado, usa um único endpoint que fornece uma descrição completa e compreensível dos dados. As consultas do GraphQL podem acessar as propriedades dos recursos e seguir referências entre recursos, permitindo que o cliente obtenha todos os dados necessários em uma única solicitação ao servidor GraphQL e evite problemas de sobrecarregamento e subrecarregamento.
Em uma arquitetura REST, a alteração da estrutura dos dados geralmente exige que as equipes versionem a API para evitar erros no sistema e interrupções no serviço para o usuário final. Isso significa que os desenvolvedores precisam criar um novo endpoint toda vez que alteram a estrutura, resultando em várias 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.
REST APIs usam 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. Cada solicitação, independentemente de ter resultado em um erro, retorna um código de status 200 OK. Os erros não são comunicados usando códigos de status HTTP; em vez disso, o sistema comunica os erros no corpo da resposta juntamente com os dados. Essa abordagem, os clientes precisam examinar 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 possui suporte integrado para atualizações em tempo real. Se um aplicativo web ou móvel precisar de funcionalidade em tempo real com uma REST API, os desenvolvedores geralmente precisam implementar técnicas como long-polling (onde o cliente faz repetidas consultas ao servidor em busca de novos dados), eventos enviados pelo servidor e WebSockets, o que pode adicionar complexidade à aplicação.
No entanto, o GraphQL inclui suporte integrado para atualizações em tempo real usando assinaturas. As assinaturas mantêm uma conexão constante com o servidor, permitindo que o servidor envie atualizações para o cliente sempre que eventos específicos ocorrem 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 e estruturas disponíveis para desenvolvedores. No entanto, trabalhar com REST APIs geralmente exige que as equipes naveguem por vários endpoints e entendam as convenções/padrões exclusivos de cada API.
O GraphQL é relativamente novo, mas o ecossistema do GraphQL cresceu tremendamente desde sua introdução, com uma variedade de ferramentas e bibliotecas disponíveis tanto para o desenvolvimento de serviços frontend quanto backend. Ferramentas como GraphiQL, Apollo Studio e GraphQL Playground fornecem ambientes de desenvolvimento (IDEs) integrados no navegador para explorar e testar APIs GraphQL. Além disso, o GraphQL tem suporte robusto para geração de código, o que pode simplificar o desenvolvimento do lado do cliente.
REST APIs dependem de mecanismos de cache HTTP, como ETags e cabeçalhos modificados por último. Embora eficaz, as estratégias de cache podem ser complexas de implementar e podem não otimizar consistentemente o desempenho para todos os casos de uso.
APIs do 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 Fundação GraphQL, os desenvolvedores criaram implementações para uma variedade de linguagens de programação, incluindo JavaScript, Python, Ruby e PHP, entre outras. E as APIs GraphQL foram adotadas por inúmeras empresas, como Github, Pinterest, Paypal, Shopify, Airbnb e mais1, permitindo que mais clientes otimizem a especificação de dados, reduzam a transmissão excessiva ou inadequada de dados pela rede e melhorem as capacidades gerais de recuperação de dados.
Além disso, empresas e desenvolvedores estão promovendo a federação aberta de arquiteturas GraphQL. Em sua iteração atual, a federação GraphQL combina serviços GraphQL separados em uma única API GraphQL, que atua como ponto de entrada para todos os dados de backend subjacentes e facilita a recuperação de dados em uma única solicitação. Infelizmente, no entanto, a implementação de federação é exclusiva para um único fornecedor.
Como resposta, a IBM está defendendo federação democratizada, o que facilita a agregação de dados de APIs GraphQL e APIs não GraphQL em vez de agregação exclusiva do GraphQL.2
O IBM API Connect é uma solução completa de gerenciamento de APIs que utiliza uma experiência intuitiva para ajudar a criar, gerenciar, proteger, socializar e monetizar APIs de forma consistente, ajudando a impulsionar a transformação digital no local e na nuvem.
O IBM API Connect facilita a construção e implementação de uma API GraphQL em nível de produção em questão de minutos. Basta fornecer os detalhes de conexão da sua fonte de dados e uma API GraphQL segura e otimizada será gerada instantaneamente.
Conheça as duas abordagens diferentes que essas estruturas adotam para desenvolver APIs e os pontos fortes e fracos de cada uma.
Consulte o Gartner Magic Quadrant for API Management para descobrir por que a IBM continua sendo reconhecida como líder em Gestão de APIs.
Explore o IBM API Connect toolkit.
Maximize o valor de API para impulsionar negócios digitais com uma solução abrangente de gerenciamento de APIs.
A IBM foi nomeada Líder no Relatório Gartner de 2023: Critical Capabilities for API Management.
Esses tutoriais fornecem instruções práticas que ajudam os desenvolvedores a aprender como usar as tecnologias em seus projetos.
Notas de rodapé
1"A IBM compra a StepZen, uma startup de GraphQL, para aprimorar seu jogo no gerenciamento de APIs" (link externo ao site ibm.com), TechCrunch, 8 de fevereiro de 2023
2"Por que o GraphQL precisa de uma Abordagem de Federação Aberta" (link externo ao site ibm.com), The New Stack, 16 de novembro de 2023