GraphQL vs REST: tudo o que você precisa saber

Pode ser difícil escolher as tecnologias que serão incluídas na pilha de tecnologia do seu próximo projeto. Em muitos casos - e especialmente quando se trata de escolher entre APIs GraphQL e RESTful - trata-se de escolher a próxima melhor arquitetura de design de API.

Existem quatro maneiras significativas de construir APIs: SOAP, GRPC, REST e GraphQL. Muitas vezes limitamos nossas mentes ao REST e GraphQL sempre que queremos construir APIs. Isso ocorre porque o REST mudou as formas tradicionais de construção de APIs com SOAP e GRPC.

O GraphQL é amplamente marcado como um REST melhor porque representa uma maneira melhor de criar APIs. Muitos desenvolvedores acreditam que o GraphQL substituirá o REST. Muitos outros já descobriram que o GraphQL ajuda a resolver alguns desafios comuns que os desenvolvedores enfrentam ao criar APIs REST.

Esses dois métodos de construção de APIs são totalmente diferentes. Na prática, essas tecnologias funcionam enviando uma solicitação HTTP e recebendo o resultado. Ambos têm seus prós e contras e, neste artigo, discutiremos amplamente essas duas grandes tecnologias que mudaram a maneira como desenvolvemos e dimensionamos APIs.

Antes de nos aprofundarmos nos detalhes, vamos primeiro explorar o significado das APIs GraphQL e RESTful.

O que é GraphQL?

GraphQL é uma linguagem de consulta de API, bem como um tempo de execução para responder a essas consultas com dados existentes. Ele também vem equipado com ferramentas poderosas para lidar até mesmo com as consultas mais complexas.

O recurso central do GraphQL é sua capacidade de solicitar e receber apenas os dados específicos solicitados - nada mais. Isso torna muito mais simples dimensionar suas APIs junto com seu aplicativo.

A parte mais empolgante do GraphQL é sua capacidade de fornecer todos os dados em um endpoint.

O diagrama acima é uma representação típica da arquitetura GraphQL. Os clientes fazem solicitações de diferentes dispositivos e o GraphQL lida com suas solicitações e retorna apenas os dados solicitados. Isso resolve perfeitamente o problema de over-fetching e under-fetching em APIs RESTful.

No exemplo acima, mostramos um playground GraphQL e como você pode consultar dados com um único endpoint. Na parte superior está o endpoint da API, à esquerda está a consulta que solicita nomes de continentes e, por último, à direita, respondemos à consulta que solicitamos.

O GraphQL foi criado pelo Facebook com o objetivo principal de resolver a experiência do desenvolvedor de aplicativos móveis enquanto trabalha com APIs REST. Desde que sua primeira versão de código aberto foi lançada em 2015, o GraphQL experimentou um enorme crescimento devido à adoção da tecnologia por grandes players do setor de tecnologia.

Empresas que usam GraphQL

Abaixo está uma lista de apenas algumas das empresas e aplicativos que usam GraphQL ativamente em seus servidores.

Facebook

O Facebook criou o GraphQL e o usa em produção para impulsionar seus aplicativos móveis desde 2012. A empresa multibilionária de rede social abriu a especificação GraphQL em 2015, tornando-a acessível em muitos ambientes e para equipes de todos os tamanhos .

GitHubGenericName

O GitHub também anuncia o uso do GraphQL fornecendo uma API GraphQL para criar integrações, recuperar dados e automatizar seus fluxos de trabalho usando a API GraphQL do GitHub. A API do GitHub GraphQL oferece consultas mais precisas e flexíveis do que a API REST do GitHub.

Pinterest

O Pinterest também é um dos primeiros a adotar o GraphQL. A gigante do compartilhamento de fotos discutiu publicamente sua exploração inicial do GraphQL e como eles usam a tecnologia GraphQL que alimenta sua empresa de bilhões de dólares.

Muitas outras empresas de bilhões de dólares, como Intuit, Shopify, Coursera e Airbnb, potencializam seus aplicativos com o GraphQL. E essa ampla preferência pelo REST só continua a crescer.

O que é API RESTful?

