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 em que 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 um arquivo JSON, que deve conter pares específicos de chave-valor.
Outro aspecto importante deste tipo de comunicação a ser entendido é que ela é baseada 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 anos 90, um protocolo cliente-servidor popular chamado SOAP usava o formato de mensagem XML com um esquema codificado diretamente. 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 crescimento na popularidade do formato de arquivo JSON. Era simples de entender e conveniente. Apenas tinha algumas chaves e pares de valores em seu formato de mensagem.
Em termos simples, Rest é uma diretriz para transferir mensagens JSON pela internet com o HTTP como seu protocolo (mecanismo de transporte). Com Rest, não é necessário se preocupar em criar um esquema.
O que é REST?
Já falamos sobre o surgimento do REST. Agora vamos mergulhar fundo em sua tecnologia central. Então, deixe-me dizer que REST significa Transferência de Estado Representacional. Rest é um estilo arquitetural padronizado de software, 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 solicitação terá alguns dados que devem ser compreendidos pelo servidor. A arquitetura do servidor faz com que o servidor lembre informações desta solicitaçã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 autenticações múltiplas neles para mantê-los seguros.
Nesse tipo de caso, enviamos uma solicitação GET ao servidor para um endpoint onde podemos obter dados de recurso de bebidas.
Da mesma forma, podemos executar todos os CRUD (Create, Read, Update, Delete) na API Rest, o que a torna adequada para grandes projetos que não requerem super-transferência de dados e não precisam ser em tempo real.
O Rest funciona melhor para projetos em que 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 muitas desvantagens que são bastante cruciais em alguns casos. Vamos conversar sobre elas.
- A necessidade de comunicação bidirecional.
E se o servidor precisar enviar algum dado para o 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 resultados ao vivo. Como você manteria o servidor enviando uma solicitação ao cliente para atualizar os dados dos resultados? Podemos fazer com que os clientes enviem solicitações a cada 10 segundos, mas 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 sem estado 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 enfrentar 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 não tem um formato. Ele simplesmente 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, as bibliotecas de cliente são feitas por terceiros, principalmente 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 criar 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 enfrentar alguns problemas com Rest e para enfrentar problemas com bibliotecas de cliente, 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 em segundo plano e o 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 alarde.
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 comunicação. Ele serializa arquivos proto em formato binário e os envia para o servidor, e do lado do servidor, eles são desserializados de volta ao formato original. É assim que funciona com o protobuf.
O gRPC possui diferentes formas de comunicação. Você pode pensar nelas como características do gRPC.
Características do gRPC
- Pedido único:É um tipo simples de comunicação de pedido-resposta onde o cliente envia um pedido proto e, ao recebê-lo, o servidor espera algum tempo para realizar algum processo e, em seguida, retorna alguma resposta.
- Streaming do servidor:Ao fazer um único pedido, uma enxurrada de dados vem como resposta do servidor. Por exemplo, ao clicar em um vídeo, muitos dados relacionados ao vídeo inundam o lado do servidor.
- Streaming do cliente:É o contrário do streaming do 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 continuamente dados para o lado do servidor.
- Streaming bidirecional:Neste tipo de comunicação, o cliente e o servidor enviam vários mensagens. Um bate-papo é um excelente exemplo disso.
Estas são quatro características 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 permitirá a transmissão rápida de comunicação bidirecional. Para isso, usaremos o stream gRPC, que oferecerá alguns benefícios 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 sendo escritos. A comunicação ainda pode ser estabelecida, desde que o formato de mensagem seja aceito.
Assim, 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 problemas com tudo, incluindo 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.
- Problemas 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 manipular. Você não precisa 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, portanto, 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 solicitação-resposta. O gRPC usa o HTTP 2 e aproveita o suporte do HTTP 2 para comunicação tanto do cliente-resposta quanto bidirecional. Esta é outra característica que torna o desempenho do gRPC melhor do que o REST. 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 do que o 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 fica 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 é em formato binário e difícil de descriptografar.
Velocidade:
Novamente, o gRPC sai vitorioso, pois oferece 10x mais velocidade do que o Rest, e isso se deve ao mesmo motivo, usando 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 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 streaming de dados, não há comunicação bidirecional, velocidade lenta, etc., mas é o melhor para aplicativos padrão que vemos no dia a dia.
Por outro lado, o gRPC, sendo jovem e difícil de aprender, oferece muitas coisas como alto streaming de dados tanto no lado do cliente quanto do servidor, bom streaming de dados bidirecional, é rápido e compacto, e usa o HTTP 2. Devido ao seu desempenho rápido, o gRPC é o mais adequado para aplicativos de alta carga de trabalho como streaming de vídeo, streaming de músicas, jogos online, compartilhamento de arquivos e aplicativos de chat.