Smashing Podcast Episódio 31 com Eve Porcello: O que é GraphQL?

Neste episódio, estamos falando sobre GraphQL. O que é e como resolve alguns problemas comuns de API? Falei com a especialista Eve Porcello para descobrir.

Mostrar notas

• Eva no Twitter
• A empresa de Eve, Moon Highway
• Aprendendo GraphQL com O'Reilly
• Descubra seu caminho através do GraphQL Wilderness - O workshop GraphQL de Eve será lançado no início de 2021

Atualização semanal

• Como usar o MDX armazenado no Sanity em um site Next.js
  escrito por Jason Lengstorf
• Criando um chatbot de conversação habilitado para NLP usando o Dialogflow do Google
  escrito por Nwani Victory
• Considerações éticas na pesquisa de UX: a necessidade de treinamento e revisão
  escrito por Victor Yocco
• Tornando os sites mais fáceis de conversar
  escrito por Frederick O'Brien
• Como projetar uma interface de usuário simples quando você tem uma solução complexa
  escrito por Suzanne Scacca

Transcrição

Drew McLellan: Ela é engenheira de software, instrutora, autora e cofundadora da empresa de treinamento e desenvolvimento curricular, Moon Highway. Sua carreira começou escrevendo especificações técnicas e criando designs de UX para projetos web. Desde o início da Moon Highway em 2012, ela criou conteúdo de vídeo para egghead.io e LinkedIn Learning, e é coautora dos livros Learning React e Learning GraphQL for O'Reilly's Media.

Drew: Ela também é uma palestrante frequente em conferências e apresentou em conferências como React Rally, GraphQL Summit e OSCON. Então, sabemos que ela é especialista em GraphQL, mas você sabia que uma vez ela ensinou um urso polar a jogar xadrez? Meus amigos, por favor, dêem as boas-vindas a Eve Porcello.

Drew: Oi Eva, como você está?

Eve Porcello: Estou arrasando.

Drew: Como mencionei lá, você é um educador em coisas como JavaScript e React, mas eu queria falar com você hoje sobre uma de suas outras áreas especializadas, GraphQL. Muitos de nós já ouviram falar do GraphQL de alguma forma, mas podem não ter certeza do que é, ou o que ele faz e, em particular, que tipo de problema ele resolve na pilha da web.

Drew: Então prepare o cenário para nós, se você quiser, se eu sou um desenvolvedor front-end, onde o GraphQL se encaixa no ecossistema e qual função ele desempenha para mim?

Eva: Sim. O GraphQL se encaixa entre o front-end e o back-end. É meio que viver no meio entre os dois e oferece muitos benefícios para desenvolvedores front-end e back-end.

Eve: Se você é um desenvolvedor front-end, pode definir todos os requisitos de dados de front-end. Então, se você tem uma grande lista de componentes React, por exemplo, você pode escrever uma consulta. E isso definirá todos os campos que você precisaria para preencher os dados dessa página.

Eve: Agora, com a parte de back-end, é realmente própria, porque podemos coletar muitos dados de várias fontes diferentes. Portanto, temos dados em APIs REST, bancos de dados e todos esses lugares diferentes. E o GraphQL nos fornece essa pequena camada de orquestração para realmente entender o caos de onde todos os nossos dados estão. Então é realmente útil para todo mundo na pilha.

Drew: Então é basicamente uma tecnologia baseada em API, não é? Ele fica entre o front-end e o back-end e fornece algum tipo de API, correto?

Eve: Sim, isso é exatamente certo. Exatamente.

Drew: Acho que, na última década, o padrão-ouro para APIs tem sido o descanso. Portanto, se você tiver um aplicativo do lado do cliente e precisar preenchê-lo com dados do back-end, criaria um endpoint da API REST e consultaria isso. Então, onde esse modelo cai? E quando podemos precisar que o GraphQL entre e resolva isso para nós?

Eve: Bem, o problema com o qual o GraphQL realmente nos ajuda, meio que o problema de ouro, a solução de ouro, eu acho, que o GraphQL fornece é que com REST estamos extraindo muitos dados. Então, se eu tiver usuários cortados ou produtos cortados, isso me devolverá todos os dados toda vez que eu acertar a rota.

