O papel e o impacto do GraphQL
Por Rajesh Narayanan
Revisado por e com contribuições da equipe OCTO e de outros colaboradores.
Opinião do Escritório do CTO da F5
O GraphQL surgiu como uma abordagem moderna e eficiente para o desenvolvimento de APIs, superando as limitações das APIs REST tradicionais. Embora o REST seja amplamente utilizado desde os primórdios da web, o GraphQL oferece uma nova perspectiva e maior controle aos desenvolvedores. Com o GraphQL, os desenvolvedores podem definir um esquema fortemente tipado que permite aos clientes solicitar com precisão os dados de que precisam. Ao eliminar a obtenção excessiva ou insuficiente de dados, o GraphQL otimiza o desempenho e facilita a criação de aplicações web modernas e interativas com requisitos complexos de consulta e modelagem de dados.
No entanto, reconhecemos que o GraphQL também apresenta desafios. Este artigo oferece uma visão sobre as preocupações de segurança e a curva de aprendizado associadas à adoção do GraphQL. Analisamos estudos de caso reais que descrevem os benefícios obtidos por empresas renomadas que implementaram o GraphQL com sucesso.
Além disso, apresentamos nossa própria investigação sobre o GraphQL, compartilhando nossas experiências e descobertas. Oferecemos uma breve introdução ao GraphQL, comparamos essa tecnologia ao REST e analisamos em profundidade os desafios que ela soluciona. Também abordamos questões de segurança para ajudar as organizações a tomar decisões bem fundamentadas. Nossa pesquisa revela o potencial transformador do GraphQL. Demonstramos como simplificamos a arquitetura de um software de gerenciamento de testes, o que resultou em um aumento de mais de 300% na quantidade de dados expostos que estavam ocultos em objetos JSON por meio do GraphQL.
Em conclusão, recomendamos enfaticamente que as empresas que enfrentam dificuldades para dimensionar, otimizar ou operar uma infraestrutura de API REST considerem o GraphQL como uma solução viável. Nossos insights oferecem orientações práticas para quem está iniciando sua jornada com o GraphQL, permitindo aproveitar seus benefícios e superar desafios de forma eficaz.
Introdução ao GraphQL
POR QUE GRAPHQL?
As limitações das APIs REST estão impulsionando a demanda por uma nova abordagem tecnológica para APIs.
A abordagem baseada em REST (Transferência de Estado Representacional) foi originalmente proposta como um conjunto de princípios arquitetônicos para o desenvolvimento de APIs web. O REST evoluiu ao longo das décadas de 2000 e 2010, com o surgimento da Web 2.0, tornando-se uma alternativa melhor para implementar a arquitetura orientada a serviços (SOA) em comparação com outras tecnologias, como a Arquitetura de Agente de Solicitação de Objeto Comum (CORBA).
À medida que o número de clientes cresceu devido à adoção de dispositivos móveis, aumentou a demanda por dados precisos. No entanto, as APIs baseadas em REST frequentemente resultavam na obtenção de dados em excesso ou em quantidade insuficiente, gerando ineficiências. Essa abordagem, exemplificada por aplicativos como o Facebook, muitas vezes exigia inúmeras chamadas à API REST para uma única atualização, aumentando o tráfego de rede e prejudicando o desempenho e a experiência do usuário.
O GraphQL foi projetado especificamente para superar essas limitações, oferecendo um esquema fortemente tipado e uma maneira mais eficiente de consultar dados. Isso o torna ideal para casos de uso em que dados específicos são necessários para otimizar a largura de banda da rede. Além disso, a capacidade do GraphQL de realizar a introspecção do esquema possibilita uma documentação e ferramentas melhores. Embora uma implementação mais padronizada de REST pudesse ter oferecido alguma concorrência, os recursos e benefícios exclusivos do GraphQL fazem dele uma opção atraente para arquiteturas de aplicações modernas, distribuídas e com uso intensivo de dados.
A Figura 1 mostra uma diferença topológica na forma como REST e GraphQL são implementados. Conforme afirmado em API REST vs. GraphQL, “a principal diferença entre as APIs GraphQL e REST é que GraphQL é uma linguagem de consulta, enquanto REST é um conceito arquitetural para software baseado em rede.”
A MOTIVAÇÃO DA META PARA O GRAPHQL
A Meta criou o GraphQL em 2012 (disponibilizado como código aberto em 2015) para melhorar o desempenho e a flexibilidade de seus aplicativos móveis. Antes do GraphQL, os aplicativos móveis da Meta eram desenvolvidos usando uma combinação de APIs RESTful e código nativo, o que dificultava a compatibilidade com a grande variedade de dispositivos, tamanhos de tela e condições de rede que os aplicativos precisavam oferecer.
Um dos principais desafios enfrentados era que as APIs RESTful frequentemente retornavam uma quantidade inadequada de dados — às vezes, dados demais; outras vezes, dados de menos. Quando a API retornava uma grande quantidade de dados desnecessários para os aplicativos móveis, isso resultava em tempos de carregamento mais longos e baixo desempenho. Quando a API retornava poucos dados, os aplicativos móveis precisavam fazer várias solicitações a diferentes endpoints para obter todos os dados necessários, aumentando a latência e a complexidade do processo.
A Meta desenvolveu o GraphQL para que qualquer aplicativo pudesse solicitar apenas os dados necessários em uma única requisição. Isso possibilitou otimizar a transferência de dados entre os aplicativos móveis e os serviços de backend, resultando em tempos de carregamento mais rápidos e melhor desempenho. Além disso, a tipagem forte e os recursos de autodocumentação do GraphQL facilitaram a compreensão e o consumo da API pelos desenvolvedores.
VANTAGENS DO GRAPHQL
O GraphQL oferece recursos avançados para recuperação e manipulação de dados, proporcionando benefícios significativos em relação às abordagens tradicionais de API.
Esquemas fortemente tipados
O GraphQL conta com um esquema fortemente tipado que garante clareza e precisão na definição da estrutura e dos tipos de dados que podem ser consultados em uma API. Digamos que tenhamos uma API para uma biblioteca que contém livros, autores e editoras.
a) Esquema GraphQL: No GraphQL, um esquema fortemente tipado seria como o mostrado na Figura 2 abaixo:
Os esquemas fortemente tipados no GraphQL oferecem benefícios relacionados à segurança ao permitir a validação de entradas, evitar a busca excessiva ou insuficiente de dados, fornecer documentação clara e suporte a ferramentas, facilitar o controle de versão e auxiliar na autorização e no controle de acesso. Esses recursos aumentam a segurança da API, reduzindo o risco de vulnerabilidades comuns e garantindo o tratamento adequado dos dados e o gerenciamento de acesso.
No exemplo apresentado (Figura 2), o esquema define os tipos de dados de livros, autores e editoras, bem como as relações entre eles. O esquema é fortemente tipado, o que significa que cada campo tem um tipo de dado específico, e os clientes podem facilmente inspecionar o esquema para descobrir os campos disponíveis e seus respectivos tipos.
b) Esquema REST: No REST, a definição do esquema teria tipagem flexível, conforme mostrado na Figura 3 abaixo:
Esses endpoints retornam objetos JSON que representam os livros, autores e editoras, mas o esquema em si não é definido explicitamente e fica a cargo da habilidade e interpretação do programador. Os clientes terão que consultar a documentação para entender a estrutura dos dados.
Além do REST
O GraphQL evoluiu para além de ser apenas uma alternativa melhor ao REST e tem potencial para se tornar a abordagem preferencial de empresas que buscam uma estratégia de dados mais eficiente. Além de superar as limitações do REST, há vários outros motivos pelos quais o GraphQL se consolidou como uma nova abordagem para o design de APIs. Embora a tabela (Figura 4) possa mostrar as vantagens do GraphQL em relação ao REST, é mais adequado considerar o GraphQL uma resposta à evolução da internet e das diferentes aplicações, e não à identificação de problemas no próprio REST.
| ATRIBUTOS | GRAPHQL | REST |
|---|---|---|
MODELAGEM FLEXÍVEL DE DADOS |
O GraphQL permite que os desenvolvedores definam e aprimorem APIs com facilidade para atender a requisitos em constante mudança. Os clientes podem especificar com precisão os dados de que precisam usando a linguagem de consulta, o que possibilita um processo de recuperação de dados mais flexível e eficiente. |
Normalmente, o servidor define endpoints fixos que retornam estruturas de dados predefinidas. Os clientes têm controle limitado sobre o formato e a estrutura da resposta, o que muitas vezes resulta na obtenção de dados em excesso ou em quantidade insuficiente. O REST não oferece o controle granular sobre a recuperação e a composição de dados disponibilizado pelo GraphQL. |
CONSULTAS EM LOTE |
O GraphQL permite combinar várias consultas em uma única solicitação, o que pode reduzir significativamente o número de interações entre o cliente e o servidor e melhorar o desempenho. |
O REST não possui um mecanismo integrado para agrupar várias consultas em uma única solicitação. Cada solicitação REST normalmente corresponde a um único recurso ou endpoint. Alguns frameworks ou extensões REST podem oferecer maneiras de agrupar várias solicitações, mas elas não são nativas nem padronizadas como no GraphQL. |
CONSULTAS E RESPOSTAS TIPADAS |
Os clientes podem especificar exatamente os dados de que precisam, e os servidores podem responder apenas com os dados solicitados, reduzindo a obtenção de dados em excesso ou em quantidade insuficiente. Além disso, o GraphQL possui tipagem forte, o que ajuda a evitar erros e melhora o suporte das ferramentas. |
A tipagem não é imposta de forma inerente nas consultas e respostas. A estrutura e o formato dos dados normalmente são predefinidos pelo servidor, e os clientes precisam interpretar e processar os dados de acordo com essas definições. Isso pode resultar em menor segurança de tipos. |
INTEGRAÇÃO COM FRAMEWORKS DE FRONT-END |
O GraphQL foi projetado para funcionar bem com frameworks de front-end como React e Vue, facilitando a criação de aplicações web modernas e interativas. O GraphQL conta com bibliotecas e ferramentas específicas para uma integração perfeita. |
Embora o REST possa ser usado com frameworks de front-end, a integração pode exigir mais trabalho manual e implementações personalizadas. Apesar da existência de bibliotecas de terceiros, o REST não oferece uma maneira padronizada de integração com frameworks de front-end específicos, como React ou Vue. |
CONSULTAS BASEADAS EM GRAFOS |
O GraphQL permite realizar consultas complexas que abrangem vários recursos e relacionamentos em uma única solicitação, facilitando a obtenção dos dados necessários para criar interfaces de usuário complexas. |
O REST normalmente segue uma abordagem centrada em recursos, na qual cada endpoint representa um recurso ou uma entidade específica. Ele não oferece de forma inerente um mecanismo para consultar dados de vários recursos ou relacionamentos em uma única solicitação. |
DESEMPENHO |
A capacidade do GraphQL de solicitar com precisão apenas os dados necessários pode tornar a recuperação de dados mais eficiente e melhorar o desempenho. |
As APIs REST podem obter dados em excesso ou em quantidade insuficiente, pois os clientes têm controle limitado sobre a estrutura da resposta. Isso pode afetar o desempenho, principalmente se a API retornar dados excessivos ou desnecessários. |
PRODUTIVIDADE DOS DESENVOLVEDORES |
A natureza autodocumentada do GraphQL, com recursos de introspecção, reduz a necessidade de documentação extensa e promove uma melhor compreensão do modelo de dados. O esquema com tipagem forte e a validação de consultas promovem um entendimento compartilhado e detectam erros antecipadamente. O GraphQL possui uma linguagem de consulta intuitiva e uma curva de aprendizado mais simples, facilitando a integração de novos integrantes e a transferência de conhecimento nas equipes de desenvolvimento. |
Devido à falta de um contrato padronizado entre o cliente e o servidor, o conhecimento informal da equipe fica prejudicado. As APIs REST normalmente dependem de documentação informal ou de convenções que variam entre diferentes implementações. A falta de um entendimento compartilhado gera inconsistências e lacunas de conhecimento nas equipes. Isso faz com que os desenvolvedores mais antigos na equipe precisem dedicar um tempo valioso à capacitação dos demais integrantes, em vez de se concentrarem no problema de negócio. Essa dependência de indivíduos para a documentação resulta em conhecimento informal fragmentado, dificultando que todos os integrantes da equipe tenham uma compreensão abrangente dos recursos e das estruturas de dados da API. |
VERSIONAMENTO DE API |
A vantagem inerente do GraphQL em relação ao versionamento está na possibilidade de marcar como obsoletos os campos que serão removidos, dando aos desenvolvedores do lado do cliente tempo para se adaptarem. Ainda é possível adotar um versionamento semelhante ao das APIs REST. |
Marcar campos como obsoletos não é um recurso inerente ao REST. Cabe aos desenvolvedores do lado do cliente garantir que estejam usando a versão correta da API. |
Figura 4: Vantagens do GraphQL em relação ao REST
DESAFIOS DO GRAPHQL
Embora o GraphQL ofereça muitas vantagens em relação às APIs RESTful tradicionais, seu uso também apresenta alguns desafios. Entre os desafios mais comuns estão:
- Curva de aprendizado: Como a maioria dos desenvolvedores está mais familiarizada com REST, as organizações que pretendem adotar o GraphQL precisarão reservar tempo para que suas equipes aprendam a usá-lo de forma eficaz. O GraphQL exige uma maneira diferente de pensar sobre a criação e o consumo de APIs, e sua adoção pode exigir mudanças na arquitetura subjacente da aplicação. Talvez os desenvolvedores precisem aprender novos conceitos, como esquemas, resolvedores e tipos, além de novas ferramentas e bibliotecas. Com o GraphQL, os clientes têm mais controle sobre os dados que podem acessar, o que pode dificultar a proteção das APIs. Técnicas como validação de entrada, autenticação e autorização talvez precisem ser aplicadas de maneira diferente em comparação com as APIs RESTful.
- Cache: O uso de cache pode ser mais complexo com o GraphQL, pois os clientes podem solicitar dados diferentes a cada consulta, dificultando o armazenamento em cache e a reutilização das respostas.
- Desempenho: Embora o GraphQL permita que os clientes solicitem apenas os dados de que precisam, ele também pode possibilitar consultas mais complexas e que consomem mais recursos. As APIs GraphQL podem apresentar problemas de desempenho, especialmente ao consultar grandes conjuntos de dados ou quando há um grande número de solicitações simultâneas. Os desenvolvedores precisam implementar estratégias como limitar a profundidade das consultas ou garantir que os clientes estejam autorizados a acessar apenas os dados específicos necessários.
- Tratamento de erros: o GraphQL pode tornar o tratamento de erros mais complexo, pois os erros podem ser retornados como parte da resposta, em vez de como um código de status HTTP separado.
- Testes: Testar com GraphQL apresenta desafios devido à complexidade das consultas, à falta de abordagens de teste padronizadas, à evolução do esquema e à validação das consultas durante a execução. Os desenvolvedores precisam dedicar tempo para encontrar frameworks e ferramentas de teste adequados para enfrentar esses desafios. Eles também precisam garantir uma cobertura de testes abrangente, selecionando as ferramentas apropriadas e considerando a evolução do esquema para testar APIs GraphQL de forma eficaz e assegurar sua funcionalidade e estabilidade.
- Monitoramento: Monitorar APIs GraphQL pode ser desafiador devido à complexidade das consultas, à falta de registros e métricas padronizados e à possibilidade de problemas de desempenho. A natureza dinâmica das consultas GraphQL dificulta a previsão e o monitoramento da estrutura e do tamanho dos dados solicitados. A ausência de ferramentas de monitoramento padronizadas específicas para APIs GraphQL dificulta a obtenção de informações sobre o desempenho das consultas GraphQL, o rastreamento de erros e a integridade da API. Os desenvolvedores precisam adotar ferramentas e práticas de monitoramento especializadas que sejam capazes de lidar com as características específicas do GraphQL, garantindo um desempenho eficiente e uma operação confiável.
Padrões de uso do GraphQL
O GraphQL é uma ferramenta poderosa que pode ser usada em uma ampla variedade de aplicações, desde a criação de APIs até o funcionamento de aplicativos móveis. Sua flexibilidade e capacidade de unificar fontes de dados o tornam adequado para diversos padrões de uso.
- Criação de APIs eficientes: Um dos principais usos do GraphQL é criar APIs que possam ser consumidas por aplicações web e móveis. O GraphQL oferece uma maneira flexível e poderosa de definir e acessar dados, sendo ideal para criar APIs que precisam oferecer suporte a uma ampla variedade de clientes e casos de uso.
- Busca e manipulação de dados: o GraphQL pode ser usado para buscar e manipular dados de diversas fontes, incluindo bancos de dados, serviços em nuvem e outras APIs. Ao oferecer uma maneira unificada de acessar dados, o GraphQL pode ajudar a simplificar o processo de desenvolvimento e manutenção de aplicações orientadas por dados.
- Casos de uso em tempo real: o GraphQL é ideal para casos de uso em tempo real, pois os clientes podem assinar atualizações de dados específicos e receber notificações quando esses dados forem alterados. Isso pode ser usado em aplicações como chats, transmissões ao vivo, painéis em tempo real e muito mais.
- Microsserviços: o GraphQL pode ser usado para criar uma arquitetura flexível e com baixo acoplamento, permitindo que diferentes microsserviços se comuniquem entre si de maneira consistente e bem definida.
- Do back-end para o front-end: o GraphQL pode ser usado para criar uma arquitetura de back-end para front-end (BFF), permitindo que diferentes clientes front-end acessem dados e serviços de forma consistente e eficiente.
- Desenvolvimento mobile: o GraphQL pode ser usado para viabilizar aplicativos móveis, oferecendo uma forma consistente e eficiente de acessar dados e serviços, independentemente da plataforma ou do dispositivo.
Experiências de adoção do GraphQL no setor (estudos de caso)
Há motivos claros para precisarmos do GraphQL, como demonstram as seguintes implementações no setor:
NETFLIX
A Netflix resumiu sua jornada com o GraphQL em 2020 em uma série de duas publicações no blog, cuja leitura é indispensável para qualquer profissional que trabalhe com GraphQL. O estudo de caso apresentado foi o sistema Studio Edge, que consistiu em reformular a arquitetura das APIs do estúdio para usar GraphQL. A API Studio da Netflix é usada pelas equipes de conteúdo para gerenciar e monitorar a produção, a pós-produção e a distribuição de séries e filmes. A API fornece acesso a uma enorme quantidade de dados, incluindo metadados sobre títulos, informações sobre talentos e muito mais.
Inicialmente, a API do Studio foi desenvolvida usando uma arquitetura RESTful tradicional, com endpoints que retornavam dados no formato JSON. No entanto, à medida que a API crescia e o número de clientes que a acessavam aumentava, ficou claro que era necessária uma solução mais eficiente.
A Netflix começou a explorar o GraphQL como uma possível solução para a API do Studio. A empresa começou criando um grafo selecionado para a API do Studio. Foram identificados vários benefícios importantes, como a possibilidade de reduzir o uso da rede, simplificar o acesso aos dados e melhorar o desempenho, permitindo que os clientes solicitem apenas os dados de que precisam.
A Netflix também enfrentou alguns desafios específicos ao adotar o GraphQL para a Studio API, principalmente no gerenciamento da complexidade do esquema e na garantia de que os clientes só pudessem acessar os dados que estavam autorizados a visualizar.
Para enfrentar esses desafios, a Netflix desenvolveu uma solução personalizada chamada "Netflix GraphQL Federation", que usa a especificação Apollo Federation para dividir o esquema da API do Studio em partes menores e mais fáceis de gerenciar. A empresa também implementou um sistema de gerenciamento de permissões e controle de acesso, que permite restringir o acesso dos clientes a determinadas partes do esquema.
No blog, eles também publicaram a evolução da arquitetura de sua API, de um monólito para um gateway federado. A Figura 5 é uma adaptação da imagem publicada no blog.
Acreditamos que há outra abordagem que ainda não foi contemplada e que pode ser predominante no setor, embora não tenha sido formalizada.
É possível combinar a camada agregada de gateways e o gateway federado da Figura 5, conforme mostrado abaixo:
Cada ícone de engrenagem representa, essencialmente, uma instância efêmera e federada do GraphQL (também conhecida como ator de gateway), que pode ser instanciada em tempo real (até mesmo a cada transação) na borda, ou seja, topologicamente próxima aos clientes, e se conectar aos microsserviços por meio de um transporte de API seguro. Em essência, essa combinação substitui a camada de agregação de gateway, ou a camada federada, por atores de gateway distribuídos que reúnem o melhor das duas funcionalidades. Chamamos isso de arquitetura de atores de gateway GraphQL distribuídos conforme mostrado na Figura 7.
OUTROS PRIMEIROS ADOTANTES
PayPal
O PayPal está em sua jornada com o GraphQL desde 2018 quando passou a usá-lo em seu aplicativo de checkout. Sua principal preocupação com o REST, semelhante à da Meta, era que os princípios de design não eram otimizados para aplicativos web e móveis nem para seus usuários. Os aplicativos clientes faziam muitas solicitações de ida e volta entre o cliente e o servidor, levando aproximadamente 700 ms para buscar os dados. Isso resultava em uma renderização mais lenta, frustração dos usuários e taxas de conversão mais baixas. No aplicativo de checkout, o PayPal descobriu que os desenvolvedores de interface do usuário (UI) passavam menos de um terço do tempo criando a interface, enquanto o restante era dedicado a descobrir como buscar e processar os dados.
As outras tecnologias consideradas pela equipe de engenharia do PayPal foram APIs de orquestração e Bulk REST. A criação de uma API de orquestração levaria à busca excessiva de dados e ao acoplamento dos clientes ao servidor. O PayPal concluiu que, com o tempo, essa abordagem pode tornar a API pesada, improvisada e destinada a mais de uma finalidade. O experimento com Bulk REST também não foi bem-sucedido. Embora tenha livrado a equipe de engenharia da necessidade de ajustar as APIs de orquestração, ele exigia que os clientes conhecessem profundamente o funcionamento das APIs.
A primeira experiência do PayPal com o uso do GraphQL para desenvolver um novo produto foi um SDK para dispositivos móveis destinado à integração do PayPal Checkout em aplicativos. Após uma semana avaliando o GraphQL, a equipe de engenharia decidiu usá-lo no novo produto. Embora a API ainda não estivesse pronta, a equipe conseguiu concluir o produto antes do prazo, praticamente sem precisar de conhecimentos específicos sobre o PayPal. Os desenvolvedores conseguiram criar rapidamente um aplicativo eficiente e fácil de usar, o que convenceu a equipe de engenharia a adotar plenamente o GraphQL em sua stack de tecnologia.
Starbucks
A Starbucks contratou uma empresa terceirizada para desenvolver seu Progressive Web App (PWA).
A equipe recebeu a tarefa de criar um sistema de pedidos capaz de lidar com lógicas de negócios complexas de forma eficiente e eficaz. Como os clientes podem personalizar seus pedidos, a equipe de desenvolvimento precisou garantir que o sistema pudesse comportar diversas instâncias de lógicas de negócios específicas, enviando os dados certos para o lugar certo no momento certo.
O GraphQL permitiu que a equipe criasse uma API eficiente, com cache e renderização no lado do servidor, para aprimorar a funcionalidade offline. A equipe também usou React para incorporar animações, criando uma experiência de usuário dinâmica e envolvente.
GraphQL na F5
O objetivo do Escritório do CTO da F5 era entender como poderíamos usar o GraphQL no ecossistema da F5. Temos dois projetos em andamento que exploram o uso do GraphQL.
APRIMORANDO MODELOS DE DADOS E VISIBILIDADE
O conjunto de ferramentas de gerenciamento de testes (TMS) oferecido pela F5 permite que os clientes testem endpoints ou clientes de seus próprios sistemas e verifiquem se são humanos ou bots.
Este foi um projeto de uso interno criado para otimizar o desenvolvimento e os testes do software TMS. O principal objetivo era extrair os dados JSON armazenados no banco de dados SQL existente, convertê-los em dados de grafo e implementar uma API GraphQL para consultas.
Isso foi necessário porque o banco de dados atual apresenta desafios, incluindo o "problema dos blobs JSON", decorrente do armazenamento de metadados como objetos JSON em um banco de dados tabular. A análise e o processamento desses objetos são inerentemente dispendiosos e ineficientes. Além disso, devido à sua natureza de grafo, os blobs JSON contêm dados valiosos que podem aprimorar ainda mais os produtos e a segurança da F5. Com a migração para um banco de dados de grafos direcionados, os blobs JSON podem ser analisados e gerenciados de forma eficiente por meio de relações direcionadas, otimizando a transferência e a utilização dos dados.
Os resultados são animadores. Ao identificar quais tabelas do banco de dados relacional do TMS contêm blobs JSON, concluímos que a migração para um GraphDB e o uso do GraphQL poderiam ampliar significativamente nossa visibilidade do sistema.
A Figura 9 mostra as possíveis evoluções ou opções de implementação para este projeto. Cada opção tem suas próprias implicações.
A opção 1 tem o menor impacto na interface do usuário, pois o cliente não precisa ser alterado. Um modo híbrido, como nas opções 1 ou 2, pode funcionar bem dependendo da situação, especialmente se houver um número menor de colunas com objetos JSON. Além disso, o esquema derivado de cada JSON também seria pequeno.
Mas, durante o planejamento, percebemos que os objetos JSON precisavam de um contexto que estava armazenado em outras colunas do banco de dados SQL. O esquema armazenado em cada objeto JSON também era bastante grande. Isso aumentaria o trabalho de manutenção da base de código. Portanto, após uma análise cuidadosa, decidimos reformular a arquitetura da aplicação para oferecer suporte a GraphQL e Neo4J, conforme mostrado na opção 3.
INTEGRAÇÃO COM O CLOUDGRAPH
O CloudGraph é uma API GraphQL universal, gratuita e de código aberto, e uma ferramenta de Gerenciamento da Postura de Segurança na Nuvem (CSPM) para AWS, Azure, GCP e Kubernetes (K8s). O objetivo do projeto é usar o CloudGraph para criar um “plugin do CloudGraph” (Figura 10) que exiba os dados do F5 Distributed Cloud (F5XC), proporcionando maior visibilidade dos recursos de nuvem conectados por meio do F5 Distributed Cloud.
Nosso objetivo é realizar a integração com o CloudGraph para obter uma compreensão aprofundada da tecnologia e desenvolver futuras integrações com o CloudGraph, insights e APIs GraphQL para dados do F5XC.
Após integrar o provedor F5XC personalizado à plataforma CloudGraph e usar o recurso de criação de relacionamentos da plataforma, teremos maior visibilidade dos recursos de nuvem conectados por meio do F5XC e de seus relacionamentos com outras nuvens. Poderemos então gerar consultas complexas sobre recursos em várias nuvens para o mesmo tenant. Isso nos permitirá oferecer às partes interessadas uma visão abrangente do F5XC e explorar uma integração mais profunda do CloudGraph para incluir plugins adicionais do GraphQL e insights personalizados sobre operações em nuvem relevantes para a F5 e seus clientes.
Com base nas iniciativas acima, nossa exploração inicial está alinhada às experiências descritas nos estudos de caso apresentados anteriormente.
Preocupações de segurança do GraphQL
As percepções iniciais sobre a superioridade do GraphQL em relação ao REST em termos de segurança foram desmentidas, pois o GraphQL, como qualquer outra tecnologia, apresenta seus próprios riscos se não for implementado corretamente. É importante reconhecer que o GraphQL não é inerentemente mais seguro do que outras tecnologias. Uma implementação adequada e a adoção das melhores práticas são fundamentais para garantir a segurança das APIs GraphQL. Ao desfazer esse mito, podemos abordar o GraphQL com uma compreensão realista de suas questões de segurança e tomar as medidas apropriadas para mitigar possíveis riscos.
ATAQUE DE INTROSPECÇÃO
O GraphQL oferece aos desenvolvedores uma ferramenta poderosa chamada introspecção, que permite solicitar informações sobre o esquema usado por um serviço GraphQL. Essa ferramenta possibilita que os desenvolvedores conheçam melhor o serviço e sua estrutura. No entanto, há riscos associados à introspecção. Habilitar a introspecção em um serviço GraphQL em produção significa que informações confidenciais contidas no esquema também podem ser acessadas. Isso representa um risco significativo, pois usuários mal-intencionados podem explorar a introspecção para obter dados confidenciais e potencialmente causar danos. Além disso, a introspecção permite que esses usuários identifiquem facilmente operações potencialmente prejudiciais, pois podem visualizar todo o esquema e determinar quais consultas executar. As consequências desse tipo de vazamento podem ser desastrosas, dependendo da natureza do esquema e dos dados nele contidos.
Mitigação: Uma solução para mitigar os riscos da introspecção é desativá-la em APIs de produção usando diversos frameworks. Ao desativar a introspecção, os desenvolvedores perdem algumas das funcionalidades convenientes que ela oferece. No entanto, para recuperar essa praticidade, eles podem registrar o esquema GraphQL da API de produção em ferramentas como o GraphOS. Isso permite manter o acesso controlado ao esquema e às suas informações.
INJEÇÃO DE SQL
A injeção de SQL é um ataque amplamente conhecido e comum, que apresenta riscos que vão desde a manipulação de dados até a exclusão completa do banco de dados. Esse ataque simples explora a concatenação de strings, permitindo que um invasor insira código executável nos dados de entrada, obtenha acesso não autorizado ao banco de dados e realize alterações maliciosas. Curiosamente, esse vetor de ataque não se limita apenas a bancos de dados SQL, podendo também afetar bancos de dados de grafos, como o Neo4j. O Neo4j utiliza a linguagem de consulta Cypher, que se assemelha ao SQL e herda suas vulnerabilidades. Esse tipo de ataque, conhecido como injeção de Cypher, explora essas semelhanças, mas também se beneficia das soluções existentes, sem a necessidade de criar novas abordagens.
Mitigação: As contramedidas incluem a sanitização das entradas do usuário para detectar e impedir a exploração, além do uso de parametrização para desvincular essas entradas da criação direta de consultas. Essas medidas reduzem efetivamente o risco de ataques de injeção. É fundamental abordar esse problema de segurança nas implementações de GraphQL, mas, felizmente, existem soluções conhecidas e fáceis de implementar.
ATAQUE À API DE PROXY REST
Sobrepor uma API GraphQL a uma API REST pode gerar vulnerabilidades de falsificação de solicitação do lado do servidor (SSRF). Os invasores podem explorá-las modificando os parâmetros enviados à API REST por meio do proxy GraphQL. Se nenhuma das APIs validar os parâmetros de chamadas específicas, os invasores poderão assumir o controle do sistema de back-end. Por exemplo, acrescentar "/delete" a um ID de usuário em uma consulta GraphQL pode resultar na exclusão não intencional de dados quando o valor for repassado à API REST.
Mitigação: Embora essa vulnerabilidade seja uma preocupação válida, ela pode ser solucionada de forma eficaz definindo tipos no esquema GraphQL e validando rigorosamente os parâmetros antes de enviá-los a APIs ou serviços externos. É importante observar que essa vulnerabilidade, assim como outras associadas ao GraphQL, decorre de problemas de implementação, e não de problemas inerentes ao próprio GraphQL. Esses problemas surgem quando o GraphQL é usado de forma inadequada devido a uma mentalidade de curto prazo, apesar do grande potencial da tecnologia.
ATAQUES EM LOTE
Vulnerabilidades de autenticação são um vetor de ataque comum em diversos sistemas, incluindo o GraphQL. A capacidade do GraphQL de enviar várias consultas ou mutações em uma única solicitação o torna suscetível a ataques em lote, que envolvem métodos de força bruta.
O primeiro tipo de ataque envolve o uso de força bruta para descobrir senhas de login. Os invasores enviam uma solicitação com diversas mutações contendo pares de credenciais de login. Como o GraphQL permite várias mutações em uma única solicitação, esse ataque contorna as verificações de limitação de taxa e possibilita a criação de uma sessão por meio de força bruta de senhas.
O segundo tipo de ataque funciona de forma semelhante, mas tem como alvo uma forma popular de autenticação de dois fatores (2FA) chamada senha de uso único (OTP). Uma única solicitação é enviada com várias mutações, cada uma contendo uma credencial de login válida combinada com uma variação diferente de OTP. Se alguma das mutações incluir a OTP correta, a solicitação será autenticada e uma sessão será estabelecida.
Mitigação: A correção dessas vulnerabilidades exige uma abordagem abrangente, pois não existe uma solução infalível. Os desenvolvedores desempenham um papel fundamental ao adotar práticas de codificação segura e priorizar a perspectiva da lógica de negócios. No servidor web, é essencial implementar medidas como limitar as tentativas de login e validar as entradas do usuário. Além disso, deve-se dar atenção especial à análise de solicitações que contenham várias mutações, pois uma tentativa legítima de login normalmente não envolve mais de uma mutação.
ATAQUE DE NEGAÇÃO DE SERVIÇO
Esses ataques consistem em sobrecarregar o serviço GraphQL com tráfego excessivo, tornando-o incapaz de processar solicitações de usuários legítimos e podendo causar falhas no servidor. Os ataques de DoS podem ser realizados por meio de consultas GraphQL recursivas ou do envio de solicitações de consulta muito grandes.
No cenário de consultas recursivas, os invasores exploram a natureza cíclica das definições de esquema do GraphQL. Por exemplo, se o esquema incluir os tipos autor e livro, um invasor poderá consultar repetidamente o autor e o livro em um loop, sobrecarregando o servidor com chamadas recursivas e interrompendo seu funcionamento.
Como alternativa, os invasores podem enviar consultas que solicitam uma grande quantidade de dados do banco de dados. Por exemplo, uma consulta pode recuperar muitos autores e todos os livros associados a eles. Uma solicitação de dados tão grande pode deixar o sistema significativamente mais lento ou causar uma falha nele.
Mitigação: Há várias soluções para mitigar esse problema. A primeira abordagem é definir um tempo limite para as consultas, impedindo que os usuários façam solicitações que excedam uma duração especificada. No entanto, isso pode não resolver totalmente o problema, pois ainda podem ocorrer danos dentro do tempo estipulado. Outra solução é impor limites à profundidade e à complexidade das consultas. As consultas que ultrapassarem a profundidade ou a complexidade definidas, desviando-se da definição do esquema, poderão ser rejeitadas. Por fim, limitar a frequência de solicitações dos usuários pode ser eficaz. Se um usuário enviar um conjunto grande ou contínuo de solicitações, seu acesso ao servidor poderá ser temporariamente negado até que o servidor esteja pronto para processar solicitações adicionais.
Padrões de implantação do GraphQL
Há vários padrões de implantação para GraphQL, conforme mostrado, cada um com seu próprio conjunto de vantagens, desvantagens e aspectos a considerar. Alguns dos padrões mais comuns incluem:
IMPLANTAÇÃO MONOLÍTICA
Esse é o padrão mais simples e comum para implantar uma API GraphQL. Em uma implantação monolítica, o servidor GraphQL, o banco de dados e quaisquer outros serviços necessários são implantados juntos como uma única unidade. Isso pode facilitar os primeiros passos com o GraphQL, mas pode dificultar o dimensionamento e a manutenção à medida que a aplicação cresce.
MONÓLITOS COMPOSTOS
Monólitos compostos referem-se à arquitetura em que uma aplicação monolítica é construída usando uma combinação de monólitos e microsserviços, com o GraphQL atuando como a camada de API (Figura 12). Nesse padrão, em vez de dividir todo o sistema em microsserviços separados, a aplicação é inicialmente desenvolvida como monólitos separados, que encapsulam toda a lógica de negócios e as camadas de acesso a dados.
Dentro dessa estrutura monolítica, o GraphQL é implementado como a camada de API, permitindo que os clientes solicitem e recuperem dados de diferentes microsserviços subjacentes. Isso significa que, embora a aplicação permaneça monolítica do ponto de vista da implantação, ela utiliza o GraphQL para compor dados de vários serviços e apresentá-los aos clientes de maneira flexível e eficiente.
Esse padrão oferece benefícios como a simplificação do desenvolvimento e da implantação, além da possibilidade de aproveitar os poderosos recursos de consulta e obtenção de dados do GraphQL. Ele permite que os desenvolvedores adotem gradualmente uma arquitetura de microsserviços, sem abrir mão da flexibilidade e da facilidade de uso proporcionadas pelo GraphQL.
SUBGRAFOS FEDERADOS
Os grafos federados nos padrões de implantação do GraphQL combinam vários serviços GraphQL, chamados de subgrafos, em um único esquema GraphQL unificado. Cada subgrafo representa um domínio ou microsserviço independente, com seus próprios dados e funcionalidades. Essa arquitetura utiliza um gateway central que encaminha as consultas dos clientes ao subgrafo apropriado com base nos campos solicitados. Ao federar esses subgrafos, os desenvolvedores podem criar um grafo coeso, no qual os clientes podem consultar e navegar entre diferentes serviços de forma transparente.
Essa abordagem promove a modularidade, a escalabilidade e o desenvolvimento independente de serviços, resultando em melhor desempenho e flexibilidade na criação de APIs GraphQL. Os subgrafos federados (Figura 13) oferecem uma maneira eficiente de compor dados de vários serviços e criar uma arquitetura distribuída e escalável.
GRAFOS HÍBRIDOS
Os grafos híbridos (Figura 14) nos padrões de implantação do GraphQL combinam subgrafos federados e esquemas não federados por meio de técnicas de stitching. Essa abordagem permite que as organizações integrem APIs GraphQL existentes ou sistemas legados a microsserviços federados, resultando em uma API GraphQL unificada que aproveita os benefícios de ambas as abordagens. Ao mesclar esquemas e resolver relações entre tipos e campos, a arquitetura de grafo híbrido oferece flexibilidade, modularidade e escalabilidade.
O padrão de grafo híbrido permite que as organizações adotem gradualmente a federação enquanto aproveitam seus recursos existentes. Ele possibilita a integração perfeita de subgrafos federados e esquemas não federados, atendendo a diversos requisitos e promovendo a interoperabilidade. Essa abordagem permite que as organizações criem APIs GraphQL abrangentes, capazes de escalar e se adaptar à evolução das necessidades. Ao combinar os pontos fortes dos serviços federados e não federados, os grafos híbridos oferecem uma solução flexível e poderosa para criar implantações GraphQL.
Os desafios relacionados a grafos híbridos em implantações de GraphQL incluem gerenciar a complexidade dos esquemas mesclados, lidar com possíveis impactos no desempenho, garantir a consistência e a integridade dos dados, administrar a evolução e o versionamento do sistema e enfrentar as complexidades do monitoramento e da depuração em uma arquitetura distribuída. Para superar esses desafios e garantir o bom funcionamento das implantações de grafos híbridos, é necessário um planejamento cuidadoso, otimização e práticas robustas de desenvolvimento.
ROTEAMENTO SEM SERVIDOR
Esse padrão envolve a implantação da API GraphQL como um conjunto de funções sem servidor, como o AWS Lambda ou o Google Cloud Functions. Essa pode ser uma maneira econômica e escalável de implantar uma API GraphQL, mas também pode gerar latência adicional e aumentar a complexidade da arquitetura.
Há muitos desafios no roteamento sem servidor. Um deles é conectar perfeitamente subgrafos distribuídos à medida que a aplicação cresce. A coordenação de várias equipes e implantações pode se tornar complexa, dificultando o gerenciamento e o dimensionamento eficaz dos subgrafos. Garantir a consistência e a sincronização dos dados entre esses subgrafos é outro obstáculo. O monitoramento e a depuração em um ambiente distribuído sem servidor podem ser mais difíceis, exigindo mecanismos adequados de registro e tratamento de erros. Além disso, o gerenciamento do controle de acesso e da autorização em várias funções sem servidor e subgrafos apresenta desafios. Superar esses desafios é essencial para o bom funcionamento e a escalabilidade de uma implantação do GraphQL baseada em uma arquitetura sem servidor.
IMPLANTAÇÃO NA BORDA
Em um padrão de implantação na borda para APIs GraphQL, a API é posicionada mais perto dos clientes por meio de um serviço de CDN. Isso oferece vários benefícios, incluindo menor latência para respostas mais rápidas, redução da carga no servidor de origem e proteção contra ataques DDoS.
Ao distribuir a infraestrutura da API entre servidores de borda em todo o mundo, é possível processar o tráfego com mais eficiência e proporcionar uma melhor experiência aos usuários em escala global. Os recursos de cache e filtragem da CDN ajudam a melhorar a escalabilidade e a garantir a disponibilidade da API, mesmo diante de tráfego intenso ou ataques maliciosos. As implantações na borda têm o potencial de otimizar o desempenho e a confiabilidade de uma API ao aproveitar a rede de servidores das CDNs.
Conclusão
As tecnologias GraphQL amadureceram o suficiente para serem adotadas por empresas tradicionais. Embora o Hype Cycle da Gartner para APIs de 2022 indique que ainda estamos a vários anos de uma adoção generalizada, chegamos a um ponto de inflexão crucial, no qual as ferramentas necessárias já estão disponíveis. Embora o GraphQL ainda seja relativamente novo, ele evoluiu a ponto de atender às necessidades de grandes empresas consolidadas.
A maturidade das tecnologias GraphAPI está relacionada ao número crescente de empresas que adotam o GraphQL e outras tecnologias de bancos de dados em grafo. À medida que mais empresas adotam essas tecnologias, as ferramentas e os recursos necessários para oferecer suporte a elas tornam-se cada vez mais disponíveis, facilitando a adesão de outras empresas. Além disso, os benefícios das tecnologias GraphAPI — como consultas de dados mais eficientes e menor complexidade — estão sendo cada vez mais reconhecidos, impulsionando ainda mais sua adoção no meio empresarial.
Como setor, precisamos reconhecer a importância de tecnologias GraphAPI, como o GraphQL, e seu potencial para superar as limitações do REST. As empresas não podem ignorar a necessidade urgente de investir no GraphQL e compreendê-lo, especialmente no que diz respeito à modelagem, à diversidade e à opacidade dos dados. Embora seja fácil se encantar com os recursos e o potencial do GraphQL, também precisamos reconhecer a possível fase de desilusão após o pico de expectativas infladas. Os fornecedores devem priorizar o aprimoramento de seus produtos para oferecer suporte completo ao GraphQL, enquanto as áreas de TI das empresas — incluindo os fornecedores — devem identificar quais dados se beneficiariam da exposição por meio do GraphQL para aumentar a produtividade.
Os clientes devem priorizar a compreensão de seus dados e reconhecer que uma empresa comum opera de maneira diferente dos hyperscalers que originalmente introduziram o GraphQL. Vamos trabalhar juntos para adotar o GraphQL como um padrão eficaz de arquitetura de software e impulsionar o setor rumo a mais produtividade e inovação.