A arquitetura cliente-servidor popular divide a comunicação em duas partes: uma que assume todas as tarefas pesadas e fornece serviços, conhecida como servidor, e a outra que aproveita esses serviços, conhecida como cliente.
Em geral, na comunicação cliente-servidor, o cliente simplesmente envia uma solicitação pedindo recursos ou serviços ao servidor, e o servidor responde a essa solicitação.
Para a comunicação cliente-servidor, clientes e servidores precisam ter bibliotecas que possam entender o protocolo no qual estão se comunicando. Um protocolo é uma linguagem ou conjunto de regras de comunicação na Internet. Eles são mecanismos de transporte que seguem algumas diretrizes para transportar dados pela Internet.
O segundo aspecto mais importante da comunicação do cliente é o formato de mensagem no qual tanto o cliente quanto o servidor podem concordar. Esse formato de mensagem é baseado em alguns esquemas, e ao não seguir esses esquemas, a comunicação não estaria ocorrendo. Os formatos de mensagem podem ser semelhantes ao XML, que adere a um esquema, ou a um arquivo JSON, que deve conter pares de chave-valor específicos.
Outro aspecto importante deste tipo de comunicação a ser entendido é que é baseado em um mecanismo de solicitação e resposta, o que significa que o servidor só se comunica quando o cliente inicia a comunicação. Com REST e GraphQL, isso é principalmente unidirecional. Este é um problema básico que será resolvido por tecnologias como gRPC.
Por que o REST surgiu?
Nos primórdios dos anos 90, um protocolo cliente-servidor popular chamado SOAP utilizava o formato de mensagem XML com um esquema hardcoded. O esquema para o formato de mensagem era muito rígido. A falta de liberdade foi o que causou o abandono do SOAP e a emergência do REST.
O REST surgiu devido ao crescente apelo do JavaScript, o que levou ao aumento da popularidade do formato de arquivo JSON. Era simples de entender e conveniente. Apenas tinha alguns pares de chave e valor em seu formato de mensagem.
Em termos simples, o Rest é uma diretriz para transferir mensagens JSON pela internet com o HTTP como seu protocolo (mecanismo de transporte). Com o Rest, não é necessário se preocupar em criar um esquema.
O que é REST?
Falamos sobre a emergência do REST. Agora vamos mergulhar fundo em sua tecnologia central. Então, deixe-me dizer que REST significa Transferência de Estado Representacional. O Rest é um estilo arquitetônico de software padronizado, uma API muito utilizada na indústria.
Razões para a Popularidade e Uso Generalizado do REST
- O REST é simples e padronizado para arquitetura de comunicação. Ao utilizar R, você não precisa se preocupar com a formatação de sua mensagem ou dados. Você não precisa se preocupar com o formato de sua mensagem a cada momento, pois tudo é padronizado e utilizado na indústria.
- O REST é escalável. Se seu serviço se tornar maior e precisar de mais funcionalidades, você pode facilmente reformular seu servidor sem se preocupar com o desempenho do REST do servidor, e você pode criar novas funções em completa isolamento, a menos que estejam atrapalhando seus dados.
- REST é stateless. Isso significa que cada requisição terá alguns dados que devem ser compreendidos pelo servidor. A arquitetura do servidor faz com que o servidor recupere as informações desta requisição, mas na arquitetura REST, o estado da sessão é armazenado no lado do cliente, tornando o servidor mais eficiente e dando ao servidor pouco trabalho para um funcionamento mais fino.
- Por último mas não menos importante, o Rest é uma arquitetura de alto desempenho e suporta cache.
Quando Usar REST
Imagine que você está criando um site para um restaurante. Você tem todos os menus online, e os itens de comida são divididos em três categorias:
- Entradas
- Prato principal
- Bebidas
Agora, digamos que você queira ver todas as bebidas online. Na arquitetura Rest, você pode facilmente e consistentemente particionar todos os seus recursos em endpoints de API. Claro, você pode usar várias autenticações neles para mantê-los seguros.
Nesse tipo de caso, enviamos uma requisição GET ao servidor para um endpoint onde podemos obter dados de recurso de bebidas.
Da mesma forma, podemos executar todas as operações CRUD (Create, Read, Update, Delete) no Rest API, o que o torna adequado para grandes projetos que não exigem super-transmissão de dados e não precisam ser em tempo real.
O Rest funciona melhor para projetos onde a transferência eficiente de dados é um fator importante. O cache é outra característica do REST que é útil para aplicativos padrão como aplicativos de reserva de comida, aplicativos de reserva de hotel, sites de blog, sites de fórum, etc.
Limitações e Problemas com REST
REST é ótimo, mas tem vários contras que são bastante cruciais em alguns casos. Vamos falar sobre eles.
- A necessidade de comunicação bidirecional.
E se o servidor precisar enviar algum dado ao cliente? O servidor quer iniciar a comunicação. Na arquitetura REST, isso não é possível. Claro, você pode usar alguns truques, mas eles não são práticos. - Imagine criar um site de placar ao vivo. Como você manteria o servidor enviando uma solicitação ao cliente para atualizar os dados do placar? Podemos fazer com que os clientes enviem solicitações a cada 10 segundos, mas essa não é uma boa prática. Isso sobrecarregará o servidor, o que pode levar a problemas de velocidade.
- A arquitetura REST é puramente de solicitação e resposta e não suporta streaming de dados (processamento contínuo de eventos).
- A propriedade REST de ser stateless pode ser considerada uma bênção e uma maldição, pois você não pode decidir o estado dos dados na arquitetura REST.
Por que gRPC surgiu?
Para resolver o primeiro problema com REST, que é a necessidade de comunicação bidirecional, o WebSocket foi inventado, que permite que o servidor inicie a comunicação, mas o problema é que ele não tem um formato. Ele apenas envia bytes e não tem restrições.
Os WebSockets não tinham problemas próprios, mas o verdadeiro problema é que qualquer tipo de comunicação requer um protocolo, e cada protocolo requer uma biblioteca de cliente que possa se comunicar usando esse protocolo.
Se você está criando um aplicativo Python que trabalha com a arquitetura Rest, você precisará de um cliente HTTP que possa se comunicar com o servidor. Em muitos casos, bibliotecas de clientes são feitas por terceiros, principalmente por desenvolvedores independentes. O uso de bibliotecas de terceiros pode expor sua segurança, e todo o seu aplicativo dependerá de um terceiro para a comunicação.
No caso de um aplicativo web, o navegador age como uma biblioteca de cliente, mas para projetos não web, você precisará de uma biblioteca de cliente de terceiros. Se você está pensando em fazer uma por conta própria, lembre-se de que não é tão fácil, e você se sobrecarregará mantendo outro aplicativo.
Então, para resolver alguns problemas com Rest e para resolver problemas com bibliotecas de clientes, a Google inventou o gRPC em 2015.
Para o gRPC, uma biblioteca de cliente é mantida pela Google para quase todos os idiomas populares. Ele usa o protocolo HTTP 2 por baixo dos panos e protocol buffer (protobuf) como seu formato de mensagem.
Você não precisa se preocupar com nenhuma biblioteca de cliente, pois a Google está mantendo-a para você e para quase todas as linguagens de programação. Uma única e centralizada biblioteca de cliente é uma das principais forças do gRPC.
Outra vantagem do gRPC é o formato de mensagem que ele usa. O protocol buffer é agnóstico de linguagem, então você pode fazer clientes em Python e servidores em Go e ainda ser capaz de se comunicar sem fazer nenhum alvoroço.
O gRPC é essencialmente uma biblioteca de cliente e um protocolo que pode ser usado em qualquer dispositivo.
O que é gRPC?
O gRPC utiliza o protobuf para se comunicar. Ele serializa arquivos proto em formato binário e os envia para o servidor, e no lado do servidor, eles são desserializados para o formato original. É assim que funciona com o protobuf.
O gRPC possui diferentes formas de comunicação. Você pode pensar nelas como recursos do gRPC.
Recursos do gRPC
- Solicitação única:É um tipo simples de comunicação de solicitação-resposta onde o cliente envia uma solicitação proto e, ao recebê-la, o servidor espera algum tempo para realizar algum processo e, em seguida, retorna alguma resposta.
- Streaming de servidor:Ao fazer uma única solicitação, uma enxurrada de dados vem como resposta do servidor. Por exemplo, ao clicar em um vídeo, muitos dados relacionados ao vídeo inundam do lado do servidor.
- Streaming de cliente:É o oposto do streaming de servidor. Aqui o cliente envia muitos dados de uma só vez para o servidor. Por exemplo, isso acontece quando você compartilha um arquivo grande na internet ou envia uma imagem ou vídeo para a internet. O cliente envia dados constantemente para o lado do servidor.
- Streaming bidirecional:Nesse tipo de comunicação, o cliente e o servidor enviam vários mensagens. Um bate-papo é um excelente exemplo disso.
Esses são quatro recursos populares do gRPC que o tornam tão poderoso.
Quando Usar o gRPC
Quanto às características do gRPC, vimos alguns casos de uso para o gRPC. Vamos imaginar que você deseja criar um aplicativo de chat. Você não vai usar a API Rest, pois não será capaz de permitir a transmissão rápida de comunicação bidirecional. Para isso, vamos usar o stream do gRPC, que oferecerá algumas vantagens além da velocidade.
Primeiro, seu comportamento neutro em relação à linguagem não importa em que linguagem de programação o servidor ou outros clientes estão escrevendo. A comunicação ainda pode ser estabelecida, desde que o formato de mensagem seja aceito.
Então, com essa característica, a versão Android do aplicativo de chat pode se comunicar com a versão iOS e vice-versa.
Problemas com o gRPC
Existem questões com tudo, inclusive com o gRPC.
- Suporte limitado a navegadores:O gRPC usa o HTTP 2, então é difícil chamar o serviço gRPC diretamente do navegador, o que às vezes requer a configuração de um proxy.
- Formato não legível:Como todos sabemos, o gRPC usa um formato binário que não é legível por humanos. É uma desvantagem em alguns casos.
- Falta de maturidade:O gRPC foi desenvolvido em 2015, então ainda é um pouco imaturo em comparação com o REST, e muitos bugs e problemas precisam ser resolvidos.
- Questões de aprendizado:Rest e GraphQL usam JSON, que é mais fácil de aprender. A maioria das pessoas tentará se apegar a eles, pois o protobuf ainda é um tópico novo e complexo, então será difícil encontrar especialistas em gRPC.
REST vs. gRPC:
Agora discutiremos a diferença técnica entre REST e gRPC.
Formato de mensagem:
O formato de mensagem usado pelo REST é principalmente JSON (às vezes formato XML), que é uma forma mais legível e fácil de manusear. Você não precisará se preocupar com o esquema no Rest. Por outro lado, o gRPC usa um protocol buffer para serializar dados. A forma comprimida é mais leve e mais rápida para se deslocar. Está em formato binário, então serializa e desserializa dados para transmiti-los.
HTTP 1.1 vs. HTTP 2:
O Rest API geralmente usa o HTTP 1.1 como seu protocolo, enquanto o gRPC usa o HTTP 2 como seu protocolo por baixo dos panos. O Rest API ainda pode usar o HTTP 2, mas ainda é limitado devido ao mecanismo de requisição-resposta. O gRPC usa o HTTP 2 e aproveita o suporte do HTTP 2 tanto para comunicação de resposta do cliente quanto para comunicação bidirecional. Esta é outra característica que torna o desempenho do gRPC melhor que o REST. Ele pode gerenciar solicitações unidirecionais como o HTTP 1.1 e solicitações bidirecionais simultaneamente como o HTTP 2.
Latência:
A baixa latência e alta velocidade de comunicação do gRPC o tornam útil para conectar sistemas que consistem em arquitetura de microsserviços leves, o que aumenta a eficiência da transmissão de mensagens. Na maioria dos casos da rede, a latência do REST leva 25ms, enquanto a latência do gRPC é muito menor que a do REST.
Limite de carga útil:
O Rest tem um limite máximo de carga útil de 45MB ao enviar mensagens de saída, enquanto o gRPC não tem nenhum limite, o que significa que sua mensagem de saída pode ser tão pesada quanto você desejar.
Segurança:
Em termos de segurança, o Rest ficará atrás, pois utiliza o HTTP 1.1 e o formato JSON, que são fáceis de descriptografar e acessar. Por outro lado, o gRPC utiliza o HTTP 2, que é muito mais seguro, e usa o protobuf, que está em formato binário e é difícil de descriptografar.
Velocidade:
Aqui novamente, o gRPC vence, pois oferece 10 vezes mais velocidade que o Rest, e isso se deve ao mesmo motivo, utilizando o HTTP 2 como protocolo e o protobuf como formato de mensagem.
Função de geração de código
O Rest não fornece recursos de geração de código integrados, o que significa que o desenvolvedor precisa de aplicativos de terceiros para produzir código de API, enquanto o gRPC possui recursos de geração de código nativos devido ao seu compilador protobuf, que é compatível com várias linguagens de programação. Este é outro benefício, especialmente para arquiteturas de microsserviços.
Gateway REST de Memphis
Para permitir a produção de mensagens via chamadas HTTP para vários casos de uso e facilidade de uso, Memphis adicionou um gateway HTTP para receber solicitações baseadas em REST (=mensagens) e produzir essas mensagens para a estação necessária.
Casos de uso comuns que se beneficiam do Gateway REST são:
- Produzir eventos diretamente a partir de um frontend
- Conectar o Debezium usando o Servidor HTTP
- Webhooks do ArgoCD
- Integração do PostHog
- Receber dados do Fivetran/Rivery/Qualquer plataforma ETL usando chamadas HTTP
Gateway REST de Memphis + um esquema JSON pode ser uma combinação poderosa para aumentar a qualidade dos dados e garantir uma comunicação saudável entre aplicativos ou serviços.
Memphis em breve também suportará o gRPC.
Conclusão
Em última análise, gostaria de dizer que o REST ainda é a arquitetura mais utilizada e popular, e é impossível abandoná-la. O REST tem várias desvantagens, como a falta de transmissão de dados, ausência de comunicação bidirecional, velocidade lenta, etc., mas é o melhor para aplicações padrão que vemos no dia a dia.
Por outro lado, o gRPC, sendo jovem e difícil de aprender, oferece muitas coisas como alta transmissão de dados tanto no lado do cliente quanto do servidor, boa transmissão de dados bidirecional, é rápido e compacto, e usa o HTTP 2. Devido à sua alta performance, o gRPC é mais adequado para aplicações de alta carga de trabalho, como transmissão de vídeo, transmissão de músicas, jogos online, compartilhamento de arquivos e aplicativos de chat.