React: utilizando GraphQL para integração de dados

Conhecendo o GraphQL - Apresentação

Apresentando o instrutor e o curso

Olá, estudante da Alura! Meu nome é Pedro, sou instrutor de front-end na Alura.

Audiodescrição: Pedro é um homem branco, com cabelos escuros e barba escura. Ele veste roupas pretas em um ambiente iluminado pelas cores rosa e azul.

Seja bem-vindo a mais um curso de React na nossa plataforma da Alura. Neste curso, vamos explorar uma forma mais simples de fazer requisições para um endpoint, sem a necessidade de nos preocuparmos com várias URLs e parâmetros. Além disso, vamos aprender a personalizar a resposta que o back-end retorna para nós.

Introduzindo o GraphQL e suas vantagens

Muitas vezes, nos deparamos com situações em que recebemos informações desnecessárias do back-end para nossa aplicação. Isso é algo comum no dia a dia de trabalho, especialmente em áreas como finanças e bancos, onde a segurança das informações é crucial.

Estou aqui para informar que existe uma maneira de contornar esse problema, e vou apresentar a vocês o GraphQL.

Comparando GraphQL e REST

Vamos entender como o GraphQL funciona, qual é sua utilidade e como ele se diferencia do REST, um padrão comum de chamadas. Caso não conheçam o REST, não há problema, pois vamos abordar os principais pontos e realizar uma comparação. Temos um material de qualidade preparado para mergulharmos nesse universo do GraphQL.

Requisitos e estrutura do curso

Para acompanharmos juntos, é necessário ter alguns conhecimentos prévios sobre o funcionamento do React, gerenciamento de estado local, funcionamento de hooks, entre outros aspectos do React. Não se preocupem, pois vamos avançar passo a passo, compreendendo cada etapa até chegarmos ao final.

Explorando a plataforma Runner Circle

Este curso está repleto de informações úteis e divertidas. Utilizaremos a plataforma Runner Circle, onde podemos criar uma conta, fazer login e explorar funcionalidades como o feed de treinos, deletar treinos, criar novas postagens, editar o perfil, entre outras. Vamos focar principalmente na parte do feed, com filtros e tudo mais, até deixarmos nosso projeto funcionando 100% com a integração do GraphQL.

Convidando para a jornada de aprendizado

Preparem-se, peguem suas águas e nos encontramos em breve para iniciarmos a descoberta deste universo com o GraphQL. Espero vocês do outro lado.

Conhecendo o GraphQL - Conhecendo o GraphQL

Discutindo a otimização de requisições para APIs

Vamos discutir como podemos otimizar as requisições que fazemos do lado do cliente para uma API. Atualmente, quando trabalhamos em um projeto que faz requisições para um servidor, é comum utilizarmos o padrão REST. Esse padrão será discutido em breve, mas, para entendermos, normalmente recebemos informações da API em um conjunto de dados.

Vamos imaginar uma situação: ao pedir um combo em uma rede de fast-food, recebemos um sanduíche, batata e refrigerante, mesmo que desejemos apenas o sanduíche. No desenvolvimento de software, ao fazer uma requisição para uma API de usuários, recebemos um conjunto de dados que inclui, além do nome do usuário, um ID que talvez não utilizemos, e-mail, endereço completo, entre outros. Muitas vezes, recebemos mais informações do que precisamos.

Explorando a personalização de dados com GraphQL

E se pudéssemos receber apenas os dados necessários para uma determinada ocasião? Por exemplo, no caso do Runner Circle, queremos exibir informações dos treinos de outros usuários no feed, sem receber dados desnecessários como e-mail ou última vez que acessaram. Desejamos apenas as informações de treino para reduzir a quantidade de dados trafegando entre o cliente e o back-end.

Será que conseguimos fazer isso com o padrão REST? Infelizmente, com REST, estamos limitados a esse conjunto de informações retornadas. Para resolver isso, vamos estudar o GraphQL, que permite romper essas barreiras e retornar apenas as informações desejadas do banco de dados.