REST significa “Representational State Transfer”, que é um estilo de arquitetura de software para sistemas de hipermídia distribuídos. Ele define princípios e restrições para a troca de recursos entre o servidor e os clientes.

Se esses princípios forem seguidos em uma API, o aplicativo dessa API será chamado de "RESTful". A API REST do WordPress é um excelente exemplo disso.

Abaixo estão alguns dos princípios e restrições que uma API deve atender para ser chamada de API Restful:

• Desacoplamento cliente-servidor: Os clientes (frontend) e o servidor (backend) são completamente separados e só podem se comunicar através dos endpoints.
• Interface uniforme: os dados vistos na interface são idênticos em todos os dispositivos.
• Stateless: O servidor não lembra se a solicitação atual está sendo feita pela primeira vez ou não. Cada vez que uma solicitação é feita, ela precisa incluir todas as informações necessárias para processá-la do zero.
• Capacidade de cache : o armazenamento em cache e sessão é permitido, mas eles devem ser configurados para permitir que os usuários finais desativem o cache de dados.
• Arquitetura de sistema em camadas: as APIs devem ser projetadas para que nem o cliente nem o servidor possam dizer se estão se comunicando diretamente ou por meio de um intermediário.

O diagrama abaixo é da arquitetura REST básica. Ele mostra como as solicitações e respostas são normalmente tratadas.

Benefícios do GraphQL

Abaixo estão alguns benefícios do uso do GraphQL, que ilustram por que ele é mais do que suficiente para criar o próximo aplicativo de um bilhão de dólares.

Buscando dados por meio de um único endpoint de API

A principal vantagem do GraphQL é sua capacidade de acessar qualquer ou todos os pontos de dados por meio de um único endpoint de API.

Um dos problemas mais comuns com APIs RESTful é ter muitos endpoints para acessar informações. No GraphQL, você tem apenas um único endpoint, portanto, não precisa enviar várias solicitações para recuperar informações diferentes sobre um objeto.

O diagrama abaixo mostra um exemplo claro de recuperação de recursos usando a API RESTful e o GraphQL. Você pode ver que há apenas um endpoint para acessar o recurso no servidor GraphQL, enquanto vários endpoints de API são necessários para acessar diferentes recursos na API RESTful.

Sem busca excessiva ou insuficiente

A questão do excesso ou falta de busca é um problema conhecido com APIs RESTful. É quando os clientes baixam dados acessando pontos de extremidade que retornam estruturas de dados fixas ou recuperam mais ou menos do que esperavam.

A busca excessiva resulta no recebimento da solicitação – ou “busca” – mais dados do que o exigido por uma determinada solicitação. Imagine que você está buscando todos os usuários em uma tabela com a intenção de exibir seus nomes de usuário em sua página inicial. Nesse caso, a busca excessiva retornará todos os dados de cada usuário, incluindo (mas não apenas) o nome.

A busca insuficiente é comparativamente rara, mas acontece quando o endpoint específico não fornece todas as informações solicitadas. O cliente precisará fazer solicitações adicionais para acessar as outras informações conforme necessário.

O GraphQL resolve com eficiência o problema de over-fetching ou under-fetching, capturando o recurso exato que o cliente solicitou sem nenhum detalhe extra.

Melhor manuseio de sistemas complexos e microsserviços

O GraphQL pode unificar e ocultar a complexidade de vários sistemas integrados.

Por exemplo, digamos que queremos migrar de um aplicativo de back-end monolítico para uma arquitetura de microsserviço. A API GraphQL ajuda a lidar com a comunicação entre vários microsserviços, mesclando-os em um esquema GraphQL.

Depois que esses esquemas são definidos, tanto o front-end quanto o back-end podem se comunicar separadamente sem nenhuma alteração adicional, pois o front-end sabe que os dados no esquema sempre estarão sincronizados no sistema.

Rápido e Seguro

O problema de over-fetching pode resultar em maior consumo de largura de banda para os clientes, o que pode, com o tempo, causar atrasos em seu aplicativo. Usar padrões de design de API RESTful é mais demorado para separar as informações necessárias de uma carga útil enorme.