Eve: Com o GraphQL, podemos ser um pouco mais exigentes sobre quais dados queremos. Então, se eu precisar apenas de quatro campos de um objeto que tenha cem, poderei realmente identificar esses campos e não precisar carregar dados ou carregar todos esses dados, devo dizer, em seu dispositivo, porque isso é muito trabalho braçal extra, especialmente para o seu telefone.

Drew: Já vi e trabalhei com APIs REST no passado que têm um campo opcional onde você pode passar uma lista dos dados que deseja de volta ou pode aumentar o que retorna com coisas extras. E então eu acho que está identificando esse problema, não é? Isso quer dizer que você nem sempre deseja os mesmos dados de volta todas as vezes. Então é que o GraphQL formaliza essa abordagem de permitir que o front-end especifique o que o back-end vai retornar, em termos de dados?

Eva: Sim, exatamente. Assim, sua consulta se torna como você pergunta, como você filtra, como você busca qualquer tipo de informação de qualquer lugar.

Eve: Também acho importante observar que não precisamos desmontar todas as nossas APIs REST para trabalhar com o GraphQL com sucesso. Muitas das implementações mais bem-sucedidas do GraphQL que eu vi por aí, são wrappers em torno de APIs REST. E a consulta do GraphQL realmente oferece uma maneira de pensar sobre quais dados você precisa. E então talvez alguns dos seus dados venham de nossos usuários e produtos, exemplos, alguns dos dados venham do REST, alguns deles venham de um banco de dados.

Drew: Acho que o cenário familiar é que você pode ter um endpoint em seu site que retorna informações sobre um usuário para exibir o cabeçalho. Pode fornecer seu nome de usuário e seu avatar. E você seleciona isso em todas as páginas e preenche os dados, mas depois encontra em outro lugar em seu aplicativo que precisa exibir o nome completo.

Drew: Então você adiciona isso ao endpoint e ele começa a retornar isso. E então você faz sua seção de gerenciamento de contas e precisa do endereço de correspondência deles. Então, isso também é retornado por esse endpoint.

Drew: E antes que você perceba, esse endpoint está retornando uma carga útil inteira que custa muito no back-end para montar e, obviamente, muito para baixar.

Drew: E isso foi selecionado em cada página apenas para mostrar um avatar. Então, acho que esse é o tipo de problema que cresce com o tempo, que era tão fácil de cair, principalmente em grandes equipes, que o GraphQL está no topo desse problema. Ele sabe como resolver isso e foi projetado para resolver isso.

Eva: Exatamente. E sim, eu acho que toda a ideia de um esquema GraphQL, eu acho que é realmente, é um pouco menos falado do que a parte da linguagem de consulta do GraphQL. Mas eu realmente sinto que o Schema em particular nos dá esse bom sistema de tipos para API.

Eve: Então, qualquer pessoa na equipe, gerentes, desenvolvedores front-end, desenvolvedores back-end, qualquer pessoa que realmente esteja lidando com dados pode se reunir, unir-se em torno de quais dados realmente queremos fornecer nessa API e todos saberão qual é essa fonte a verdade é que eles podem construir suas próprias partes do aplicativo com base nisso.

Eve: Então, há algumas coisas complicadas de gerenciamento do Schema que surgem com isso também. Mas no que diz respeito à mudança dos microsserviços de volta para os monólitos, estamos fazendo isso, mas ainda obtendo todos os benefícios que gostamos dos microsserviços.

Drew: E entendi corretamente que a maneira típica de configurar um sistema GraphQL é que você teria basicamente uma rota, que é o ponto final para o qual você envia todas as suas consultas para que você não precise... Muitas vezes, uma das as coisas mais difíceis é descobrir o que nomear e qual deve ser o caminho em que essa consulta específica deve estar. Está retornando usuários e produtos, deveria ser cortar algo dos usuários ou cortar algo do produto?

Drew: Com o GraphQL, você tem apenas um endpoint para o qual você dispara suas consultas e recebe uma resposta apropriada.

Eva: Exatamente. Sim. É um único ponto final. Acho que você ainda está lidando com problemas de nomenclatura porque está nomeando tudo no Schema. Mas até onde, eu sinto que muitas empresas que fizeram grandes apostas em microsserviços, todo mundo gosta, quais endpoints nós temos? Onde eles estão? Como eles são documentados? E com o GraphQL, temos um lugar, um tipo de dicionário para procurar qualquer coisa que queiramos descobrir sobre como a API funciona.