Evitando problemas de overfetching e underfetching com GraphQL

Usando a analogia do pedido de lanche, com GraphQL, podemos personalizar nosso pedido de informações para o back-end. Podemos optar por receber apenas o que desejamos, evitando sobrecarga de informações entre o cliente e o back-end. Isso é importante, especialmente em tópicos avançados de segurança, para filtrar dados sensíveis e evitar o retorno desnecessário de informações.

O GraphQL nos ajuda a evitar o overfetching (requisições desnecessárias com muitas informações) e o underfetching (requisições insuficientes que exigem novas requisições). Ele proporciona um equilíbrio perfeito no número de requisições feitas do lado do cliente para retornar informações do banco de dados. Além disso, facilita a evolução do back-end sem a necessidade de versionar a API.

Facilitando a evolução de APIs com GraphQL

Em cenários reais, quando evoluímos back-ends e APIs, dados que podem causar problemas no front-end atual exigem a criação de uma nova versão para evitar problemas. Com GraphQL, podemos evitar essa necessidade, mantendo a integridade e eficiência das requisições.

Com o GraphQL, ao pegarmos somente as informações que desejamos, evitamos muitos problemas. Isso ocorre porque, independentemente de um campo novo ter sido adicionado ou outro removido, é fácil adaptar a chamada para esse novo campo ou informação. Não precisamos versionar nossa API, pois temos certeza de que, do lado do cliente que consome essas APIs, teremos total controle. Assim, não será um grande problema para nós enquanto pessoas desenvolvedoras. Isso facilita muito as integrações com APIs legadas, pois, ao utilizarmos o GraphQL, não nos preocupamos com o versionamento das APIs. Se uma API está depreciada em nosso projeto, por exemplo, se a API está na versão 3 e, por algum motivo, precisamos usar a v1 em algum momento, não teremos penalizações quanto a esse uso. Pegaremos somente as informações necessárias, e um campo depreciado ou removido pode não ser importante, não afetando a forma como utilizamos as chamadas para API.

Considerando as desvantagens do GraphQL

Entretanto, nem tudo são vantagens. Existem desvantagens na utilização do GraphQL. O primeiro ponto é a curva de aprendizado, pois, ao invés de consumir todas as informações, consumimos filtrando o que queremos. Para utilizar o GraphQL e sua forma de comunicação, precisamos aprender alguns detalhes, pois ele oferece capacidades adicionais em relação ao padrão REST. Estamos aqui para, juntos, subirmos essa escada do aprendizado.

O GraphQL gera um pouco mais de complexidade do lado do servidor. Se estamos aliviando o lado do cliente, ou seja, nosso lado enquanto front-end, algum lado desbalanceará e recairá sobre o servidor. Precisamos entender como funcionam essas chamadas e quais verbos são utilizados no GraphQL, já que saímos do padrão de GET, PUT, DELETE, POST, etc., do REST. Além disso, lidar com o cache é mais difícil. Não é que seja difícil de fazer, mas foge dos padrões com os quais estamos acostumados no REST, que já possui um cache embutido nas chamadas. Com o GraphQL, precisamos ser mais explícitos. Vamos ver isso na prática, com uma configuração especialmente pensada para trabalhar com cache.

Comparando REST e GraphQL

Comparando REST e GraphQL, no quesito requisição e resposta, o REST trabalha com múltiplos endpoints e a resposta é fixa, mudando apenas se houver uma nova versão da API. No GraphQL, temos um único endpoint e montamos nossa requisição e resposta de forma personalizada. Em termos de flexibilidade, no REST a resposta é definida pelo servidor, enquanto no GraphQL é personalizada e flexível conforme a necessidade do cliente.

Em relação à performance, o REST facilita o cache, enquanto no GraphQL, embora reduza múltiplas requisições, o cache é mais manual. No REST, o versionamento ocorre quando há diferenças na resposta, enquanto no GraphQL, a compatibilidade é mantida e apenas campos são depreciados. Isso não interfere no restante da API, desde que façamos a alteração necessária ao depreciação de campo.

