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: