Um breve tour pelo GraphQL

Olá Habr!


O livro de Alex Banks e Eva Porsello, que entregamos à tradução alguns dias atrás, servirá como uma breve digressão na linguagem de consulta do GraphQL. O livro dos mesmos autores sobre React e Redux tornou-se um verdadeiro best-seller (estamos aguardando a quinta edição da gráfica). A propósito, graças a todos que nos apontaram imprecisões no código e nos termos;) fizemos o livro sobre a tecnologia tão rapidamente obsoleta, muito rapidamente.

O autor do artigo de hoje, Robin Viruch, também está trabalhando em um livro sobre GraphQL e bibliotecas para essa linguagem, e no artigo de hoje explica brevemente as vantagens e características do GraphQL como uma alternativa ao REST



Quando se trata de solicitações de rede entre aplicativos cliente e servidor, o REST é mais frequentemente escolhido como uma ponte entre os mundos cliente e servidor. No REST, tudo se desenvolve em torno da ideia de "precisamos de recursos acessíveis por URL". Você pode ler um recurso usando uma HTTP GET , criar um recurso usando uma solicitação HTTP POST e atualizá-lo e excluí-lo usando solicitações HTTP PUT e DELETE . Essas operações são chamadas de CRUD (Criar, Ler, Atualizar, Excluir). O recurso pode ser qualquer conteúdo recebido de autores, usuários ou retirado de artigos. Ao usar o REST, o formato de transferência de dados não é codificado, mas geralmente o JSON é usado para essa finalidade. No final, o REST permite a comunicação entre aplicativos pelo protocolo HTTP normal usando URLs e métodos HTTP.

 //    REST GET https://api.domain.com/authors/7 //   JSON { "id": "7", "name": "Robin Wieruch", "avatarUrl": "https://domain.com/authors/7", "firstName": "Robin", "lastName": "Wieruch" } 

Embora o REST tenha permanecido um padrão de fato por um bom tempo, nos últimos anos outra tecnologia desenvolvida pelo Facebook ganhou popularidade: é chamada GraphQL. Este artigo, uma introdução ao GraphQL, fala sobre os prós e contras dessa linguagem de consulta.

O que é o GraphQL?

Antes de mergulhar na discussão dos pontos fortes e fracos do GraphQL, vamos primeiro responder à seguinte pergunta: o que é o GraphQL? GraphQL é uma linguagem de consulta de freeware criada pelo Facebook em 2012. Mesmo antes de enviar o produto para código aberto, o idioma já era usado no Facebook como uma tecnologia interna para trabalhar com aplicativos móveis. Por que com aplicativos móveis? O GraphQL foi desenvolvido como uma alternativa à arquitetura REST típica. Ele permite que o cliente solicite apenas os dados desejados - nem mais nem menos. O cliente é responsável por tudo, ou seja, você. Nesse caso, surgem dificuldades na arquitetura REST, pois é a interface do banco de dados que determina quais informações estarão disponíveis para cada recurso em cada URL. A amostragem de dados não é solicitada na parte do cliente. Portanto, o frontend, em qualquer caso, deve solicitar todas as informações sobre o recurso, mesmo que precise apenas de uma parte desses dados. Esse problema é chamado de "re-amostragem". Na pior das hipóteses, o aplicativo cliente precisa ler não apenas um, mas muitos recursos, para acesso ao qual é necessário executar muitas solicitações de rede. Isso leva não apenas à nova amostragem, mas também a solicitações de avalanche na rede. No entanto, tendo uma linguagem de consulta como o GraphQL, usada não apenas no servidor, mas também no lado do cliente, o cliente decide quais dados ele precisa - e, para isso, envia apenas uma solicitação ao servidor. Quando o Facebook desenvolveu aplicativos móveis usando a linguagem GraphQL, foi possível reduzir drasticamente a carga da rede, pois muito menos dados começaram a ser transmitidos por ela.

O Facebook postou a especificação GraphQL e sua implementação de referência em JavaScript para acesso gratuito. Desde então, essa especificação foi implementada em muitas outras linguagens de programação importantes. Além disso, o ecossistema desenvolvido em torno do GraphQL cresce não apenas horizontalmente, espalhando-se para outras linguagens de programação, mas também verticalmente (as bibliotecas são construídas sobre o GraphQL, por exemplo, Apollo, Relay).