Concluindo a comparação entre REST e GraphQL

Concluindo, no GraphQL temos dados variados, enquanto no REST os dados são uniformes. No GraphQL, múltiplas fontes de dados são possíveis, mas no REST, os requisitos são sempre os mesmos. O GraphQL permite que clientes diferentes utilizem-no sem problemas, enquanto no REST o uso de cache é amplo e embutido, necessitando de manutenção manual no GraphQL.

Vamos entender mais sobre como funcionam REST e GraphQL na prática, antes de entrarmos em detalhes sobre como fazer uma query e buscas, trazendo para o padrão que entendemos do REST e explorando o playground do GraphQL. Vejo vocês na sequência para continuarmos aprendendo sobre a utilização de GraphQL em projetos com React.

Conhecendo o GraphQL - Configurando o Postman

Introduzindo o padrão REST e GraphQL

Chegou o momento de vermos na prática como funciona o padrão REST, que atualmente está sendo adotado no projeto do Runner Circle. Vamos fazer uma comparação para entender como funciona o GraphQL e como podemos aproveitar essas informações valiosas que acabamos de aprender. Vamos compreender como a arquitetura do GraphQL opera, retornando resultados customizados, ou seja, da forma que precisarmos e quisermos. Precisamos ver isso acontecendo na prática.

Estamos com o editor de texto aberto, rodando o projeto do React Runner Circle. No lado direito, o projeto está em execução com o comando npm run dev, e no lado esquerdo, o servidor está rodando. Vamos pausar ambas as execuções e fechar a que está rodando o projeto, pois, por enquanto, vamos focar apenas no lado do servidor. Para rodar o servidor, utilizaremos o comando npm run server:json-server.

npm run server:json-server

Configurando o servidor local

Neste projeto, estamos utilizando um servidor local, onde, na raiz do projeto, há uma pasta chamada "database". Dentro dessa pasta, temos dois arquivos: o arquivo JSON que utilizaremos para o nosso servidor, chamado json-graphql-server.js, e o json-server.json, que será o arquivo para o nosso servidor JSON que está rodando no momento.

Assim que executamos o comando npm run server:json-server, o arquivo é executado na porta 3001, e ele exibe no terminal que podemos acessar pela web para ver as informações.

> react-runner-circle@0.1.0 server:json-server
> json-server --watch database/json-server.json --port 3001

Também temos disponíveis os endpoints localhost:3001/user e localhost:3001/feed.

Endpoints:
http://localhost:3001/user
http://localhost:3001/feed

Explorando os endpoints REST

É através desses dois endpoints que, dentro do padrão REST, faremos as requisições utilizando os verbos GET, PUT, POST e DELETE, que já conhecemos em relação à utilização de HTTP com o padrão REST de funcionamento. Com o GraphQL, será um pouco diferente, mas vamos entender como está funcionando.

Para isso, temos o Postman instalado na máquina. Vamos abrir o site do Postman. Em uma nova aba do navegador, digitamos "Postman" na pesquisa do Google, que retorna o primeiro link, www.postman.com. Ao acessar essa página, no canto esquerdo, no final da aba onde temos a criação de time, parte de Workspaces e tudo mais, a última opção aparece como "Download Desktop App". Para utilizar o Postman e verificar as requisições locais, como é o caso do nosso servidor que rodará tanto o padrão REST quanto o GraphQL, precisamos fazer o download da aplicação do Postman.

Outra forma de acessar a API é abrindo uma nova aba no navegador e digitando localhost:3001.

localhost:3001

Dessa forma, conseguimos acessar a nossa API. Temos as informações do localhost:3001/user, por exemplo, e, ao voltar uma página, se clicarmos na opção "feed", temos o retorno localhost:3001/feed.

http://localhost:3001/user
http://localhost:3001/feed

Analisando a eficiência do padrão REST