Devido à capacidade do GraphQL de evitar buscas excessivas e insuficientes, o servidor retorna uma forma segura, fácil de ler e previsível que torna suas solicitações e respostas de API mais rápidas.

Benefícios do REST

Apesar da crescente popularidade do GraphQL, o REST ainda é um dos padrões de API mais populares. Vamos dar uma olhada no porquê.

• Curva de aprendizado: APIs RESTful são as mais fáceis de aprender e entender. Esta é sua principal vantagem sobre outras APIs.
• Serialização: REST vem com uma abordagem e formatos flexíveis para serialização de dados em JSON.
• Cache: a API REST pode gerenciar uma carga alta com a ajuda de um servidor proxy HTTP e cache.
• Solicitação complexa: as APIs REST têm um endpoint separado para solicitações diferentes e isso ajuda a tornar a solicitação complexa mais gerenciável do que em outras APIs
• Limpo e Simples: as APIs REST são elegantes, simples e limpas. Eles são fáceis de explorar.
• Procedimentos HTTP padrão: REST usa chamadas de procedimento HTTP padrão para recuperar dados e fazer solicitações.
• Cliente/Servidor: Isso significa que sua lógica de negócios está desacoplada da apresentação. Assim, você pode alterar um sem afetar o outro.
• REST Is Stateless: Todas as mensagens trocadas entre cliente e servidor possuem todo o contexto necessário para saber o que fazer com a mensagem.

Desvantagens do GraphQL

Agora que discutimos os prós do GraphQL vs REST, vamos explorar algumas das desvantagens do GraphQL:

• Curva de Aprendizagem Difícil: GraphQL não é tão fácil de aprender quanto REST. A parte mais desafiadora da construção de uma API GraphQL é projetar o esquema. Isso leva muito tempo e conhecimento de domínio.
• Upload de arquivo: o GraphQL não possui um recurso de upload de arquivo nativo. Isso pode ser contornado usando a codificação Base64, mas o custo de codificação e decodificação dessa maneira pode ser demorado e caro.
• Web Caching: O cache ajuda a reduzir o tráfego frequente para o servidor, o que agiliza as solicitações e o processo de resposta, mantendo as informações acessadas com frequência próximas ao servidor. O GraphQL não suporta ou depende de métodos de cache HTTP, dependendo dos mecanismos de cache dos clientes Apollo ou Relay.
• Inadequado para aplicativos pequenos: o GraphQL pode não ser a melhor arquitetura de API para criar um aplicativo pequeno. Se o seu aplicativo não exigir as consultas mais flexíveis oferecidas pelo GraphQL, o REST é o caminho a seguir.
• Problema de consulta complexa: a capacidade do GraphQL de fornecer a um cliente exatamente o que ele deseja também pode levar a problemas de propagação de consulta. Se um cliente enviar muitas consultas aninhadas, isso pode levar ao envio de consultas erradas, o que pode consumir muito tempo para o servidor. É melhor utilizar REST com endpoints personalizados para atender a essas solicitações.

Desvantagens do REST

Agora, vamos voltar nossa atenção para algumas das desvantagens do REST:

• Várias viagens de ida e volta: O maior problema com APIs REST é a natureza de vários endpoints. Isso significa que para o cliente obter todos os recursos para uma aplicação completa, ele precisa fazer inúmeras idas e voltas para obter os dados.
• Over-fetching e under-fetching: O problema de over-fetching e under-fetching é uma grande desvantagem nas APIS RESTful. Pode causar atraso nas respostas devido à busca de grandes cargas indesejadas.
• Hierarquia: como as APIs REST são construídas em recursos de referência de URI, elas são inadequadas para recursos que não são naturalmente organizados ou acessados ​​em uma hierarquia simples.

Por que usar GraphQL em vez de REST

Em seguida, discutiremos por que você pode querer considerar o GraphQL para seu futuro desenvolvimento de API em vez da API RESTful.

Esquema fortemente tipado

O GraphQL usa um sistema de tipos forte para definir os recursos da API. No GraphQL, a linguagem de definição de esquema (SDL) é usada para definir os parâmetros em torno de como o cliente acessa os dados do servidor. Todas as APIs expostas ao cliente são escritas em SDL, resolvendo o problema de inconsistência de dados visto em APIs RESTful.