O GraphQL fornece os seguintes tipos de operações: solicitação (leitura), alteração (gravação) ou assinatura (leitura contínua). Qualquer uma dessas operações é apenas uma string que deve ser montada de acordo com a especificação da linguagem de consulta GraphQL. Quando uma operação do GraphQL chega ao aplicativo de banco de dados a partir do aplicativo cliente, ela pode ser interpretada em comparação com todo o esquema GraphQL localizado no back-end e resolvida para o aplicativo cliente usando os dados disponíveis. O GraphQL funciona igualmente bem com qualquer camada de rede (que geralmente é organizada por HTTP), bem como com qualquer formato de carga útil (geralmente JSON). Ele também não se preocupa completamente com a arquitetura do aplicativo (que na maioria dos casos consiste na parte do cliente e na interface do banco de dados). É apenas uma linguagem de consulta.

 //  GraphQL author(id: "7") { id name avatarUrl articles(limit: 2) { name urlSlug } } //   GraphQL { "data": { "author": { "id": "7", "name": "Robin Wieruch", "avatarUrl": "https://domain.com/authors/7", "articles": [ { "name": "The Road to learn React", "urlSlug": "the-road-to-learn-react" }, { "name": "React Testing Tutorial", "urlSlug": "react-testing-tutorial" } ] } } } 

Como você pode ver, a consulta já se aplica a muitos recursos (autor, artigo), chamados campos no GraphQL, e apenas um conjunto específico de campos aninhados para esses campos (nome, urlSlug para o artigo), embora outros dados possam ser fornecidos no próprio esquema de dados do GraphQL Informações (por exemplo, para um artigo - uma descrição, data de lançamento). Enquanto em uma arquitetura REST precisaríamos de pelo menos duas consultas em cascata para recuperar o autor e os artigos desse autor, o GraphQL resolve esse problema em uma consulta. Além disso, a consulta seleciona apenas os campos necessários, e não a entidade inteira.

Essa é a essência do GraphQL. No caso em que o aplicativo do servidor fornece o esquema GraphQL no qual define todos os dados disponíveis com sua hierarquia e tipos, o aplicativo cliente solicita apenas os dados necessários.

Benefícios do GraphQL

A seguir, são apresentados os principais benefícios do uso do GraphQL em um aplicativo.

Amostra de dados declarativa

Como você pode ver, o GraphQL usa amostragem de dados declarativa em suas consultas. O cliente seleciona os dados, suas entidades e todos os campos entre os quais existem vários relacionamentos e, para tudo isso, uma única solicitação é aplicada. O cliente decide quais campos são necessários para esta interface do usuário. Muitas vezes, você quase pode falar sobre amostragem de dados orientada à interface do usuário. Por exemplo, é assim que o Airbnb usa o GraphQL. Um mecanismo de pesquisa do Airbnb geralmente fornece resultados para residências, impressões e outras categorias específicas para uma determinada área de assunto. Para extrair todos os dados de uma só vez, uma consulta GraphQL é executada, captando apenas as informações que são definitivamente necessárias em uma interface do usuário específica. No final, a divisão de responsabilidades está perfeitamente organizada no GraphQL: o cliente conhece os requisitos de dados, o servidor conhece a estrutura de dados e como resolver dados de uma fonte existente (seja um banco de dados, microsserviço, API de terceiros).

Sem nova amostragem ao trabalhar com o GraphQL

Ao trabalhar com o GraphQL, não há re-seleção. Considerando que é provável que um cliente móvel obtenha uma nova busca usando a mesma API que um cliente Web com uma API REST. E, ao trabalhar com o GraphQL, o cliente móvel e o cliente da Web podem escolher diferentes grupos de campos para eles mesmos, usando a mesma API do GraphQL. Conseqüentemente, o cliente móvel pode selecionar menos informações, pois informações desnecessárias podem não ser necessárias na tela pequena (ao contrário do monitor grande no qual a versão web do aplicativo é visualizada). O GraphQL minimiza a quantidade de dados transmitidos pela rede, selecionando-os seletivamente e sendo guiados nesse caso principalmente pelas necessidades do aplicativo cliente.

GraphQL para React, Angular, Nó, etc.

O GraphQL é uma solução promissora, não apenas para desenvolvedores do React. Seja o Facebook que superou o GraphQL e, no lado do cliente, o Facebook usa o React, de fato, essa linguagem não está vinculada a nenhuma solução para o front-end ou back-end. A implementação de referência do GraphQL é escrita em JavaScript, para que o GraphQL possa ser combinado com as bibliotecas Angular, Vue, Express, Hapi, Koa e outras JavaScript nas partes cliente e servidor. Além disso, isso se aplica não apenas ao ecossistema JavaScript. O GraphQL imita o REST em um aspecto, devido ao qual se tornou popular: a interface do GraphQL é independente da linguagem de programação (linguagem de consulta) usada para comunicar dois objetos (por exemplo, cliente e servidor). Portanto, sua especificação pode ser reproduzida em qualquer linguagem de programação.

Quem usa o GraphQL?