Drew: Então, estou muito familiarizado com outras linguagens de consulta, como o SQL é um exemplo óbvio de uma linguagem de consulta que muitos desenvolvedores da web conhecem. E as consultas que assumem a forma quase como um comando. É uma string de texto, não é, Selecione isso de onde, onde, o que for. Qual o formato das consultas com o GraphQL?

Eve: Ainda é uma string de tecnologia, mas não define de onde vem essa lógica. E muito da lógica é movida de volta para o servidor. Portanto, o servidor GraphQL, a API do GraphQL, é realmente responsável por dizer: “Vá obter esses dados de onde estão, filtre-os com base nesses parâmetros”.

Eve: Mas na linguagem de consulta, é muito orientada para o campo. Então, apenas adicionamos campos para qualquer coisa que queremos recuperar. Podemos colocar filtros nessas consultas, é claro, também. Mas acho que é um pouco menos direto sobre de onde vem essa informação. Muitas das funcionalidades são incorporadas ao servidor.

Drew: Então você pode misturar e combinar em uma consulta. Você pode fazer uma solicitação que traz muitos tipos diferentes de dados em uma solicitação. Isso está certo?

Eve: Sim, isso é absolutamente certo. Assim, você pode enviar uma consulta para quantos campos seu servidor permitir e trazer de volta todos os tipos de dados aninhados. Mas é assim que funciona, conectamos diferentes tipos em campos. Então, acho que vamos reciclar minha ideia de usuários e produtos, mas o usuário pode ter um campo de produtos que retorne uma lista de produtos. Todos esses estão associados a outros tipos também. Então, tão profundamente aninhado quanto queremos que a consulta vá, podemos.

Drew: Isso significa recuperar os dados para uma visualização típica em seu aplicativo da Web que pode ter todos os tipos de coisas acontecendo, que você pode apenas fazer uma solicitação ao back-end e obter tudo de uma só vez sem precisar fazer diferentes consultas para diferentes endpoints, porque tudo é apenas uma coisa?

Eva: Sim. Esse é exatamente o objetivo todo, é apenas uma única consulta, defina todos os campos que você deseja e, em seguida, retorne-o em uma resposta.

Drew: E as consultas são baseadas em JSON, certo?

Eve: A consulta em si é uma string de texto, mas normalmente retorna dados JSON. Portanto, se eu tiver os campos, minha resposta JSON corresponderá exatamente e, portanto, ficará muito claro o que você receberá ao enviar essa consulta, porque a resposta dos dados será exatamente a mesma.

Drew: Muitas das consultas parecem ser quase como objetos simples, como um cliente ou um produto. Existe uma maneira de especificar consultas mais complexas em que a lógica de negócios é controlada no back-end? Digamos que eu queira obter uma lista de equipes para um usuário, mas apenas onde esse usuário é um administrador de uma equipe e onde o plano de equipe não expirou, e todos esses tipos de restrições reais que enfrentamos no desenvolvimento diário de aplicativos da Web. Isso pode ser alcançado com o GraphQL?

Eva: Com certeza. Então, essa é a coisa realmente empolgante e poderosa sobre o GraphQL, você pode mover muito dessa lógica para o servidor. Se você tivesse uma consulta complexa, algum tipo de usuário realmente específico que você desejasse obter, tudo o que você precisaria fazer no Schema é dizer "Obter usuário complicado" e, em seguida, no servidor, haveria uma função em que você poderia escrever toda a lógica em qualquer idioma que você quisesse. JavaScript é a linguagem de implementação GraphQL mais popular, mas você não precisa usar isso. Então Python, Go, C++, o que você quiser usar, você pode construir um servidor GraphQL com isso. Mas sim, você pode definir uma consulta tão complexa quanto quiser.

Drew: E acho que isso permite encapsular muita lógica de negócios em novos tipos de objetos. Isto é Justo? Você sabe, você configura um usuário complicado e não precisa pensar o que é um usuário complicado, mas você pode continuar usando esse usuário complicado e saber que a lógica de negócios é implementada nele. Isso está certo?

Eva: Isso é exatamente certo. Então eu acho que isso é muito bom para o pessoal de front-end porque eles podem começar a prototipar com base nisso. E então a equipe de back-end poderia implementar essas funções para fazer isso funcionar. E então há esse tipo de entendimento compartilhado sobre o que esse tipo realmente é e quem eles são, e “Quais são os campos desse tipo?” E tudo pode ser tratado onde quer que o GraphQL esteja funcionando na pilha. E é por isso que não é realmente uma tecnologia de front-end ou back-end. É realmente tipo de ambos, e nenhum.

