O crescimento do GraphQL explode, mas também os problemas que os gráficos federados resolvem

GraphQL é uma linguagem de consulta que permite aos usuários encontrar e solicitar dados de servidores de forma que possam especificar o tipo de dados que desejam por meio da API de maneira mais precisa do que por meio de outros tipos de estruturas de API. Uma plataforma GraphQL federada permite que diferentes esquemas sub-GraphQL sejam usados ​​de forma desacoplada, mas por meio de uma única interface API da plataforma GraphQL. Ambos se tornaram e continuarão a se tornar enormemente populares.

Estatísticas divulgadas recentemente pelo relatório do Gartner revelam como mais de 60% das empresas usarão GraphQL na produção, contra menos de 30% em 2024. Em 2027, 30% das empresas que usam GraphQL usarão a federação GraphQL, contra menos de 5% em 2024, informou o Gartner.

Portanto, a adoção federada do GraphQL irá, de acordo com o Gartner, aumentar cinco vezes durante os próximos três anos, enquanto a adoção do GraphQL “apenas” dobrará.

Por que?

Porque o Federated GraphQL resolve um grande problema: a chamada expansão do GraphQL. Esse fenômeno, conhecido como expansão do GraphQL, ocorre quando vários GraphQL e outras APIs proliferam em uma organização.

As estatísticas do Gartner destacam a eficácia do GraphQL como uma forma muito inteligente e confiável de conduzir consultas por meio de uma API. No entanto, surge um problema potencial quando os usuários de uma empresa começam a utilizar seu próprio GraphQL ou outras APIs para vários fins legítimos em paralelo, levando à dificuldade de manejo que a expansão causa. Antes de nos aprofundarmos, vamos estabelecer definições claras para GraphQL e uma plataforma GraphQL federada.

O Gartner define GraphQL assim:

“GraphQL é uma especificação aberta para implementação de APIs, que permite aos consumidores especificar o conteúdo que solicitam de um serviço. Ele fornece aos desenvolvedores um sistema de tipos para definir dados e um mecanismo do lado do servidor para consultar elementos de dados específicos de que precisam. A especificação também fornece uma linguagem de consulta para os consumidores da API definirem consultas e mutações para atualização, e assinaturas para solicitar notificações de dados alterados.”

Federado e menos espalhado

Voltando à questão da expansão do GraphQL, o Federated GraphQL oferece uma solução ao consolidar instâncias diferentes. Veja o Netflix, por exemplo; após adotar o GraphQL, eles descobriram inúmeras instâncias espalhadas por sua infraestrutura. Ao mesmo tempo, eles utilizaram vários outros tipos de API, como APIs GRPC e REST. Inicialmente, eles tentaram centralizar o GraphQL em uma única API ou monólito, o que se mostrou restritivo. No entanto, o gateway federado GraphQL, fornecido pela Apollo, resolveu esse desafio de forma eficaz.

Como Geoff Schmidt, CEO e cofundador da Apollo GraphQL me explicou durante KubeCon + CloudNativeCOn, GraphQL – como SQL – é uma linguagem de consulta e especificação, em vez de um software específico. Embora existam implementações de GraphQL, como Apollo Federation, o próprio GraphQL é um padrão que define como os clientes podem solicitar dados de servidores, disse Schmidt. É semelhante a como SQL é uma linguagem usada para interagir com bancos de dados, mas vários sistemas de gerenciamento de banco de dados implementam SQL, como PostgreSQL ou MySQL. Portanto, o GraphQL pode ser implementado por diferentes plataformas e frameworks, mas não é um projeto de software independente no mesmo sentido que um sistema de gerenciamento de banco de dados, disse ele.

“A adoção do GraphQL, especialmente com o conceito de federação GraphQL, ajudou a agilizar o acesso a dados em vários microsserviços dentro das empresas, promovendo plataformas de autoatendimento e eficiência de API”, disse Schmidt.

Existem muitos mal-entendidos não apenas sobre o que é o GraphQL federado, mas também sobre o que o GraphQL faz ou está em sua origem. O que o GraphQL não é é um projeto de código aberto. Muitas vezes é relatado erroneamente que o GraphQL é de código aberto do Facebook, mas na verdade ele não existe como um projeto de código aberto.