O Facebook usa o GraphQL desde 2012, antes que essa linguagem se tornasse código aberto. O Facebook é a força motriz responsável pelo desenvolvimento da especificação GraphQL e sua implementação de referência em JavaScript. Então, trabalhando com o GraphQL, você já está de pé sobre os ombros dos gigantes. No entanto, outras empresas conhecidas usam esse idioma em seus aplicativos. Eles investem no ecossistema GraphQL, porque os aplicativos modernos precisam muito dessa linguagem. Assim, você será apoiado não apenas pelo Facebook, mas também pelas seguintes empresas:


Quando o Facebook desenvolveu o GraphQL e o tornou disponível ao público, outras empresas de aplicativos móveis também enfrentaram problemas semelhantes. Foi assim que a Netflix criou o projeto Falcor, que pode ser considerado uma alternativa ao GraphQL. O que mais uma vez confirma que, para aplicativos modernos, você precisa exatamente de soluções como GraphQL e Falcor.

A Única Fonte da Verdade

Nas aplicações GraphQL, a verdade última existe: este é o esquema GraphQL. É ela - a fonte central, que descreve todos os dados disponíveis. Enquanto o esquema GraphQL geralmente é definido no lado do servidor, os clientes podem ler (consultar) e gravar (modificar) dados com base nesse esquema. Assim, o aplicativo para servidor, em essência, fornece as informações exaustivas disponíveis no servidor, e o lado do cliente pergunta apenas o que é necessário na formulação de consultas no GraphQL ou altera pequenos fragmentos de informações usando as alterações no GraphQL.

O GraphQL segue as tendências atuais

O GraphQL segue as tendências atuais no desenvolvimento de aplicativos. Você pode ter apenas um aplicativo no back-end, mas muitas vezes acontece que muitos clientes diferentes usam esse back-end (Web client, dispositivo móvel, relógios inteligentes ...) e todos eles dependem dos dados armazenados no aplicativo de back-end. Portanto, o GraphQL pode ajudar não apenas a fazer amigos dos "dois mundos", mas também a satisfazer os requisitos de cada cliente (relacionado, por exemplo, ao usar a rede, relacionamentos de dados aninhados, selecionar apenas os dados necessários) sem a necessidade de criar uma API dedicada para cada tipo de cliente.

Por outro lado, no servidor, podemos esperar não uma única interface interna, mas um grupo de microsserviços, cada um dos quais fornece sua própria funcionalidade específica. É nesse caso que o esquema do GraphQL é ideal, cuja estrutura é tal que, nesse esquema do GraphQL, é possível agregar todos os tipos de funcionalidade.

Como o esquema do GraphQL se une

Graças à costura, você pode montar um esquema de muitos outros. Quando posso entrar nessa situação? Digamos que seu back-end seja implementado usando uma arquitetura de microsserviço. Cada microsserviço processa dados e lógica de negócios relacionados a uma área de assunto específica. Portanto, cada microsserviço pode definir seu próprio esquema GraphQL. Depois disso, você precisará costurá-los para montar um de todos os esquemas que o aplicativo cliente acessará. No final, cada microsserviço pode ter seu próprio terminal GraphQL, e um gateway API GraphQL consolidará todos os esquemas em um global, para fornecê-lo aos aplicativos clientes.

Introspecção GraphQL

A introspecção do GraphQL é a capacidade de extrair um esquema do GraphQL com a API do GraphQL. Como o esquema contém todas as informações sobre todos os dados disponíveis na API do GraphQL, ele pode ser usado com muito sucesso na geração automática de documentação da API. No entanto, o assunto não se limita a documentar a API; a introspecção também pode ser usada para simular um esquema GraphQL em um aplicativo cliente (para fins de teste) ou para recuperar esquemas de vários microsserviços e depois juntá-los.

GraphQL fortemente tipado

O GraphQL é uma linguagem de consulta altamente tipada, escrita na expressiva Schema Definition Language (SDL) para GraphQL. Essa linguagem tem as mesmas vantagens que qualquer linguagem de programação fortemente tipada. É menos propenso a erros, pode ser validado em tempo de compilação e pode ser utilizado para integração com os recursos suportados do editor / IDE, como preenchimento automático e suporte de entrada.

Versionando o GraphQL

O GraphQL não possui essas versões de API às quais estamos acostumados no REST. É normal no REST oferecer várias versões da mesma API (por exemplo, api.domain.com/v1/, api.domain.com/v2/), pois os recursos ou sua estrutura podem mudar com o tempo. No GraphQL, você pode converter APIs em outras não recomendadas no nível do campo. Portanto, o cliente recebe um aviso ao acessar um campo não recomendado. Depois de algum tempo, o campo não recomendado pode ser excluído do esquema e não mais clientes o usarão. Assim, a API GraphQL pode ser desenvolvida sem a necessidade de versionamento.

Crescimento do ecossistema GraphQL