Esse é o funcionamento da API com REST. Temos um GET que retorna todas as informações, e se quisermos, por exemplo, pegar as informações do ID 3, que é da usuária Marina Santos, que fez uma corrida rápida no final do dia, precisamos acessar localhost:3001/feed/3, que é o ID desse post no feed.

http://localhost:3001/feed/3

Com isso, temos o padrão de funcionamento do REST. Não conseguimos selecionar quais informações queremos utilizar. Por exemplo, ao selecionar o ID 3, temos as informações de usuário, com o nome e o ID da usuária, o tempo que ela gastou na atividade, e informações de distância, calorias e batimentos cardíacos. Temos a descrição da atividade realizada e um timestamp. No entanto, percebemos que são informações que talvez não precisemos do lado do cliente. Por exemplo, o timestamp não será utilizado, o ID da usuária também não, e o ID da postagem não será necessário. Precisamos apenas do nome, do tempo gasto na atividade para mostrar no feed, e das informações de distância, calorias, batimentos cardíacos e descrição. Isso é apenas uma postagem, mas se tivermos milhares, imagine quantas informações estamos desperdiçando e retornando desnecessariamente do lado do servidor, que poderíamos simplesmente filtrar e ter de forma reduzida.

Utilizando o Postman para requisições REST

Vimos o funcionamento do lado da web sem utilizar o Postman. Após efetuar o download do Postman, clicando e voltando para a documentação do postman.com, clicando na última opção da lateral esquerda, fazemos o download da aplicação. No nosso caso, já temos o Postman baixado, pois estamos utilizando o macOS. Se estiver utilizando Mac, Linux ou Windows, ele também tem suporte. É possível rodá-lo na web, mas, rodando na web, não conseguimos fazer requisições locais, como é o caso que precisamos aqui para seguir investigando as nossas APIs.

Após realizar o download e a instalação, será necessário criar uma conta. Já temos uma conta criada, mas para criar uma conta é muito simples. Basta acessar o site do postman.com, no topo da aplicação, no canto superior direito, ao lado do botão de upgrade, há um símbolo que, no nosso caso, mostra a conta, e-mail e informações. Será o mesmo botão utilizado para criar uma nova conta. Basta seguir o processo normal de criação de conta, sem mistério. É possível até vincular com o GitHub ou com o próprio Gmail, pois ele tem essas integrações, facilitando a criação de conta.

Explorando métodos HTTP no Postman

Com o software instalado, conseguimos abri-lo no desktop, no caso, em um Mac. Ao abrir uma nova requisição, observamos que ele já tem o verbo selecionado, que é o GET. Temos também os métodos POST, PUT, PATCH, DELETE, HEAD e OPTIONS, que são específicos para determinadas informações e não são utilizados com tanta frequência, portanto, não entraremos em detalhes sobre eles.

O método GET é utilizado para retornar informações, enquanto o POST é usado para enviar dados ao servidor. Não é necessariamente um dado de criação, pois podemos utilizar o POST também para edição. Já o PUT e o PATCH são específicos para atualizações; não conseguimos criar dados no servidor, ou seja, no banco de dados, utilizando PUT e PATCH. Para isso, precisamos do POST. O DELETE é utilizado para remoção de dados. O método HEAD retorna as informações do cabeçalho da requisição, que sempre contém informações específicas, como tipo de conteúdo, host, certificados de segurança, entre outros. O OPTIONS fornece informações adicionais sobre a requisição, que não fazem parte do cabeçalho nem do corpo da requisição.

Realizando requisições GET no Postman

Selecionando o padrão GET, digitamos no campo de URL localhost:3001/ e clicamos no botão SEND, localizado no canto direito da aplicação Postman. Observamos que ele retornou um HTML, exibindo as informações do localhost:3001 quando acessamos apenas a barra. Trata-se de uma página web com DOCS SPONSOR, USER e FEED. No Postman, há uma lista com a tag ul, e dentro dela, o primeiro índice é USER e o segundo é FEED, ou seja, são as duas APIs disponíveis no localhost.

localhost:3001

