Veja o que é um serviço gRPC, seus beneficios e vantagens. Descubra também quais foram as motivações do Google para desenvolve-lo e quais seus principios de design.

A Microsoft vai disponibilazr o gRPC para ASP.NET Core junto com o .NET Core 3. Veja como ele pode impactar seu dia-a-dia, quais os beneficios. Atualize e esteja preparado!

O que é

O gRPC é um serviço de alto desempenho para atender chamadas RPC (Remote Call Procedures). Open source e que pode ser executado em qualquer ambiente. Permite que o aplicativo client-server se comuniquem de forma transparente. Com suporte a load balance, tracing, health-check e autenticação. Facilitando a comunicação entre sistemas.

Suporta o protocolo Protobuf por padrão, tornando a comunicação entre serviços ainda mais eficiente. Além de suportar comunicação HTTP2 e QUIC.

Pode também utilizar outros protocolos de mensagens como JSON e XML.

RPC

O RPC é um modelo client-server. O solicitante é um client e quem fornece a informação é um serviço Server side. O RPC é uma operação síncrona e exige que o Client seja suspenso até que o resultado do Server seja retornado.

Google RPC

O Google é o criador do gRPC. O objetivo era conectar os Microsserviços em seus datacenters. O google já utiliza Microsserviços há muito tempo.

Protocol buffer

Protobuf (sigla de Protocol buffers) é um protocolo de mensagem criado e utilizado pelo Google. Para serializar dados estruturados. É agnóstico de linguagem ou plataforma. Tal como o JSON e o XML.

A transferência utilizando o protobuf chega a ser até 6 vezes mais rápido se comparado com JSON.

Beneficios

Os principais benefícios do gRPC são:

Estrutura RPC leve e de alto desempenho.
Desenvolvimento de API Contract-first, usando Protocol Buffers por padrão.
Ferramentas disponíveis para várias linguagens de programação.
Suporta chamadas streaming do client, server e bidirecionais.
Redução do uso de rede através da serialização do Protobuf.

Esses benefícios tornam o gRPC ideal para:

Ambientes com Microsserviços, pois torna a comunicação leve. Onde a eficiência é crítica.
Por estar disponivel em diversas linguagens torna os sistemas poliglotas. Novamente beneficiando ambientes com Microsserviços.
Serviços real time ponta-a-ponta que precisam lidar com solicitações ou respostas de streaming.

Princípios e Requisitos

O Google criou alguns principios e requisitos tanto para os desenvolvedores que utilizam, quanto para aqueles que implementam sua própria versão do gRPC.

Serviços não Objetos, Mensagens e não Referências - Promove a filosofia de design de microsserviços. Com eficiência na troca de mensagens entre sistemas. Evitando as armadilhas de objetos distribuídos e as falácias de ignorar a rede.
Cobertura e Simplicidade - O gRPC deve estar disponível em todas as plataformas de desenvolvimento. Deve ser fácil para um dev construir um serviço gRPC. Deve ser viável em dispositivos com CPU e memória limitada.
Gratuito e Open Source - Os recursos fundamentais deve ser gratuitos para todos. As funcionalidades serão sempre de dominio público, com licenciamento que deve facilitar e não impedir a adoção.
Interoperabilidade e Alcance - O protocolo de comunicação deve ser capaz de suportar à uma infra-estrutura comum de internet.
Propósito geral e Performance - O gRPC deve ser aplicável em uma grande gama de cenários. Ao passo que sacrifica muito pouco o desempenho quando comparado a uma tecnologia específica do cenário proposto.
Layered (Em camadas) - As principais funções da tecnologia devem ter a habilidade de evoluir de forma independente. A troca do protocolo de comunicação não deve quebrar a camada de aplicação.
Payload Agnostic - Serviços podem precisar usar diferentes tipos de mensagem e encode, como Protobuf, JSON, XML e Thrift. O protocolo do comunicação e as implementações devem permitir isso. Da mesma forma, a necessidade de compactação da mensagem varia de acordo com o cenário: o protocolo deve permitir diferentes mecanismos de compactação.
Streaming - Sistemas de storage dependem de streaming e de controle de fluxo para expressar grandes conjuntos de dados. Outros serviços, como voice-to-text ou stock-tickers, dependem de streaming para representar mensagens temporalmente relacionadas.
Blocking & Non-Blocking - Deve suporta o processamento síncrono e assíncrono das mensagens trocadas por um client-server. Isso é crítico para escalabilidade e lidar com streams em determinadas plataformas.
Cancellation & Timeout - As operações podem ser pesadas ou demorar no processamento - Com especificações de cancelamento permite que os servidores recuperem recursos quando os client são bem desenvolvidos. O cancelamento pode ocorrer em cascata. Um client pode indicar um tempo limite para uma chamada. Permitindo que os serviços ajustem seu comportamento às necessidades do cliente.
Lameducking - Os servidores devem ter a permissão de desligar, rejeitando novas solicitações, enquanto continuam processando os pedidos em andamento.
Controle de Fluxo - O poder de computação e a capacidade de rede são frequentemente desequilibrados entre client e server. O controle de fluxo permite um melhor gerenciamento de buffer, além de fornecer proteção DOS.
Pluggable - Um protocolo de comunicação é apenas uma parte da infraestrutura. Grandes sistemas distribuídos precisam de segurança, health check, load balance e failover, monitoramento, tracing e logs, etc. As implementações devem ser extensiveis. Permitindo que o desenvolvedor escolha os componentes desses recursos e, quando útil, implementações padrão.
Extensões como APIs - Extensões que exigem colaboração entre serviços devem fazer o uso de APIs em vez de extensões de protocolo, sempre que possível. Extensões desse tipo podem incluir health check, load balance, service introspection e load monitoring.
Metadata Exchange - Conceitos comuns de cross-cutting, como autenticação ou trace, dependem da troca de dados que não fazem parte da interface de um serviço. Os deploys dependem de sua capacidade de evoluir esses recursos a uma taxa diferente das APIs expostas pelos serviços.
Códigos de status padronizados - Os clients geralmente tratam erros retornados por chamadas de API. O namespace do status code deve ser restrito para tornar o gerenciamento de erros mais claro. Se for necessário um status de erro específico do domínio, o metadados da mensagem pode ser utilizado.

O conteúdo original estará nas referências

Conclusão

O gRPC é mais um aliado na construção de APIs. O foco é a comunicação entre serviços. Por ser agnóstico promete boa adoção em ambientes com Microsserviços.

Espero que este artigo tenha te ajudado a entender mais sobre o gRPC!