Drew: Parece que está formalizando a API e o relacionamento entre front-end e back-end, então todos estão obtendo uma interface previsível que é padronizada.

Eva: Exatamente.

Drew: O que eu acho que em organizações onde o front-end e o back-end pertencem a equipes diferentes, o que não é incomum, acho que essa abordagem também permite que alterações sejam feitas, digamos, no front-end, pode exigir diferentes dados, sem precisar de alguém que trabalhe no backend para fazer as alterações que correspondem a isso. Você ainda tem essa API quase infinitamente personalizável sem exigir nenhum trabalho para alterá-la se precisar de novos dados.

Eve: Sim, exatamente certo.

Drew: Então, o servidor GraphQL é responsável por formatar a resposta ou você precisa fazer isso na lógica do lado do servidor?

Eve: Então o servidor GraphQL define duas coisas. Ele define o próprio Schema que reside no servidor e, em seguida, define as funções do resolvedor. Essas são funções que vão buscar os dados de onde quer que estejam. Portanto, se eu tiver uma API REST que estou envolvendo com o GraphQL, o resolvedor buscaria nessa API, transformaria os dados da maneira que precisasse e os retornaria ao cliente nessa função. Você também pode usar qualquer tipo de função de banco de dados que desejar nesse servidor. Então, se você tem dados em vários lugares diferentes, este é um ponto coeso muito bom para colocar todos esses dados e projetar toda a lógica ao redor: “De onde estão vindo esses dados? Como queremos transformá-lo?”

Drew: O cliente diz: “Quero um usuário complexo”, o servidor recebe isso em uma consulta e pode dizer: “Certo, vou procurar o resolvedor de usuário complexo”. Isso está certo?

Eva: Mm-hmm (afirmativo).

Drew: Qual é a função, e então você escreve sua lógica para que sua equipe de back-end, ou quem escreve a lógica dentro dessa função, faça o que for necessário para retornar um usuário complexo.

Eva: Sim, exatamente.

Drew: Então, isso pode ser chamar outras APIs, consultar um banco de dados, procurar coisas no cache ou praticamente qualquer coisa.

Eva: Praticamente qualquer coisa. E então, desde que o retorno da função corresponda aos requisitos do Schema, corresponda a quais campos, quais tipos, estavam retornando lá, tudo funcionará bem e harmoniosamente.

Drew: Acho que dá a você um formato de resposta consistente em toda a sua API apenas por padrão. Você não tem que projetar o que parece. Você acaba de obter um resultado consistente.

Eva: Sim, exatamente.

Drew: Acho que isso pode ser uma grande vitória, porque pode ser muito difícil manter a consistência em uma grande variedade de pontos finais da API, especialmente em equipes maiores. Pessoas diferentes estão trabalhando em coisas diferentes. A menos que você tenha uma governança bastante rígida, isso pode se tornar muito complexo rapidamente, não é?

Eva: Sim, absolutamente. E eu acho que o Schema é apenas um pequeno documento tão bom para descrever tudo. Você obtém o benefício automático de poder ver todos os campos desse Schema sempre que estiver tentando enviar consultas para ele, porque você pode enviar consultas de introspecção e há todos os tipos de ferramentas legais para isso, como GraphQL e GraphQL Playground, pequenas ferramentas que você pode usar para interagir com os dados da API.

Eve: Mas também, se você já brincou com o Postman, como fazer ping em uma API REST, muitas dessas, a documentação realmente não existe ou é difícil de encontrar, ou coisas assim. O GraphQL realmente oferece essa boa camada coesa para descrever tudo o que pode fazer parte dessa API.

Drew: Na prática, como as coisas funcionam no lado do servidor? Quero dizer, acho que você precisa executar um serviço GraphQL como parte de sua infraestrutura, mas qual a forma disso? É um servidor inteiro rodando em sua própria porta? Ou é apenas como uma biblioteca que você integra ao seu Express ou Apache existente ou qualquer outra coisa com uma rota que resolva para esse serviço? Como você implementa isso?