Sem over-fetching ou under-fetching

A questão da busca excessiva ou insuficiente é um problema conhecido das APIs RESTful nas quais os clientes recebem mais ou menos informações do que solicitaram. O GraphQL resolve esse problema fornecendo um meio para o cliente especificar as informações necessárias e, em seguida, retornando exatamente - e apenas - essas informações específicas.

Vários endpoints

Um dos maiores problemas das APIs RESTful é ter muitos endpoints para acessar as informações.

Vamos supor que você queira acessar um determinado usuário por meio de seu número de identificação. Você seria apresentado a um endpoint como /users/1 . Mas se você quiser acessar as fotos desse usuário, precisará enviar uma solicitação para outro endpoint, como /users/1/photos .

No GraphQL, você tem um único endpoint e não precisa enviar várias solicitações para recuperar informações diferentes sobre o usuário.

Confronto GraphQL vs REST

Por fim, vamos explorar a principal diferença entre as APIs GraphQL e RESTful. Depois disso, discutiremos alguns dos recursos de um bom design de API e compararemos como cada tecnologia lida com eles.

atuação

Não há dúvida de que o GraphQL funciona mais rápido que as APIs RESTful devido à sua capacidade de fornecer um único endpoint para acessar todos os seus recursos. As APIs RESTful usam vários endpoints, o que pode resultar em latência de rede.

Complexidade da consulta

Como os endpoints não são separados em vários endpoints, as consultas do GraphQL podem se tornar cada vez mais complexas ao longo do tempo. Os endpoints da API RESTful, por outro lado, são separados, o que restringe as APIs RESTful a consultas simples.

Popularidade e suporte da comunidade

GraphQL é um padrão de arquitetura de API e linguagem de consulta em crescimento. Embora ainda seja jovem, sua taxa de adoção e pool de recursos estão crescendo rapidamente, e os recursos já são abundantes para os interessados ​​em aprender por conta própria.

O REST, por outro lado, já possui um vasto suporte da comunidade e continua sendo usado por empresas de todos os tipos, desde as que criam pequenos microsserviços até as que criam aplicativos sociais complexos e além.

Atualmente, o concurso de popularidade entre GraphQL vs REST está empatado. Ambas as tecnologias continuam a ser amplamente utilizadas e bem apoiadas pela comunidade de desenvolvimento.

Curva de aprendizado

A curva de aprendizado do GraphQL é íngreme. Requer um bom conhecimento de domínio de desenvolvimento de API e engenharia geral de software. Um iniciante completo terá dificuldade em entender o GraphQL o suficiente para criar um aplicativo complexo.

Por outro lado, o REST é muito fácil de começar e requer menos conhecimento de domínio imediatamente. A API RESTful está bem integrada à maioria das principais linguagens de programação e estruturas populares, o que facilita muito o aprendizado.

Resumo

GraphQL é uma nova tecnologia que segue os padrões de arquitetura de API RESTful, assim como REST foi introduzido para resolver problemas com padrões de API SOAP.

O GraphQL oferece respostas mais rápidas, um único endpoint de API para todas as suas consultas e um esquema estrito para acesso consistente aos dados. Essas razões são o que fez com que empresas multibilionárias começassem a mudar para o GraphQL, mesmo no estágio inicial. No entanto, apesar de suas limitações, o progenitor REST do GraphQL continua mantendo uma forte presença no palco.

Neste guia, exploramos tudo o que você precisa saber sobre GraphQL e APIs RESTful, incluindo os benefícios e as desvantagens de cada tecnologia, para ajudá-lo a decidir com confiança qual delas prefere. Também discutimos os problemas conhecidos com APIs RESTful — como over-fetching, under-fetching e vários endpoints — e como o GraphQL tenta resolver esses problemas e aumentar o desempenho do seu aplicativo.

Agora você tem insights suficientes para escolher se GraphQL vs REST é apropriado para seu próximo projeto. Deixe-nos saber na seção de comentários o que você estará construindo com o vencedor escolhido!