Introdução ao GraphQL

20/06/2021 - 4 min de leitura

GRAPHQL

Estou estudando GraphQL esses tempos e diferentemente dos posts normais que escrevo, este será teórico. Sinto que falta uma base um pouco mais teórica por aqui.

GraphQL

GraphQL é uma linguagem de especificação de queries para uma API. Foi desenvolvida originalmente pelo Facebook (não sei dizer se hoje é só o facebook que a mantém) e está sendo amplamente utilizada no mundo todo. Os frontends que eu conheço amam essa lib.

Essa linguagem é uma nova maneira de comunicação entre um server e um cliente.

O jeito tradicional

Eu disse que o GraphQL é uma nova maneira de criar uma comunicação entre um servidor e um cliente. Então qual seria o jeito mais tradicional (não chamarei de antigo)? Seria comunicação via REST API.

O jeito REST de se comunicar com certeza ainda é a forma mais utilizada no mundo e continuará sendo por muitos anos ainda. Mas, como que ela funciona, em resumo?

Jeito rest de comunicação

No jeito tradicional temos uma intenção para o que queremos fazer, depois temos uma rota + método que irão ser responsáveis por atender essa solicitação e, por fim, temos um retorno, geralmente no formato JSON, como o código abaixo:

{
  "uuid": "88ba2cea-4909-4d63-aa03-20b9ea14cdac",
  "name": "Gabriell Oliveira",
  "email": "gabriell@ohmycode.com.br",
  "settings": {
    "color_preference": "#719df1"
  }
}

Tudo beleza, tudo massa.

O problema do jeito tradicional

O REST começa a evidenciar seus problemas quando há uma necessidade de versionar a API (distribuir em api/v1/ e api/v2/ etc.). Só nisso, pode gerar uma complexidade dentro dos endpoints para serializar objetos ou não, dado a versão do recurso que o cliente está buscando.

Temos outro grandíssimo problema quando se trata de REST: o tamanho desses dados que retornamos.

Velocidade é poder. Quanto mais veloz é uma API, mais eficiente e melhor será considerada.

Pra andar de mão dadas com velocidade, temos que, além de várias outras coisas, eliminar lixos do nosso retorno. Se existe dados na response da API que o front não utiliza na construção da interface, então essa informação provavelmente não deveria mais estar naquele endpoint.

Vamos pegar o exemplo JSON acima. Imagine que aquilo seja o suficiente para montar a interface. O problema desses dados excessivos começa a ser evidenciado quando temos que, por algum motivo, em outra tela do sistema, ter que acessar o mesmo endpoint e recuperar informações que não estão originalmente listadas naquele endpoint. Por exemplo, além da cor de preferência, queremos listar informações do tema dark, de ordem de prioridades de gráficos e de notificação de usuário.

Aí que entra o dilema: fazer outro endpoint só para adicionar essas informações ou colocá-las no retorno do endpoint original?

Na primeira opção, o desenvolvedor terá trabalho de "repetir" (código ou não) as mesmas informações de um endpoint.

Já a segunda opção irá aumentar dados desnecessários para outro endpoint (o endpoint original, que só precisa da cor de preferência).

Percebe que você sai perdendo de todas as formas?

A sacada do GraphQL

Vendo esses problemas, o pessoal pensou: "por que você não retorna tudo que eu eventualmente possa precisar num único endpoint e eu dou um jeito de filtrar essas informações?"

Foi assim que nasceu o GraphQL.

Através dele podemos ter todas as informações contidas num único endpoint e o cliente/front, decidirá o que ele quer pegar desse endpoint. Grotescamente, é como se ele fizesse a query direto no BD via frontend (não é bem isso que acontece, mas serve para entendimento).

Por exemplo, se ele quisesse trazer so o nome e email do perfil do usuário:

SELECT name, email FROM profile WHERE uuid="<UUID aqui>";

Essa é mais ou menos a ideia do GraphQL. Ele trouxe o poder do front decidir quais informações de um endpoint ele quer trazer.

Olha um exemplo de query no GraphQL (acabei de perceceber que não tenho highligths de graphql):

Exemplo de query com GraphQL

No exemplo acima de um blog, se fosse escrito uma API, a página inicial não necessita ter o conteúdo do post. Só bastaria o título, data de publicação, resumo e uma foto, se necessário.

Dessa forma aí, o front escolheu o que queria trazer dos posts. Se ele quisesse só o título, só teria o title dentro de allPosts.

Percebe que dessa maneira ficou mais fácil dar manutenção numa API e não precisa mais ficar versionando-a?

Muito massa.

Conceitos do GraphQL

Esses são os conceitos que você tem que entender e trabalhar, para aprender o GraphQL:

  • Types (representação de algum recurso que você quer consumir. Por exemplo, PostType)
  • Queries (pega os dados da API)
  • Mutations (quem faz inserção, update e delete. Em resumo, quem faz as manipulações de dados)
  • Subscriptions (uma killer feature. É responsável por ficar escutando as modificações de algum model. Quando há a mudança, ela automaticamente recebe um evento de quem mudou. Funciona com WebSocket por debaixo dos panos)

Conclusão

GraphQL é bem mais poderoso e cheio de features novas que o tradicional REST. Porém, ainda é muito mais fácil implementar uma API em REST do que em GraphQL.

Ao meu ver, se o projeto for pequeno, é melhor e mais fácil implementar uma API REST. GraphQL é ótimo, mas ainda vejo mais para projetos grandes. O que você acha?

Estou bem animado com o GraphQL e quero botar alguma coisa online em breve. Também documentarei meus aprendizados em breve no blog, afim de concretizar mais o aprendizado.

Futuro promissor de stack: NextJS + Django + GraphQL ❤️

Foto da capa by JJ Ying on Unsplash

Compartilhe

Twitter