Eve: Sim, é um servidor real. Assim, as implementações GraphQL mais populares são os servidores Node.js. Quando o GraphQL como especificação foi lançado, a equipe lançou essa implementação de referência em JavaScript, uma espécie de servidor Node que serviu de guia para todos esses outros que surgiram. Mas sim, você pode executar esses servidores em suas próprias instâncias. Você pode colocá-los no Lambda. Então existe o Apollo Server Express, existe o Apollo Server Lambda; todos os tipos de diferentes tipos de implementações que você pode usar para realmente executar essa coisa.

Drew: Então você mencionou brevemente antes o conceito de Schema que o servidor tem.

Eva: Sim.

Drew: Isso lhe dá a capacidade de descrever seus tipos mais estritamente do que apenas, você sabe, mapear um nome para um resolvedor. Há mais envolvido lá, não é?

Eva: Sim. Há uma linguagem completa. Então eu fiz referência à especificação e não descrevi o que é. O próprio GraphQL é uma especificação que descreve a linguagem de consulta e a linguagem de definição do Schema. Portanto, tem sua própria sintaxe. Ele tem suas próprias regras para definir esses tipos.

Eve: Quando você está usando a linguagem de definição Schema, você basicamente usa todos os recursos dessa linguagem para pensar, quais são os tipos que fazem parte da API? Também é onde você define as consultas, as mutações, que são os verbos, como as ações, criar login de conta, coisas assim. E até assinaturas de GraphQL, que são outra coisa legal, GraphQL em tempo real que você pode definir ali mesmo no Schema.

Eve: Então sim, o Schema é realmente super importante. E acho que isso nos dá essa boa imposição de tipos em todo o nosso aplicativo Stack completo, porque assim que você começa a se desviar desses campos e desses tipos, começa a ver erros, o que é bom, porque você estão seguindo as regras do Schema.

Drew: Existe algum cruzamento entre isso e o TypeScript? Existe uma espécie de sinergia entre os dois aí?

Eva: Com certeza. Então, se você é uma pessoa que fala muito sobre GraphQL, às vezes as pessoas vão te dizer que é ruim, e eles vão até você publicamente, quando você pode fazer isso, e falam sobre como o GraphQL não é bom. Mas muitas vezes eles ignoram as coisas legais que você recebe dos tipos. Então, no que diz respeito à sinergia com o TypeScript, absolutamente, você pode gerar automaticamente tipos para seu aplicativo front-end usando os tipos do Schema. Portanto, isso é uma grande vitória porque você pode não apenas gerá-lo pela primeira vez, o que oferece uma grande interoperabilidade com seu aplicativo de front-end, mas também, à medida que as coisas mudam, você pode regenerar tipos e, em seguida, criar para refletir essas alterações. Então, sim, acho que essas coisas se encaixam muito bem, já que os tipos começam a ser uma espécie de regra de fato.

Eve: … para ser uma espécie de regra de fato em JavaScript, eles se encaixam muito bem.

Drew: Parece ser uma espécie de tema contínuo com a forma como o TypeScript foi projetado... isso não é TypeScript, desculpe. O GraphQL foi projetado para que haja muito sobre a formalização da interação entre o front-end e o back-end. E está chegando como uma solução entre apenas cria consistência e uma formalização do que até agora tem sido uma experiência bastante desconexa com descanso para muitas pessoas. Uma coisa que sempre devemos ter em mente ao escrever aplicativos do lado do cliente é que o código está sujeito a inspeção e potencialmente modificação. E ter uma API onde o cliente pode apenas solicitar dados pode ser perigoso. Agora, se você puder especificar quais campos deseja, talvez isso possa ser perigoso. Onde, em toda a pilha, você lidaria com a autorização de usuários e garantiria que as regras de negócios em torno de seus dados fossem aplicadas?

Eve: Você lidaria com tudo isso no servidor. Então, isso pode acontecer de muitas maneiras diferentes. Você não precisa usar uma estratégia única, mas seus resolvedores lidarão com sua autorização. Isso pode significar envolver uma API REST existente, como um serviço como Auth0 ou algo que você criou por conta própria. Isso pode significar interagir com um OAuth, como GitHub ou Facebook ou login do Google, esses tipos de coisas que envolvem passar tokens de um lado para o outro com resolvedores. Mas muitas vezes isso será construído diretamente no Schema. Então o Schema dirá, eu não sei, vamos criar uma mutação de login. E então eu envio essa mutação com minhas credenciais e, em seguida, no servidor, todas essas credenciais são verificadas. Assim, o cliente não precisa se preocupar tanto, talvez um pouco de passagem de tokens e coisas assim. Mas a maior parte disso é apenas embutido no servidor.