O ecossistema GraphQL está crescendo. Não se trata apenas de integrações com editores e IDEs relacionadas à natureza fortemente tipada do GraphQL; para o GraphQL, como tal, existem novos aplicativos completos. Por exemplo, você pode recordar o Postman, que foi usado ao trabalhar com a API REST e agora com o mesmo objetivo, mas com a API GraphQL, o GraphiQL ou o GraphQL Playground é usado. Também existem várias bibliotecas para você, por exemplo, Gatsby.js, um gerador estático de sites para o React que usa o GraphQL. Por exemplo, o Gatsby.js permite que você escreva um mecanismo de blog que preencha seu blog com conteúdo durante a compilação por meio da API do GraphQL. Portanto, você também terá CMSs sem uma parte do cliente (por exemplo, GraphCMS) fornecendo conteúdo (para um blog) via GraphQL. API No entanto, não apenas componentes tecnológicos estão se desenvolvendo nessa área. À medida que os cogumelos crescem após a chuva, também é fácil encontrar conferências, mitaps e comunidades dedicadas ao GraphQL, boletins e podcasts.

Se eu mudar para o GraphQL - vou all-in?

Adicionando o GraphQL à pilha tecnológica existente, é claro que não fazemos o all-in. Ao migrar de um aplicativo de back-end monolítico para uma arquitetura de microsserviço, o mais importante é substituir a API do GraphQL por novos microsserviços. De fato, é precisamente na presença de muitos microsserviços que você e sua equipe podem implementar com segurança o gateway GraphQL, costurando esquemas e consolidando-os em um esquema global. Mas o gateway da API pode ser usado não apenas com microsserviços, mas também com um aplicativo REST monolítico. É assim que você pode combinar todas as suas APIs em um gateway e migrar para o GraphQL passo a passo.

Desvantagens do GraphQL

A seguir, discutiremos algumas das desvantagens associadas ao uso do GraphQL.

Complexidade de consulta do GraphQL

Às vezes, o GraphQL é usado incorretamente, tento substituí-lo por um banco de dados do lado do servidor. Não, isso não serve. GraphQL é apenas uma linguagem de consulta. Quando, no lado do servidor, a solicitação precisa ser resolvida com dados, geralmente há uma implementação independente do GraphQL que fornece acesso ao banco de dados. O GraphQL é indiferente neste caso. Além disso, o GraphQL não elimina gargalos de desempenho quando você precisa endereçar muitos campos (autores, artigos, comentários) em uma consulta. Independentemente da arquitetura em que a solicitação foi feita - RESTful ou GraphQL, você ainda precisa extrair vários campos da fonte.

Portanto, teremos um problema se o cliente enviar um monte de solicitações imediatamente para o conjunto de campos aninhados. Geralmente, os desenvolvedores do lado do cliente não sabem quantas consultas diferentes do banco de dados precisam ser processadas no aplicativo do servidor se as chamadas de dados em massa começarem. É nesses casos que um mecanismo é necessário (por exemplo, a profundidade máxima da consulta, ponderando a complexidade das consultas, evitando recursões e consultas constantes) para impedir o fluxo de consultas muito caras do cliente.

Limite de velocidade no GraphQL

Outro problema é a limitação de velocidade. Enquanto no REST é relativamente simples dizer "não são permitidas mais do que muitas consultas por dia", é difícil formular essa instrução para operações individuais do GraphQL, pois não existem apenas operações "dispendiosas" e "não dispendiosas", mas também muitas graduações intermediárias. É nesses casos que as empresas que fornecem APIs GraphQL públicas oferecem seus próprios cálculos de limite de velocidade , frequentemente reduzidos aos valores máximos acima mencionados de profundidade e ponderação da complexidade da consulta.

Cache do GraphQL

Ao trabalhar com o GraphQL, implementar um cache simplificado é muito mais complicado do que no REST. Ao trabalhar com o REST, acessamos os recursos por URL e, portanto, podemos organizar o cache no nível do recurso, pois o URL do recurso pode servir como seu identificador. No GraphQL, isso é complicado porque todas as consultas podem ser diferentes, mesmo que todos operem no mesmo objeto. Em uma solicitação, você pode solicitar o nome do autor e, na próxima - não apenas o nome do autor, mas também o endereço de email. É nesses casos que você precisará de um cache de filigrana mais no nível do campo, e não é tão simples implementá-lo. No entanto, a maioria das bibliotecas criadas sobre o GraphQL oferece esses mecanismos de cache imediatamente.

Por que não descansar?

GraphQL – REST, . REST – GraphQL, REST?
REST URL , . «», id, , id. GraphQL , . , , , GraphQL , .

, REST. Airbnb. , . REST-, REST- . , , GraphQL API, GraphQL, (, ), (., ).

, GraphQL ; , , , . GraphQL – Facebook , -.

, , REST – . , GraphQL. , GraphQL, - .

Source: https://habr.com/ru/post/pt424037/


All Articles