Imagine uma tela que precisa exibir apenas o nome e a foto de um usuário.
Ao consultar a API, ela recebe também endereço, telefone, data de nascimento e vários outros campos que não serão utilizados.
Agora pense em outra tela que precisa dos dados desse usuário e dos títulos dos seus últimos artigos. Dependendo de como a API foi construída, isso pode exigir várias requisições.
GraphQL permite que o cliente descreva os dados de que precisa. Essa é uma das suas principais características.
O que é GraphQL?
GraphQL é uma linguagem de consulta para APIs, acompanhada de um mecanismo para executar essas consultas.
O servidor define os tipos, campos e operações disponíveis em um contrato chamado schema. Dentro desse contrato, o cliente escolhe quais campos deseja receber.
Por exemplo, uma consulta poderia ser:
query {
usuario(id: "1") {
nome
foto
}
}
E a resposta:
{
"data": {
"usuario": {
"nome": "Bruno",
"foto": "https://exemplo.com/foto.png"
}
}
}
A estrutura da resposta acompanha os campos solicitados. Se outra tela precisar de mais informações, poderá pedi-las, desde que estejam disponíveis no schema e seu acesso seja permitido.
Por que isso é importante?
Uma mesma API pode atender um aplicativo, um site e um painel administrativo. Cada um pode precisar de uma combinação diferente de dados.
Com GraphQL, esses clientes conseguem adaptar suas consultas às necessidades de cada tela. Também é possível consultar dados relacionados em uma única requisição, como um usuário e seus artigos. Isso pode reduzir tanto o excesso de dados na resposta quanto a quantidade de chamadas necessárias.
O ganho está na flexibilidade de consumir a API.
E os cuidados?
Essa flexibilidade também exige controle. Uma consulta pode pedir muitos dados e percorrer várias relações, gerando um custo alto para o servidor.
Por isso, uma implementação precisa cuidar de autorização, paginação e limites para as consultas. Receber apenas os campos solicitados não garante, por si só, uma execução barata no backend.
Por onde começar?
Para um primeiro contato, vale guardar esta ideia:
O servidor define o que pode ser consultado, e o cliente descreve o que precisa receber.
A partir daí, o próximo passo é entender como o schema organiza esses dados e como as funções chamadas resolvers buscam as informações para montar a resposta.
Top comments (0)