Drew: Então, essencialmente, isso não muda em comparação com a forma como estamos construindo terminais de descanso no momento. Resto como uma tecnologia, bem, ela também não lida com autorização e nós temos middleware e coisas no servidor que lidam com isso. E é exatamente o mesmo com o GraphQL. Você apenas lida com isso. Existem convenções na comunidade GraphQL para fazer isso? Existem abordagens comuns ou está em todo lugar como as pessoas escolhem implementá-las?

Eve: É honestamente em todo lugar. Acho que na maioria das vezes você verá pessoas construindo no Schema e com isso quero dizer, representando esses tipos e usuários autorizados versus usuários comuns construindo esses tipos no próprio Schema. Mas você também verá muitas pessoas usando soluções de terceiros. Eu mencionei Auth0. Muitas pessoas vão transferir sua autorização para empresas que estão mais focadas nisso, principalmente empresas menores, startups, coisas assim. Mas você também verá empresas maiores começando a criar soluções para isso. Então AWS, Amazon tem AppSync, que é o seu tipo de GraphQL, e eles têm rolos de autor embutidos diretamente no AppSync. E isso é legal só para poder, eu não sei, não ter que se preocupar com todas essas coisas ou pelo menos fornecer uma interface para trabalhar com isso. Então, muitas dessas ferramentas do ecossistema, acho que a autorização é um tópico tão grande no GraphQL. Eles viram a necessidade, a demanda por soluções de autenticação e abordagens padrão para lidar com autenticação no gráfico.

Drew: Acho que dificilmente existe uma implementação por aí que não precise de algum tipo de autorização. Então, sim, vai ser um requisito bastante comum. Todos nós estamos construindo cada vez mais aplicativos com componentes, especialmente quando estamos usando coisas como React e View e o que você tem. E o princípio do acoplamento fraco nos deixa com muitos componentes que não necessariamente sabem o que mais está sendo executado na página ao seu redor. Existe um perigo como resultado disso, você pode acabar com muitos componentes consultando os mesmos dados e fazendo várias solicitações? Ou é apenas um problema de arquitetura em seu aplicativo que você precisa resolver para isso? Existem soluções bem conhecidas para lidar com isso?

Eve: Bem, acho que porque o GraphQL na maioria das vezes, não 100% das soluções, mas quase todas as consultas do GraphQL são enviadas por HTTP. Portanto, se você deseja rastrear onde essas várias solicitações estão ocorrendo, provavelmente é um problema bastante familiar para as pessoas que estão usando dados de descanso para seus aplicativos. Portanto, existem algumas ferramentas como Paulo Client Dev Tools e Urkel Dev Tools para desenvolvedores front-end que dizem: “O que está acontecendo? Quais consultas estão nesta página?” Isso lhe dá insights realmente claros sobre o que está acontecendo. Existem várias escolas de pensamento com isso. Criamos uma consulta grande e enorme para todos os dados da página? Ou criamos consultas menores para carregar dados para diferentes partes do aplicativo? Ambos como você pode imaginar, eles têm suas próprias desvantagens, apenas porque se você tem uma grande consulta, você está esperando por mais campos.

Eve: Se você tiver consultas menores, pode haver colisões entre os dados que você está solicitando. Mas eu acho, e para não sair muito pela tangente, mas eu já estou lá. Portanto, há algo chamado Diretiva Diferida que está chegando à especificação do GraphQL e a Diretiva Diferida vai ajudar com o tipo de carregamento secundário de conteúdo. Então, digamos que você tenha algum conteúdo no topo da página, o conteúdo super importante que você deseja carregar primeiro. Se você adicionar isso à sua consulta e, em seguida, quaisquer campos subsequentes obterem a diretiva adiada sobre isso. É apenas um pequeno decorador que você adicionaria a um campo, que dirá: "Tudo bem, carregue os dados importantes primeiro, depois espere e carregue os segundos dados". E meio que lhe dá isso, é a aparência de um tipo de transmissão de dados para o seu front-end, para que haja desempenho percebido, haja interatividade. As pessoas estão vendo os dados imediatamente em vez de esperar que cada campo seja carregado para a página, o que sim, pode ser um problema.

