Graphql – Alterando e Melhorando a Maneira como as Aplicações se Comunicam

Não levará muito tempo para que a próxima geração esteja comprando criptomoedas e verificando o saldo de sua unidade de confiança na lobby do Fortnite entre os jogos. Isso será possível graças a muitos avanços tecnológicos.

O que estamos discutindo hoje é a forma como os dados são transferidos (lidos, atualizados, adicionados/removidos) entre as aplicações e as empresas que as possuem. As interfaces de programação de aplicações (API) são a arquitetura que define essa comunicação de dados e, à medida que esses padrões se desenvolvem, os requisitos de processamento e armazenamento de dados se tornam menos árduos.

O líder no pacote em termos de “uso de recursos leve” é o GraphQL, uma linguagem de consulta e manipulação de dados de código aberto. A base de sua ecossistema é sua especificação e uma coleção de ferramentas que foi criada em torno dela.

Ele não é novo – o tempo passa rápido. O Facebook o desenvolveu em 2012 e o usou apenas internamente para o desenvolvimento de aplicativos móveis. Em 2015, ele foi “aberto” e hoje é mantido pela Fundação GraphQL (https://graphql.org/foundation/), que supervisiona seu desenvolvimento posterior.

Então, por que estou escrevendo sobre isso agora? Um caminho típico para a adoção de uma tecnologia segue as seguintes etapas: 1) hobbyistas/projetos pessoais, 2) implementação em várias linguagens, 3) implementações em startups e pequenas empresas, 4) empresas de médio porte e uso no desenvolvimento de produtos, 5) grandes corporações e gigantes da tecnologia.

O GraphQL alcançou o nível 5. Atualmente, ele é usado pelo GitHub, Pinterest, Shopify, Microsoft, para citar apenas alguns, e, mais recentemente, desde março de 2022, pela Salesforce.

Em busca de uma maneira de buscar dados de forma mais eficiente na Salesforce, encontrei sua documentação do GraphQL e comecei a ler e a procurar maneiras de implementá-lo.

Como ele difere de uma API REST tradicional?

• Uma das principais vantagens é que, com o GraphQL, você pode consultar e ter apenas os dados específicos retornados. Se você só quiser dois campos relacionados a um incidente de cliente específico, é isso que você obtém. Uma API REST tradicional retornaria todos os campos associados ao incidente. Isso poderia ser 100+ campos. Agora, você precisa fazer algo com todos os dados que você não queria inicialmente. Isso é referido como busca excessiva de dados (a busca insuficiente também é um problema).
• O acima mencionado torna o GraphQL mais rápido do que outras metodologias de API ao retornar dados.
• O GraphQL é uma linguagem fortemente tipada, o que, entre outras coisas, significa que os erros de código são detectados antes de o programa ser executado e não durante a execução.
• Um excelente conjunto de ferramentas foi construído em torno do GraphQL, o que o tornou muito amigável para os desenvolvedores.
• O GraphQL tem um único ponto de extremidade, em oposição à API REST, que tem vários pontos de extremidade. Isso significa que todos os seus dados podem ser buscados em uma única solicitação.

Dois lados da moeda: solicitante (cliente) e provedor (hospedador do GraphQL)

Eu olhei para o GraphQL até agora da perspectiva da “solicitação” de dados. Onde uma empresa como a Salesforce ou a Microsoft configurou uma API do GraphQL que você pode usar para consultar e manipular dados (ler, atualizar, adicionar).

Por exemplo, se quisermos incluir dados da Salesforce relacionados a incidentes de clientes em um portal de clientes, a maneira mais eficiente de fazer isso seria solicitar os dados exatos que estamos procurando por meio de uma consulta do GraphQL do portal para o servidor do GraphQL da Salesforce. Você obterá exatamente os dados que deseja, sem busca excessiva ou insuficiente, e, como resultado, nenhum processamento adicional ou armazenamento de dados será necessário.

O outro lado da moeda é a organização que configura a arquitetura do GraphQL para que seus clientes tenham um método eficiente para acessar os dados que desejam.

Ao construir a API do GraphQL, uma organização está criando um modelo que integra todos os seus sistemas em um modelo. Isso unifica esses sistemas e, uma vez feito, remove a complexidade do sistema subjacente. Uma vez que o trabalho esteja concluído, a consulta de dados se torna transparente por meio da API.

Quando comparo aplicações ou provedores, eu olho para as funções que eles me oferecem para obter meus dados de volta deles. Eu não quero ter que enviá-los um e-mail ou depender de relatórios pré-definidos rígidos. Eu quero ser capaz de “conectar” meus dados, consultando-os de forma flexível e oportuna. Se for reduzido a duas aplicações/provedores e eles forem semelhantes em outros pontos de comparação, e um deles oferecer uma API REST ou uma API do GraphQL, eu certamente escolherei o que tiver a API.