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?
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):
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 ❤️