Drew: Sim. Eu acho que isso permite que você arquitete páginas onde tudo o que é... nós não gostamos de falar muito sobre a janela de visualização, mas é tudo acima da dobra, você pode priorizar, carregar e carregar secundariamente em tudo mais baixa. Então, falamos muito sobre consultar dados. Um dos principais trabalhos de uma API é enviar dados novos e modificados de volta ao servidor para persistência. Você mencionou brevemente as mutações anteriormente. Essa é a terminologia que o GraphQL usa para gravar dados de volta no servidor?

Eva: Exatamente. Portanto, qualquer tipo de alteração que queremos fazer nos dados, qualquer coisa que queiramos escrever de volta no servidor, são mutações, e todas são como consultas, são operações nomeadas que vivem no servidor. Então, você pode pensar em quais são todas as coisas que queremos que nossos usuários possam fazer? Represente aqueles com mutações. E então, novamente no servidor, escreva todas as funções que fazem essas coisas funcionarem.

Drew: E isso é tão simples quanto consultar dados? Chamar uma mutação é tão fácil?

Eva: Sim. Faz parte da linguagem de consulta. Parece bastante idêntico. A única diferença é que, bem, acho que as consultas recebem filtros. Então, as mutações pegaram o que pareciam ser filtros na própria consulta. Mas esses são responsáveis ​​por realmente alterar os dados. Um e-mail e uma senha podem ser enviados com uma mutação e, em seguida, o servidor os coleta e os usa para autorizar o usuário.

Drew: Então, assim como antes, você está criando um resolvedor no backend para lidar com isso e fazer o que for necessário. Uma ocorrência comum ao gravar dados é que você deseja confirmar suas alterações e, em seguida, consultar novamente para obter o tipo de estado atual delas. O GraphQL tem um bom fluxo de trabalho para isso?

Eve: Meio que vive na própria mutação. Então, muitas vezes ao criar seu Schema você vai criar a operação de mutação. Vou ficar com o login, leva o e-mail e a senha. E a própria mutação retornou algo. Então, ele pode retornar algo tão simples quanto um booleano, isso correu bem, ou isso correu mal, ou pode retornar um tipo real. Muitas vezes você verá a mutação como a mutação de login, talvez ela retorne um usuário. Assim, você obtém todas as informações sobre o usuário assim que ele estiver logado. Ou você pode criar um tipo de objeto personalizado que forneça esse usuário mais a hora em que o usuário efetuou login e talvez um pouco mais de metadados sobre essa transação no objeto de retorno . Então, novamente, cabe a você projetar isso, mas esse padrão é realmente incorporado ao GraphQL.

Drew: Tudo isso soa muito bem, mas toda escolha técnica envolve trocas. Quais são as desvantagens de usar o GraphQL? Existem cenários em que seria uma escolha muito ruim?

Eve: Eu acho que o lugar onde um GraphQL pode ter problemas é criar um mapa um para um de-

Eve: … a luta é criar um mapa individualizado de dados tabulares. Então, digamos que você tenha, eu não sei, pense em uma tabela de banco de dados com todos os tipos de campos diferentes e, não sei, milhares de campos em um tipo específico, coisas assim, esse tipo de dados pode ser bem representado com GraphQL, mas às vezes quando você executa um processo para gerar um Schema nesses dados, você fica com, em um Schema, os mesmos problemas que você tinha no banco de dados, que talvez seja um excesso de dados que vai além do que o cliente realmente requer. Então eu acho que esses lugares, eles são potencialmente problemas. Conversei com pessoas que geraram Schemas automaticamente com base em seus dados e se tornaram um Schema de um milhão de linhas ou algo assim, apenas milhares e milhares de linhas de código do Schema. E é aí que se torna um pouco complicado, como o quão útil isso é como um documento legível por humanos?

Eva: Sim. Portanto, qualquer tipo de situação em que você está lidando com um cliente, é um ajuste muito bom no que diz respeito à modelagem de todos os tipos diferentes de dados, torna-se um pouco complicado se suas fontes de dados forem muito grandes.

Drew: Então parece que em qualquer lugar onde você vai selecionar cuidadosamente as respostas nos campos e fazê-lo mais manualmente, você pode obter resultados realmente poderosos. Mas se você está gerando coisas automaticamente porque acabou de ter um Schema enorme, então talvez se torne um pouco difícil de manejar.