Ao voltar para o verbo GET, onde digitamos a URL, e passar, por exemplo, /user, clicamos em SEND e ele retorna os dados do usuário, incluindo nome, nome de usuário, e-mail, senha (aberta, pois estamos utilizando uma API local sem validação), telefone, cidade, estado e biografia.

localhost:3001/user

Se tentarmos adicionar mais uma informação ao lado de USER, como /1, ele retorna NOT FOUND, pois o usuário é único nessa aplicação e não faz distinção por ID.

localhost:3001/user/1

Explorando requisições no endpoint FEED

Se trocarmos USER por FEED e clicarmos em SEND, percebemos que ele retorna uma lista, ou seja, um array de postagens no FEED. Cada post possui um ID e o ID do usuário que fez a postagem. Podemos buscar pelo ID da postagem, por exemplo, /feed/1, que retorna apenas a postagem de Ana Silva Correia.

localhost:3001/feed
localhost:3001/feed/1

Para buscar pelo usuário, precisaríamos passar o ID do usuário, mas essa busca é mais complexa e não basta digitar a informação na URL. É necessário seguir um padrão, passando o ID da primeira postagem e mais informações de filtragem.

localhost:3001/feed?user.id=1

Isso mostra a complexidade de filtrar informações em uma pesquisa utilizando o padrão REST.

Realizando operações PUT e PATCH no Postman

Vimos como funciona o GET. Para realizar um POST, PUT, PATCH ou DELETE, eles serão baseados em ID. Se quisermos alterar as informações do usuário, trocamos o verbo GET por PUT, copiamos as informações da resposta na aba inferior e, na aba superior, clicamos em BODY, selecionamos RAW, colamos a resposta e alteramos, por exemplo, o nome para Pedro Melo Corredor.

{
    "name": "Pedro Melo Corredor",
    "username": "pedomello",
    "email": "pedro.mello@teste.com",
    "password": "123123",
    "phone": "11999999999",
    "city": "Sao Paulo",
    "state": "SP",
    "bio": "Adoro correr pela manha!"
}

Com o PUT selecionado, clicamos em SEND e a resposta é alterada para Pedro Melo Corredor, demonstrando uma alteração de dados utilizando o padrão REST com o verbo PUT. Podemos também utilizar PATCH para isso. O PATCH devolve o nome do item e as informações, que são as mesmas. Com o POST, se clicarmos em SEND, ele retorna NOT FOUND, pois precisaríamos passar um ID, e como não estamos utilizando ID, não conseguimos fazer alterações. No PUT, se trocarmos para o nome original, sem "Corredor", e clicarmos em SEND, ele atualiza novamente o nome.

{
    "name": "Pedro Melo",
    "username": "pedomello",
    "email": "pedro.mello@teste.com",
    "password": "123123",
    "phone": "11999999999",
    "city": "Sao Paulo",
    "state": "SP",
    "bio": "Adoro correr pela manha!"
}

Concluindo a exploração do padrão REST

No GET, removendo a barra, verificamos que não estamos duplicando informações e recebemos a resposta com as informações corretas: nome, nome de usuário, e-mail, tudo funcionando perfeitamente.

Vimos, de maneira geral, como funciona nossa aplicação utilizando o padrão REST. Agora, vamos ver na prática como fazer isso com GraphQL, utilizando as mesmas informações, e quais são as diferenças em relação ao REST. Nos vemos na sequência para explorar o funcionamento do GraphQL e comparar com a facilidade que ele oferece em relação ao REST.

Sobre o curso React: utilizando GraphQL para integração de dados

O curso React: utilizando GraphQL para integração de dados possui 223 minutos de vídeos, em um total de 43 atividades. Gostou? Conheça nossos outros cursos de React em Front-end, ou leia nossos artigos de Front-end.

Matricule-se e comece a estudar com a gente hoje! Conheça outros tópicos abordados durante o curso:

• Conhecendo o GraphQL
• Configurando Apollo Client no React
• Implementando queries com variáveis e filtros
• Utilizando mutations
• Gerenciando cache e exclusão de dados