## ESQUEÇA RestAPI - GraphQL é o futuro e aqui está o porquê você deve experimentá-lo🚀

texto

Background:

GraphQL é uma linguagem de consulta (Graph Query Language) desenvolvida pelo Facebook em 2012 e lançada publicamente em 2015.

As 3 principais características do GraphQL são:

Os clientes podem especificar exatamente quais dados precisam Facilita a agregação de dados de várias fontes Usa o sistema de tipos para descrever os dados A ideia por trás disso era ter um único endpoint ' talentoso ' que pudesse lidar com consultas complexas em vez de vários endpoints (RestAPI).

Anteriormente, tínhamos SOAP (anteriormente conhecido como Simple Object Access Protocol). Então veio o REST , que nos deu muito mais flexibilidade em relação ao SOAP, e teve um bom desempenho por algum tempo. À medida que a Web se tornava mais complexa, os aplicativos também o faziam e isso destacava algumas limitações do REST. Então o facebook desenvolveu o GraphQL em 2012 (público em 2015), o que mudou tudo. Bem, nem tudo, mas definitivamente algumas coisas para nós em 2020.

Por que consideramos GraphQL: Limitações com REST

Pontos de extremidade múltiplos: Como cada recurso é representado por um endpoint, muitos endpoints precisariam ser desenvolvidos para um grande número de recursos. Isso se torna complexo muito rapidamente e ineficiente, o que limita o potencial do seu projeto.

  1. Estrutura Fixa:

À medida que os aplicativos se tornam mais sofisticados, as respostas de estrutura fixa por meio de APIs REST resultam em busca excessiva ou insuficiente de informações. Mesmo que uma pequena quantidade de dados seja necessária de todo o objeto, não há como o REST responder sem enviar o objeto inteiro. O mesmo se aplica

Versão:

Os desenvolvedores geralmente precisam manter várias versões de APIs REST.

Então veio o GraphQL:

O GraphQL, por outro lado, permite um único endpoint 'inteligente' e estabelece uma linguagem padrão para se comunicar com esse endpoint. Não parece simples em teoria, pelo menos, ter um único endpoint inteligente em vez de vários endpoints?

texto

Os 3 blocos de construção do GraphQL são Schema , Queries e Resolvers , e você pode ler sobre eles em detalhes aqui em um artigo de Sacha Greif.

Benefícios do GraphQL:

Ponto de extremidade único: não há necessidade de construir muitos pontos de extremidade, o que é uma grande vantagem! Uma única solicitação pode fornecer todos os dados, pois as consultas, mutações e assinaturas são agrupadas e disponibilizadas para você por meio do GraphQL

texto

'Por que GraphQL é o futuro das APIs' — Leonardo Madona Obtenha apenas os dados de que você precisa: não há necessidade de buscar todos os dados para um pequeno requisito com o GraphQL, você pode solicitar apenas os dados de que precisa. Isso também ajuda com problemas de desempenho no caso de uma conexão de rede lenta.

Conclusão:

Vamos encarar. O uso do GraphQL não afetará muito a experiência geral do usuário do seu aplicativo, mas definitivamente vale a pena experimentar. Como é apenas uma especificação, pode ser usado com qualquer biblioteca ou plataforma, e nosso goto tem sido o Apollo até agora.

O GraphQL tem potencial para ser o futuro das APIs, e espero que mais desenvolvedores se interessem por ele, e consegui convencê-lo a pelo menos tentar em seu próximo projeto.

Embora alguns de vocês possam achar que a segurança é um problema com o GraphQL, pois qualquer dado pode ser solicitado, considere que você escreve seus próprios resolvedores e pode resolver quaisquer problemas de segurança.

Mas pergunto... Já que é basicamente um endpoint que serve pra tudo, como fica o cache?

Eu só brinquei com graphql, mas nunca coloquei fui muito pra frente com ele em projetos.

Muito boa a sua pergunta. Na verdade as variáveis de busca são enviadas como texto na carga POST, o texto da consulta pode ser usado como identificador e armazenado em cache na resposta. O texto da consulta pode então ser usado para buscar a resposta do cache. Mas na verdade temos soluções mais sofisticadas usando o Cliente Apollo, mas isso fica de assunto para um outro artigo.
E como será controlado o que ficará em cache ou não? Tudo em cache não é o ideal. Esperando o outro artigo.
Depende, se você ativar naquela consulta, sim, mas pode deixar que eu vou fazer um artigo legar sobre isso. S2

Mesmo que uma pequena quantidade de dados seja necessária de todo o objeto, não há como o REST responder sem enviar o objeto inteiro.[...]

Poderia elaborar melhor? Da forma que entendi, um simples DTO para cada endpoint resolve esse problema.

Você está correto em sua suposição de que um DTO (Data Transfer Object) pode ser uma maneira de resolver o problema de enviar dados desnecessários em uma resposta de uma API REST. Um DTO é um objeto que representa apenas os dados que serão enviados entre os sistemas, sem a lógica de negócio ou outras informações desnecessárias. Isso significa que é possível criar um DTO para cada endpoint da API, que inclua apenas os dados que são realmente necessários para esse endpoint. Por exemplo, se uma API tem um recurso "usuário" que é identificado por sua URL, um DTO para esse recurso pode incluir apenas os campos "nome" e "email". Isso significa que, quando o cliente faz uma requisição para essa URL, a API envia apenas os dados do nome e do email do usuário, em vez de enviar todos os dados do usuário, incluindo informações desnecessárias como senha e data de registro. Usar DTOs para filtrar os dados enviados pela API pode ser uma maneira eficiente de evitar o envio de dados desnecessários. No entanto, é importante lembrar que isso pode adicionar complexidade à API e ao seu uso, pois é necessário criar e gerenciar os DTOs para cada endpoint. Além disso, é importante garantir que os DTOs sejam atualizados sempre que os dados que precisam ser enviados mudarem, o que pode ser um trabalho adicional. Por essas razões, é importante avaliar cuidadosamente se o uso de DTOs é adequado para o seu caso de uso específico.

Acredito que a força de uma api REST é a simplicidade. Um recurso e um método.

O que vejo no dia a dia é que raramente você vai alterar o que o front consome sem ter que modificar também o backend, porque o endpoint não é só extração de dados, há algum processamento ali antes de ter o resultado pronto pro envio.

Mas que eu fiquei impressionado na primeira vez que vi o GraphQl, eu fiquei :)

Realmente, dependendo a consulta irá precisar de uma regra de negócio, validação ou até permissão, mas com o Graphql você pode colocar algumas validações nele pŕoprio e criar uma chamada para alguma função dentro de sua linguagem escolhida para o backend e realizar essas regrar lá. Leia um pouco este artigo que eu fiz sobre o Hasura https://www.tabnews.com.br/COSWEB/ja-ouviu-falar-do-hasura-gostaria-de-apresentar-esta-maravilhosa-ferramente-graphql-para-os-seus-futuros-projetos O Hasura vai mudar a sua forma de pensar com o Graphql, parar gerenciar permissões e microsserviços irá facilitar a sua vida.