Ao mesmo tempo, GraphQL não compete nem substitui APIs REST. Isso ocorre porque eles podem ser usados ​​em conjunto. Conforme relatado, a linguagem de definição de esquema do GraphQL pode ser usada em conjunto com REST de algumas maneiras. Por exemplo, uma camada GraphQL federada pode abstrair endpoints REST e ser integrada como um esquema GraphQL separado.

Essa arquitetura costuma ser chamada de supergráfico ou gráfico federado – que foi introduzido pela Apollo em 2019. Ela cria uma camada de abstração que pode substituir a maioria das APIs de back-end ou front-end Backend-for-Frontend (BFFs) ou APIs de experiência.

Como explicou Schmidt: “Há uma distinção a ser feita. GraphQL não é semelhante a um software como SQL; em vez disso, funciona como um recurso ou linguagem. O SQL, por outro lado, opera como um meio padrão de consulta de bancos de dados, sendo vários bancos de dados SQL, como o Postgres, entidades de software tangíveis. É essencial entender que o GraphQL, assim como o SQL, serve como um método de consulta de dados, e não como um produto de software independente.”

Em relação ao início do GraphQL, o Facebook não lançou o código GraphQL real, mas sim uma especificação semelhante ao lançamento do SQL pela IBM em um artigo acadêmico. “Apesar disso, a adoção do GraphQL disparou, especialmente com o conceito de federação GraphQL ganhando força. Esta abordagem enfatiza a necessidade de integrar perfeitamente microsserviços díspares, promovendo uma plataforma de autoatendimento dentro das empresas”, disse Schmidt. “A essência está na criação de uma plataforma de API que otimize o uso da API, combatendo o problema predominante de APIs desarticuladas que assola muitas organizações.”

Que alternativas as pessoas têm além de juntá-las manualmente? Schmidt disse: “Bem, eles acabam escrevendo códigos extensos”, disse Schmidt. “Poderia ser denominado API de experiência, API de integração ou Backend para Frontend.” Independentemente do rótulo, o processo de escrita de código normalmente envolve a elaboração de um processo Java, .NET ou Node.js, personalizado para servir como um servidor processador, disse Schmidt. Essencialmente, ele recebe solicitações de API do cliente, instruindo-o a buscar dados para diversas funcionalidades. Posteriormente, ele chama vários serviços de back-end, consolida os dados e os entrega como um proxy ou integração API para API. “Esta abordagem consome uma quantidade cada vez maior de recursos empresariais e muitas vezes resulta numa infinidade de soluções desconexas, cada uma abordando apenas parte do problema”, disse Schmidt.

Conseqüentemente, a desilusão se instala à medida que a complexidade cresce exponencialmente. Como bem disse um analista, esse processo se assemelha a uma confusão contínua que fica fora de controle. No entanto, há esperança. “Recentemente ouvi um cliente comentar que a adoção do GraphQL transformou sua situação de código espaguete em camadas bem estruturadas, comparando-a à mudança de espaguete para lasanha – uma melhoria significativa”, disse Schmidt.

A Apollo emergiu como líder graças ao seu trabalho pioneiro no desenvolvimento da Apollo Federation, “a principal plataforma GraphQL federada”, disse Schmidt. “Enquanto outros tentam replicar nosso sucesso, criar uma solução GraphQL federada viável não é tarefa fácil. É necessário um planejador de consultas robusto e um investimento significativo, semelhante aos desafios enfrentados pela Oracle ao estabelecer o SQL como padrão. Tais esforços exigem recursos substanciais e estão além do escopo do financiamento de equipes pequenas ou médias para serem concluídos.”

Não é realmente algo que você possa fazer com uma equipe de 20 pessoas ou mesmo com uma equipe de 100 pessoas, observou Smith. Não é realmente algo que você possa fazer extracurricularmente e, ao mesmo tempo, tentar atender a outros casos de uso de API.

A postagem O crescimento do GraphQL explode, mas também os problemas que os gráficos federados resolvem apareceu pela primeira vez em The New Stack.