Eva: Sim. E acho que as pessoas estão ouvindo e discordando de mim porque também existem boas ferramentas para isso. Mas acho que o lugar onde o GraphQL realmente brilha é a etapa de abstração da lógica para o servidor, dando aos desenvolvedores de front-end a liberdade de definir seus componentes ou seus requisitos de dados de front-end e realmente gerenciar o Schema como uma equipe.

Drew: Existe algo embutido na linguagem de consulta para lidar com a paginação de resultados ou isso se resume a uma implementação personalizada conforme necessário?

Eva: Sim. Paginação, você construiria primeiro no Esquema, para poder definir a paginação para isso. Há muitas diretrizes que surgiram na comunidade. Um bom exemplo para ver se você é novo no GraphQL ou não, eu vejo isso o tempo todo, é a API do GitHub GraphQL. Eles basicamente recriaram sua API para v4 de sua API pública usando GraphQL. Então, esse é um bom ponto para ver como uma grande empresa está usando isso em escala. Muitas pessoas têm grandes APIs em execução, mas não as tornam públicas para todos. Portanto, a paginação é incorporada a essa API muito bem e você pode retornar, não sei, os primeiros 50 repositórios que você criou, ou também pode usar a paginação baseada em cursor para retornar registros com base em ideias em seus dados. Portanto, paginação baseada em cursor e tipo de paginação posicional como primeiro, último registro, geralmente é assim que as pessoas abordam isso, mas há muitas técnicas.

Drew: Existem grandes pegadinhas que devemos saber ao usar o GraphQL? Digamos que estou prestes a implantar uma nova instalação do GraphQL para minha organização, vamos construir todos os nossos novos endpoints de API usando o GraphQL daqui para frente. O que devo saber? Há alguma coisa à espreita nos arbustos?

Eve: À espreita no mato, sempre com tecnologia, certo? Eu acho que uma das coisas que não está embutida no GraphQL, mas pode ser implementada sem muito incômodo, é a segurança da API. Por exemplo, você mencionou se eu tenho uma consulta enorme, falamos sobre isso com autorização, mas também é assustador abrir uma API onde alguém poderia enviar uma consulta aninhada enorme, amigos de amigos, amigos de amigos, amigos de amigos , para baixo e para baixo na cadeia. E então você está basicamente permitindo que as pessoas façam DDoS com essas consultas enormes. So there's things that you can set up on the server to limit query depth and query complexity. You can put queries on a safe list. So maybe your front ends, you know what they all are and it's not a public API. So you only want to let certain queries come over the wire to you. So I would say before rolling that out, that is definitely a possible gotcha with the GraphQL.

Drew: You do a lot of instruction and training around GraphQL, and you've co-written the O'Reilly 'animal' book with Alex Banks called Learning GraphQL. But you've got something new that you're launching early in 2021, is that right?

Eve: That's right. So I have been collaborating with egghead.io to create a full stack GraphQL video course. We're going to build an API and front end for a summer camp, so everything is summer camp themed. And yeah, we're just going to get into how to work with Apollo server, Apollo client. We will talk about scaling GraphQL APIs with Apollo Federation. We'll talk about authorization strategies and all sorts of different things. So it's just kind of collecting the things that I've learned from teaching over the past, I don't know, three or four years GraphQL and putting it into one spot.

Drew: So it's a video course that… Is it all just self-directed, you can just work your way through at your own pace?

Eve: Yeah, exactly. So it's a big hefty course so you can work through it at your own pace. Absolutamente.

Drew: Oh, that sounds really good. And it's graphqlworkshop.com, is that right?

Eve: Graphqlworkshop.com, exactly.

Drew: And I'm looking forward to seeing that released because I think that's something that I might need. So I've been learning all about GraphQL. What have you been learning about lately?

Eve: I've also been looking into Rust lately. So I've been building a lot of Rust Hello Worlds, and figuring out what that is. I don't know if I know what that is yet, but I have been having fun tinkering around with it.

Drew: If you dear listener, would like to hear more from Eve, you can find her on Twitter where she's @eveporcello, and you can find out about her work at moonhighway.com. Her GraphQL workshop, discover your path through the GraphQL wilderness, is coming out early in 2021 and can be found at graphqlworkshop.com. Thanks for joining us today, Eve. Você tem alguma palavra de despedida?

Eve: Parting words, have fun with GraphQL, take the plunge, you'll enjoy it, and thanks so much for having me. I appreciate it.