Cinco razões a favor e contra o GraphQL

O GraphQL está a polarizar nos círculos de desenvolvimento. Damos uma olhada aos prós e contras da alternativa REST.

Por Peter Wayner

Se a sua equipe está atualmente a desenvolver uma API, há uma boa hipótese de que a introdução do GraphQL esteja nas placas. Se é um programador que pretende consultar bases de dados (próxima geração), é muito provável que tenha de enviar a sua consulta em GraphQL. A linguagem de consulta é uma das opções mais quentes para a organização de pesquisas de dados.

O GraphQL foi desenvolvido pelo Facebook em 2012 – como uma forma concisa e poderosa de procurar estruturas de dados no seu gráfico social maciço. Em 2015, a empresa começou a utilizar o GraphQL de fonte aberta – entregando o controlo à Fundação GraphQL sem fins lucrativos em 2019. Entretanto, várias empresas estão a construir serviços de pesquisa de dados em GraphQL.

O GraphQL também é a escolha certa para o seu próximo projeto? Para ajudar a decidir, reunimos cinco boas razões a favor e contra o GraphQL.

Cinco razões a favor do GraphQL

1. O GraphQL é simples

Os programadores que precisam de procurar dados adoram a forma compacta do GraphQL – especialmente aqueles que trabalham no front end e estão continuamente a acrescentar novas características e dados às interfaces de usuário. A sintaxe fornece uma das formas mais simples de obter respostas a partir de estruturas de dados complexas, por vezes aninhadas. Isto torna mais fácil a consulta de mais dados sem ter de reescrever o código.

O mecanismo de consulta do GraphQL foi também concebido para ocultar grande parte da complexidade das consultas tradicionais. Alguns programadores lutam com as junções internas e externas em consultas de bases de dados, outros estão cansados de enviar três ou quatro consultas para encontrar os dados em três ou quatro bases de dados diferentes em todo o mundo. O GraphQL esconde toda esta complexidade.

2. GraphQL está a evoluir

O GraphQL é ainda relativamente jovem e está a ser diligentemente desenvolvido. Isto também significa que são acrescentadas frequentemente novas características. Por exemplo, o registro da versão do GraphQL de outubro de 2021 contém mais de 100 alterações e melhoramentos.

3. GraphQL tem potência

Os programadores que desejam simplesmente recuperar dados de uma API, em particular, ficam regularmente surpreendidos com as possibilidades de consulta que o GraphQL oferece. Basta alguns toques de tecla para alterar uma consulta. No entanto, o verdadeiro poder do GraphQL reside debaixo do capô: um backend inteligente assegura que a informação é recuperada da melhor maneira possível. As rotinas de otimização podem analisar estatisticamente uma consulta e fazer previsões relativamente precisas, que o backend pode, por sua vez, utilizar para escolher o caminho mais rápido.

GraphQL pode também montar consultas fixas e criar uma lista de objetos em cache para aumentar a velocidade.

4. Dados para as pessoas

Os dados só são bons se forem utilizados. Para o fazer, é necessário chegar às pessoas na “base”. É por isso que os programadores front-end se concentram na criação de belas interfaces para as massas. Se o GraphQL facilita a vida a estes criadores, eles podem, por sua vez, facilitar a vida a todos os outros. A criação de um mecanismo aberto e acessível de recuperação de dados pode também levar a um renascimento da utilização de dados em toda a empresa.

5. Supergráficos como ponte entre os seus backends.

Os aficionados do GraphQL gostam de falar sobre a combinação de todos os dados de uma organização num grande supergráfico. Para tal, pegam em vários sistemas legados e acrescentam alguns novos campos para criar uma única fonte de verdade. Qualquer equipa de armazenamento de dados é capaz de criar um portal que contenha todas as pérolas.

LEIA Melhores práticas em modelagem de banco de dados e SQL

Cinco razões contra o GraphQL

1. Torna as consultas perigosamente fáceis

Muitos programadores consideram conveniente que o backend GraphQL esconda a complexidade das consultas. No entanto, estes mesmos criadores ficam surpreendidos quando o resultado abranda por um fator de cinco, dez ou mesmo cem. Cada nova consulta acrescenta aos processos e envia o backend no seu caminho. A carga do servidor cresce – e os administradores da base de dados estão a aumentar sua infraestrutura para suportar.

E ainda fica pior: algumas implementações de clouds são faturadas pela carga de trabalho. Assim, uma consulta abrangente pode acabar numa conta de nuvem abrangente no final do mês.

2. A versão API é confusa

Embora muitas equipes sejam capazes de melhorar e ampliar constantemente as suas  API de GraphQL – nem todas gerem isto de uma forma elegante. Alguns querem injetar respostas “nulas” para campos que desapareceram. Outros inserem dados fictícios. Alguns adicionam etiquetas de versão explícitas ao caminho (como “/v3/dados”) e criam uma única árvore com diferentes versões em diferentes ramos. Os criadores que executam a API podem encontrar-se a adicionar informação mas não a remover – e a ter de suportar pedidos de campos só porque alguém, algures, ainda a está a pedir.

3. O poder pode ser perigoso

Todos adoram o poder até que este liberte forças para além do seu controle. No caso do GraphQL, parece que fazer uma consulta consome demasiada largura de banda, recursos informáticos – ou ambos. Mas existem outros perigos: A informação que é suposta ser mantida em segredo poderia ser divulgada – ou atualizações desencadeadas para dados que é suposto permanecerem inalterados.

4. Nenhum esquema

Uma queixa comum dos criadores: não existe um mapa ou esquema autoexplicativo para os guiar através da árvore de dados GraphQL. A corda certa pode estar lá, mas em que ramo? Pelo menos uma base de dados relacional organiza tudo em tabelas bastante retangulares cujas colunas são claramente definidas e razoavelmente consistentes. Isto pode ser devido a uma estrutura complexa de dados gráficos e não à própria linguagem, mas não torna a vida mais fácil para os programadores.

5. Os supergráficos só parecem simples

A visão de criar um super gráfico que unifica todos os seus dados numa grande interface raramente é tão simples como parece. equipes inteiras de dados podem abarrotar os seus cérebros sobre os detalhes de tal integração durante longos períodos de tempo. Os promotores, por exemplo, queixam-se frequentemente de que os tipos de sistemas dos diferentes ramos não correspondem. Um ramo pode armazenar dados em formato de texto enquanto outro utiliza uma norma numérica.

Se a Supergraph unifica os dados armazenados em diferentes países ou continentes, é provável que tenha de gerir filiais em diferentes línguas. É fácil fundir diferentes fontes de dados para parecerem uma única interface – mas na realidade unificar os dados é muito mais complexo.

GraphQL – sim ou não?

Os programadores e equipes que considerem GraphQL devem estar preparados para refletir sobre as especificidades do GraphQL. É tentador pensar no GraphQL como uma solução fácil – mas isso poderia voltar a assombrá-lo sob a forma de contas sem fundo e dores de cabeça de segurança.

FONTE: ComputerWorld

LEIA TAMBÉM: