Phil Sturgeon postou recentemente um
tweet que atingiu muito os fãs do GraphQL. Este tweet falou sobre como o GraphQL é, por definição, uma tecnologia que contradiz a essência do HTTP / 2. O fato de o padrão HTTP / 3 já ter sido divulgado e de o autor do tweet não entender realmente quem, escolhendo o GraphQL, segue o caminho da incompatibilidade. Para entender melhor as razões da atitude de Phil em relação ao GraphQL, dê uma olhada
neste material.
Na mesma época, foi feito um anúncio sobre o projeto
Vulcain . Esta mensagem incluía as palavras: "TL / DR: GraphQL você não precisa mais!". E, finalmente, um ótimo
artigo de Mark Nottingham foi publicado sobre os poderosos recursos do HTTP / 2 e o que esses recursos significam para quem cria a API. Darrel Miller
compartilhou um link para este artigo com seus assinantes.
O que estava acontecendo me fez pensar sobre GraphQL e HTTP / 2. Se tudo começar a funcionar usando HTTP / 2 (e HTTP / 3), isso significa que não temos motivos para usar o GraphQL? Eu gostaria de descobrir hoje.
Inovações HTTP / 2
Para começar, vamos descobrir o que na tecnologia HTTP / 2 pode afetar o valor do GraphQL aos olhos dos desenvolvedores. O HTTP / 2 tem muito a oferecer. Este é, por exemplo, um novo formato binário e compactação de cabeçalho aprimorada. Mas, no nosso caso, o papel principal é desempenhado pela forma como a entrega de solicitações e respostas é processada ao usar o HTTP / 2.
Abrir uma conexão TCP é uma operação cara. Clientes que usam HTTP / 1 tendem a não executá-lo com muita frequência. Por esse motivo, devido à grande carga adicional no sistema, os desenvolvedores frequentemente tentavam limitar o número de solicitações recorrendo a uma variedade de tecnologias. Por exemplo, executando consultas em lote, usando linguagens de consulta, incorporando código CSS / JS no código da página, usando folhas de sprite em vez de imagens individuais e assim por diante. No HTTP / 1.1. foi feita uma tentativa de resolver alguns desses problemas usando conexões persistentes e processamento de dados em
pipeline . Essas duas tecnologias permitiram que os navegadores enviassem, na mesma conexão, várias solicitações e recebessem respostas para elas. A desvantagem de um esquema de troca de dados era que ele estava sujeito ao problema de bloquear o início da fila (bloqueio de
chefe de linha ). Esse problema é expresso no fato de que uma solicitação lenta pode retardar o processamento de todas as solicitações seguintes. Os especialistas que trabalharam no HTTP / 2 sugeriram maneiras diferentes de resolver esse problema. Juntamente com o novo protocolo binário, o HTTP / 2 apresenta uma nova estratégia de entrega de dados. Durante a interação de sistemas usando o protocolo HTTP / 2, uma única conexão é aberta, dentro da estrutura na qual a multiplexação de solicitações e respostas é realizada usando um novo nível binário projetado para trabalhar com quadros, quando cada quadro faz parte de um fluxo. Usando esse mecanismo, clientes e servidores podem recriar fluxos de solicitação e resposta com base nas informações sobre eles que estão nos quadros. Isso permite que o HTTP / 2
dê suporte muito
eficaz ao processamento de muitos pedidos executados em uma única conexão.
Mas isso não é tudo. O HTTP / 2 tem um novo conceito chamado Server Push. Se você não entrar em detalhes, podemos dizer que essa tecnologia permite que os servidores enviem dados aos clientes com antecedência, fazendo isso antes que os clientes solicitem esses dados. Os exemplos mais impressionantes desse comportamento são o envio antecipado de folhas de estilo e recursos JavaScript aos clientes. No processo de gerar uma resposta à solicitação HTTP, o servidor pode descobrir que algum arquivo CSS é necessário para renderizar a página HTML e descobrir com antecedência que o cliente entrará em contato com ele em breve para esse arquivo. Isso permite que o servidor envie o arquivo fornecido ao cliente antes mesmo de solicitá-lo. É assim que o projeto
Vulcain mencionado acima funciona, usando essa tecnologia para organizar o carregamento eficiente dos recursos relacionados.
Então, enquanto tudo está claro. Mas o que tudo isso tem a ver com o GraphQL?
GraphQL: uma consulta que resolve todos os problemas
A tecnologia GraphQL se deve em parte à sua atratividade, pois ajuda os desenvolvedores a lidar com as desvantagens típicas das conexões HTTP / 1.
É por isso que o GraphQL permite que os clientes, em uma sessão se comuniquem com o servidor, atendam às solicitações para receber quase tudo. Isso pode ser contrastado com a API Hypermedia, ao usar as quais você geralmente precisa executar muitas solicitações de rede (às vezes, no entanto, o
cache pode melhorar a situação).
A capacidade de receber vários recursos em uma única consulta é um dos pontos fortes do GraphQL , para o qual os criadores dessa tecnologia atraem a atenção de seus usuários em potencial.Muitos dos que dizem que ninguém precisa da tecnologia GraphQL com o advento do HTTP / 2 significam essa possibilidade. Usando APIs em lote, linguagens de consulta (como GraphQL), otimizando relacionamentos e até criando pontos finais agregados, agora parece menos atraente do que antes. O problema é que o "custo" da realização de consultas se torna pequeno. E isso é verdade. Mas é apenas por isso que usamos o GraphQL? Eu acho que não.
Talvez o fato seja que agora ainda são os primeiros dias dos clientes HTTP / 2 e alguns aplicativos de servidor?
Eu não acho que a pergunta colocada no título desta seção sirva como uma explicação válida para o fato de ainda estarmos amplamente usando o GraphQL. Mas vale a pena mencionar. O uso do HTTP / 2 no nível do aplicativo em alguns ecossistemas é um desafio que está longe de ser resolvido. Procure, por exemplo, as palavras "Rack / Rails over HTTP / 2." Vai ser interessante. O fato é que muitas partes de aplicativos do servidor são construídas usando o padrão de solicitação / resposta. Como resultado, mudar para o conceito de fluxos HTTP / 2 não é tão simples. Especialmente - no caso de alguns quadros. Mas essa é uma desculpa indigna, muitos ecossistemas apóiam perfeitamente esse esquema de interação entre clientes e servidores e, em teoria, ainda devemos nos esforçar para melhorar essa interação. (A maioria dos proxies também suporta isso, mas não é fácil organizar algo como enviar dados a um cliente por iniciativa do servidor, se o aplicativo do servidor estiver bloqueado no passado usando um padrão de solicitação / resposta).
O GraphQL é mais do que reduzir o tempo de recebimento e transmissão de dados ou otimizar a quantidade de informações transmitidas
Embora reduzir o tempo de recebimento e transmissão de dados e otimizar a quantidade de informações transmitidas sejam os pontos fortes do GraphQL sobre os quais ouvimos constantemente, essa tecnologia nos oferece muito mais.
O poder da tecnologia GraphQL reside em seu foco nos sistemas clientes. O cliente é o ambiente no qual o GraphQL faz muitos compromissos. Nos últimos anos, isso incomodou muitos. Portanto, Daniel Jacobson escreveu muitos bons artigos sobre alguns desses problemas há 5 a 7 anos.
Aqui e
ali - algumas de suas publicações. Ele diz em uma delas: "Nossas APIs REST, embora sejam capazes de lidar com solicitações gerais, não são otimizadas para nenhuma dessas solicitações".
Observe que essa ideia é válida não apenas quando aplicada à tecnologia REST. Os aplicativos clientes geralmente precisam executar mais solicitações de servidor do que seus desenvolvedores gostariam. Esses aplicativos precisam lidar com o recebimento de dados desnecessários dos servidores. Isso é mais sobre como projetar APIs que seria bom criar, para que elas suportem muitos usos diferentes. A maneira usual de resolver esse problema é manter a lógica do cliente o mais próxima possível da lógica do servidor. Um exemplo dessa abordagem são os adaptadores de cliente Netflix mencionados
neste artigo de 2012. Desde então, algumas equipes da Netflix
mudaram para o GraphQL. O padrão
BFF também visa solucionar esses problemas.
A tecnologia GraphQL está mudando o conceito de limite entre o cliente e o servidor, ajudando-nos a criar sistemas de servidores que podem incluir informações sobre como eles serão usados pelos clientes. Isso se manifesta claramente ao usar a tecnologia de solicitações
constantes , pois aqui estamos falando, em essência, sobre os recursos do servidor gerados por iniciativa do cliente.
Ao pensar sobre a relevância do GraphQL no mundo HTTP / 2, lembre-se de que estamos falando sobre abstração de servidor. O suporte a vários casos de uso de dados do servidor pode levar a problemas nas APIs tradicionais baseadas em terminal. O GraphQL permite que aqueles que suportam a API se concentrem em fornecer aos usuários dessas APIs uma ampla variedade de recursos. Ao mesmo tempo, os proprietários da API podem não se preocupar com a crescente carga nos clientes existentes e que o suporte à API se tornará muito mais complicado devido à necessidade de oferecer suporte a muitos recursos diferentes. (O suporte a muitos recursos diferentes tem suas desvantagens. Portanto, esses esquemas complicam a otimização do desempenho. Esses recursos nem sempre são bem armazenados em cache. As APIs que podem ser fortemente ajustadas enfrentam os mesmos problemas).
Sistemas Cliente e Desenvolvimento GraphQL
Neste artigo, falo principalmente sobre servidores, mas é importante lembrar que os desenvolvedores de clientes gostam muito da tecnologia GraphQL. Se você combinar fragmentos do GraphQL com a abordagem de componente das estruturas modernas de front-end, obterá uma abstração completamente surpreendente. E, novamente, se adicionarmos consultas constantes aqui, podemos dizer que o GraphQL facilita a vida dos desenvolvedores de sistemas clientes.
GraphQL é um sistema holístico com características notáveis
O GraphQL não é algo que possui recursos completamente exclusivos. Existem alternativas para esse sistema. Esquema digitado? O mesmo acontece com o OpenAPI! Abstrações de servidor que suportam diferentes casos de uso de cliente? Isso pode ser implementado de várias maneiras. Introspecção? O uso do Hypermedia permite aos clientes descobrir ações e começar a trabalhar com a entidade raiz. Uma deliciosa ferramenta GraphiQL? Tenho certeza de que algo semelhante foi criado para o OpenAPI. As possibilidades do GraphQL sempre podem ser recriadas usando outras tecnologias. No entanto, o GraphQL é um sistema holístico. É isso que atrai um público tão grande de desenvolvedores para o GraphQL, que estão felizes em usar este sistema. Suspeito que essa seja uma das razões para a rápida disseminação e desenvolvimento do GraphQL. Além disso, como a construção da API do GraphQL está bem documentada, as bibliotecas do GraphQL projetadas para várias linguagens geralmente são de alta qualidade e popularidade.
A rede ainda é um fator limitante (ou talvez sempre seja assim?)
Aqui está outro pensamento que eu quero pensar. Há uma sensação de que a rede, quando se trata de trabalhar com a API, sempre desempenhará o papel de algum fator limitante. Não importa a rapidez com que as solicitações de rede são. É por isso que não projetamos APIs da web da mesma maneira que objetos comuns usados em diferentes linguagens de programação.
Aqui , por exemplo, estamos falando sobre por que interfaces com alto nível de detalhes não são muito adequadas para criar sistemas projetados para trabalho remoto com eles.
Embora o HTTP / 2 definitivamente incentive a execução de solicitações com alta granularidade, acho que há algumas compensações a serem feitas aqui.
O HTTP / 2 pode ajudar o GraphQL?
Portanto, o GraphQL oferece ao desenvolvedor muitas ferramentas importantes e úteis, mas o HTTP / 2 também é uma ótima tecnologia. Vamos olhar para o futuro e pensar nos benefícios que os sistemas GraphQL podem se beneficiar usando HTTP / 2. Por exemplo, pode ser assim:
query { viewer { name posts(first: 100) @stream { title } } }
Acontece que podemos usar bem a abstração do GraphQL do lado do servidor, a linguagem de consulta declarativa dessa tecnologia, e ao mesmo tempo usar os recursos dos fluxos HTTP / 2. Eu acho que os soquetes da web são usados aqui. Ainda preciso descobrir isso, mas tenho certeza de que muitos já estão explorando as diretrizes do GraphQL, como
@defer ,
@stream e
@live .
Sumário
O HTTP / 2 é uma ótima tecnologia (e os exemplos dados
aqui são apenas algum tipo de milagre). O GraphQL só pode ser percebido como uma tecnologia que reduz o número de sessões de comunicação cliente-servidor ou ajuda a otimizar o volume de dados transmitidos. Nesse caso, qualquer pessoa que veja o GraphQL de uma perspectiva semelhante ficará muito feliz ao usar APIs baseadas nos recursos HTTP / 2. No entanto, se você vê no GraphQL uma combinação de tecnologias que oferecem muitas coisas úteis ao desenvolvedor, fica claro que o poder do GraphQL não se limita a melhorar o uso dos recursos de rede e economizar tráfego.
Caros leitores! Se você usa a tecnologia GraphQL, diga-nos o que não gosta mais nela.
