O que é gRPC?

RPC, ou chamada de procedimento remoto, é um modelo de comunicação para interação cliente/servidor que permite que as chamadas remotas apareçam e funcionem como chamadas locais. É uma técnica mais antiga, que remonta conceitualmente à década de 1970, com aplicações iniciais vistas em projetos de computação pioneiros, como a ARPANET e o Xerox PARC.

Em um RPC, o cliente interage com uma representação do servidor, que parece local, mas na verdade é um intermediário. Esse intermediário é comumente chamado de stub, que manipula os dados de empacotamento e desempacotar (ou seja, convertendo os dados em um formato adequado para transmissão e convertendo os resultados recebidos do servidor de volta ao formato original). Por ser um estilo de arquitetura para comunicação cliente/servidor, é comumente utilizado no projeto de APIs.

Há muitas implementações diferentes de frameworks RPC, incluindo XML-RPC e JSON-RPC. Essas implementações usam HTTP como protocolo de transporte, diferindo principalmente no tipo de formato. Datando das décadas de 1990 e 2000, essas implementações demonstraram os pontos fortes do RPC: simplificaram o desenvolvimento, abstraem as complexidades da comunicação em rede, são leves, relativamente simples de usar e podem ser lidos por humanos.

No entanto, muitos ambientes modernos (particularmente aqueles que usam arquiteturas de microsserviços, ambientes poliglotas e sistemas com altas cargas de dados) exigem um framework mais rápido e de alto desempenho para conectar aplicações distribuídas. Idealmente, esse framework facilita a transferência de dados mais eficiente e em tempo real entre serviços executados em diferentes ambientes e data centers.

O gRPC foi desenvolvido para atender a essa necessidade, oferecendo baixa latência e alta taxa de transferência por meio de serialização de dados e seu uso do protocolo HTTP/2, recursos de streaming bidirecional, geração de código e muito mais.

O gRPC foi lançado inicialmente em 2015, o mesmo ano do lançamento do HTTP/2. Ele lida com as limitações com implementações de RPC mais antigas, principalmente por meio do uso de buffers de protocolo, ou Protobuf, sua linguagem de definição de interface (IDL). O Protobuf serializa e codifica dados estruturados em binário. Isso torna os dados mais compactos, permitindo uma transmissão mais rápida e maior desempenho.

O Protobuf também permite alterações nos campos de dados sem interromper o código. Isso ajuda a reduzir erros e permite o compartilhamento e o processamento de dados em tempo real. Essas funcionalidades tornam as APIs criadas com o gRPC uma forte opção para ambientes modernos e distribuídos, arquiteturas de microsserviços, aplicações de streaming e para conectar sistemas e dispositivos da Internet das coisas.

Faria sentido se gRPC significasse "Chamada de procedimento remoto do Google". Mas a equipe gRPC do grpc.io afirma de forma descarada que significa "Chamada de Procedimento Remoto gRPC". Seu GitHub observa que o "g" significa algo diferente em cada versão (variando de "gregário" a "ganso" e "Guadalupe River Park Conservancy"). Em qualquer caso, o Google desenvolveu o gRPC e o lançou como um projeto de código aberto em 2015.

O gRPC apresenta uma versão moderna e atualizada do RPC, com compatibilidade com linguagens modernas e funcionalidades e otimizações adicionais. As funcionalidades são:

• Uma interface design language (IDL) chamada Buffers de protocolo
• Uso de HTTP/2 para transmissão de dados
• Streaming bidirecional
• Geração de códigos
• Quatro tipos de métodos
• Integração com segurança baseada em TLS
• Compatível com interceptor para registro, rastreamento, autenticação e muito mais

Buffers de protocolo, comumente conhecidos como Protobuf, é um formato de dados de plataforma cruzada desenvolvido pelo Google usado para serializar dados estruturados. Na verdade, serve como um intermediário poderoso entre o cliente e o servidor que serializa as solicitações em código binário para transmissão.

Esse mecanismo é flexível e eficiente, permitindo agnosticismo da linguagem de programação, tamanho de mensagem reduzido e análise e transmissão mais rápidas, tudo ao mesmo tempo. Uma aplicação que usa Java pode se comunicar com um que usa Python porque a solicitação é convertida na língua franca do binário. Embora não seja legível por humanos, o binário é mais rápido de transmitir e decodificar em computadores do que um formato baseado em texto, como o JSON.

Basicamente, os desenvolvedores criam um arquivo de texto com o sufixo ".proto", que contém todas as informações sobre estrutura de dados. Essas informações são baseadas em esquema, o que significa que definem parâmetros, métodos e possíveis saídas — uma descrição da estrutura dos dados. Por exemplo, você pode ter uma entrada para "usuário", que observa que esses dados incluirão "nome", "endereço de e-mail" e "cobertura de pizza favorita".

De acordo com a documentação do Protobuf, é como o XML, “mas menor, mais rápido e mais simples. Você define como deseja que seus dados sejam estruturados uma vez, então você pode usar código-fonte especialmente gerado para escrever e ler facilmente seus dados estruturados de e para uma variedade de fluxos de dados e usando uma variedade de linguagens." Como intermediário, o Protobuf também permite a instalação de várias medidas de autenticação e segurança.

Os desenvolvedores podem usar um compilador chamado Protoc para gerar código em qualquer uma das várias linguagens compatíveis, incluindo C#, C++, Dart, Go, Java, Kotlin, Node.js, Objective-C, PHP, Python e Ruby. Esse código serve para muitas funções: normalmente inclui classes ou módulos, lida com a serialização em binário e desserialização de binário e abstrai as complexidades da troca de dados. Os desenvolvedores não precisam se preocupar com empacotamento de rede, empacotamento, atualização para compatibilidade e implementação; o Protobuf cuida de tudo.

O projeto baseado em esquema do Protobuf permite que os desenvolvedores adicionem novos campos de dados a estruturas existentes sem quebrar todo o sistema. Também reduz muito o esforço necessário para atualizar, manter e lidar com tarefas tediosas relacionadas a APIs, como ajustar o código anterior após adicionar novos campos de dados. Dito isso, os arquivos .proto podem levar algum tempo e esforço para serem configurados.

HTTP/2 é um protocolo de transporte (um método que os computadores e servidores usam para trocar informações) que usa um formato binário para enviar mensagens, reduz as conexões TCP e usa compactação de cabeçalho, o que ajuda a torná-lo mais rápido e eficiente do que seu antecessor ( HTTP/1.1). Ela também permite a multiplexação, ou a capacidade de enviar múltiplos fluxos simultâneos em uma única conexão; O gRPC usa os chamados canais para permitir vários fluxos nessas várias conexões. As mensagens são enviadas como quadros de dados HTTP/2, cada um dos quais pode conter várias mensagens gRPC.

O gRPC oferece streaming bidirecional, no qual tanto o cliente quanto o servidor podem enviar mensagens de forma independente em um fluxo de leitura/gravação. Esse método permite todos os tipos de flexibilidade: um servidor e um cliente podem trocar respostas sequencialmente, ou um servidor pode esperar até que todas as mensagens do cliente tenham sido recebidas antes de responder. Essa funcionalidade pode ser ajustada de acordo com aplicações específicas.

O gRPC usa uma ferramenta de compilação chamada protoc para gerar automaticamente o código do cliente e do servidor em várias linguagens com base nas definições de serviço e estruturas de mensagem definidas em um arquivo .proto . Os plug-ins podem ser usados para estender a compatibilidade a muitas outras linguagens.

O Protoc gera classes de acesso a dados na linguagem definida na definição do Proto. Essas classes fornecem acessadores simples para campos como [nome], bem como métodos para serializar e analisar a estrutura de entrada e saída de bytes brutos.¹

O gRPC é compatível com quatro tipos de métodos diferentes para transmissão de dados: unário, streaming do lado do cliente, streaming do lado do servidor e streaming bidirecional.

O gRPC possui integração integrada com o TLS (segurança da camada de transporte), que criptografa as trocas de dados entre o cliente e o servidor e permite que os usuários ajudem a proteger as conexões.

O gRPC é compatível com autenticação conectável, rastreamento, registro, métricas, balanceamento de carga, verificação de integridade e muito mais. 

O gRPC tem quatro tipos diferentes de métodos, que indicam como uma mensagem é enviada e recebida por um cliente gRPC e um servidor gRPC. Esses tipos são:

Unário: uma chamada simples em que um cliente envia uma única solicitação e um servidor responde com uma única resposta.

Streaming no lado do servidor: uma chamada em que o cliente envia uma solicitação, mas o servidor responde com várias respostas.

Streaming no lado do cliente: uma chamada em que um cliente envia múltiplos pedidos e um servidor responde com uma única resposta. O servidor pode optar por aguardar que todo o fluxo de solicitações de clientes termine antes de processar e responder.

Fluxo bidirecional: o cliente e o servidor enviam várias chamadas para frente e para trás simultaneamente, permitindo a comunicação em tempo real.

gRPC e REST são estilos de arquitetura comumente usados no projeto de APIs. Eles têm muitas semelhanças; ambos seguem uma arquitetura cliente/servidor, dependem de comunicação baseada em HTTP, são sem estado e independentes de linguagem. Mas eles também diferem de maneiras importantes que tornam cada um ideal para diferentes casos de uso.

Formato de dados: as APIs REST usam formatos de texto simples, como JSON e XML. O gRPC usa Protobuf para codificar dados em binário.

Padrão de comunicação: o gRPC é compatível com quatro métodos: unário, streaming de servidor, streaming de cliente e streaming bidirecional. O REST usa um sistema unário de solicitação e resposta.

Geração de código: o gRPC oferece geração de código integrada; o REST não, embora existam plug-ins disponíveis.

Padrão de projeto: o gRPC tem um projeto orientado a serviços, no qual as operações de servidor que podem ser chamadas são definidas como serviços ou funções. No REST, o projeto é orientado a recursos, nos quais os métodos HTTP são usados para acessar os recursos do servidor por meio de endpoints definidos por URLs.

Protocolo: o gRPC usa HTTP/2, enquanto o REST depende do HTTP/1.1.

Acoplamento: o cliente e o servidor do gRPC são fortemente acoplados, o que significa que o cliente e o servidor devem ter acesso ao mesmo arquivo de protótipo do middleware. Qualquer alteração em um requer alteração no outro. O REST é fracamente acoplado. Essa independência significa que mudanças em um componente não afetam o outro.

O gRPC é frequentemente usado para APIs complexas que conectam vários serviços em um ambiente distribuído. Seu recurso de streaming em tempo real e seu alto desempenho tornam o gRPC ideal para vários casos de uso, incluindo microsserviços, streaming e conexão de clientes da Internet das coisas.

Devido ao seu alto desempenho, baixa latência, capacidade de lidar com grandes volumes de dados e recurso de streaming bidirecional em tempo real, o gRPC é frequentemente usado para criar APIs para microsserviços.

Como o gRPC é independente de linguagem, ele pode permitir a comunicação entre serviços escritos em diferentes linguagens de programação. Além disso, as definições do Protobuf fornecem um esquema fortemente digitado que ajuda a proteger a integridade dos dados do microsserviço.

Os recursos de streaming bidirecional do gRPC significam que ele pode transmitir dados simultaneamente em ambas as direções entre o cliente e o servidor por meio de uma única conexão de rede. Esse recurso torna o gRPC ideal para processos contínuos, como videoconferência ou quando um usuário deseja usar parte de um conjunto de dados enquanto outros dados estão sendo transferidos.

A Internet das coisas refere-se a uma rede de dispositivos ou clientes conectados. Os dispositivos de IoT (também conhecidos como "objetos inteligentes") podem incluir dispositivos simples de "casas inteligentes", como termostatos inteligentes, dispositivos vestíveis, como smartwatches, roupas com RFID, além de máquinas industriais complexas e sistemas de transporte.² As APIs gRPC são frequentemente usadas para facilitar a troca de dados consistente entre esses dispositivos.

Com sua compatibilidade com streaming bidirecional e recursos fáceis de usar para microsserviços (e seu status como um projeto CNCF), o gRPC é cada vez mais usado para APIs nativas da nuvem.

O gRPC é usado para gerar bibliotecas de cliente em muitas linguagens de programação diferentes. Essas bibliotecas são geradas com base na definição de serviço fornecida em .proto arquivos; Depois que o serviço é definido, o gRPC gera automaticamente o código do cliente na linguagem de programação escolhida.

Esse recurso simplifica o trabalho dos desenvolvedores, permitindo que se concentrem na lógica da aplicação em vez de no código de comunicação de baixo nível.

O gRPC oferece muitos benefícios para organizações e desenvolvedores que criam APIs com requisitos de alto desempenho. Esses benefícios são:

Transmissão mais rápida e eficiente: existem vários fatores que contribuem para o alto desempenho do gRPC. Por um lado, a serialização Protobuf reduz o tamanho da mensagem e pacotes menores podem ser transmitidos mais rapidamente. O binário também é analisado de forma mais eficiente do que os formatos de texto simples, como JSON ou XML.

Além disso, o gRPC usa HTTP/2, que é mais rápido e eficiente que HTTP/1.1, reduzindo ainda mais a latência e o uso da largura de banda.

Maior portabilidade: como o gRPC usa buffers de protocolo (um mecanismo de serialização independente de linguagem e plataforma) para descrever estruturas de dados e interfaces RPC, ele pode ser usado para permitir a comunicação entre serviços escritos em vários idiomas em diferentes plataformas.

Erros de tempo de execução reduzidos: o Protobuf oferece tipagem forte, o que significa que ele impõe uma estrutura de dados firme e explicitamente definida. A tipagem forte promove consistência e detecção precoce de erros, reduzindo a chance de erros no tempo de execução.

Personalização flexível: a compatibilidade integrada com middleware permite a personalização e a adição de funcionalidades, como medidas de segurança e autenticação ou análise de dados.

Embora o gRPC tenha muitas vantagens, ele não está isento de desafios. Em alguns casos (por exemplo, APIs voltadas para o público com fontes de dados simples em que a facilidade de uso é uma consideração principal), a complexidade introduzida pelo gRPC pode ser desnecessária. Os desafios do gRPC incluem:

Complexidade: definição de estruturas de mensagens e serviços em arquivos .proto, como exige o gRPC, podem ser mais desafiadores do que trabalhar com formatos baseados em texto, como XML e JSON.

Facilidade de uso: gRPC, buffers de protocolo e HTTP/2 podem apresentar uma curva de aprendizado acentuada para desenvolvedores acostumados a trabalhar com REST.

Depuração: pode ser difícil inspecionar, depurar e registrar aplicações gRPC porque o formato binário não é legível por humanos. Existem ferramentas que podem converter binário, mas exigem uma etapa extra, em comparação com XML ou JSON.

Recência e compatibilidade: o gRPC não é tão antigo quanto outros estilos de arquitetura populares, como o REST, e não tem uma comunidade tão grande ou tanta compatibilidade com plug-ins e documentação. Como um framework mais novo, há menos ferramentas (como ferramentas de scanner de segurança) disponíveis para o gRPC em comparação com alguns estilos mais estabelecidos.

Limitações de navegadores: como os navegadores da web não são compatíveis nativamente com o protocolo gRPC, não é possível chamar diretamente um serviço gRPC a partir de uma aplicação baseada em navegador. Uma forma de contornar essa limitação é usando um proxy como o gRPC-Web. O gRPC-Web atua essencialmente como uma camada de tradução entre o HTTP do navegador e o protocolo gRPC.

A aplicação da web inicia uma chamada gRPC usando a biblioteca de cliente gRPC-Web JavaScript para enviar uma solicitação gRPC que foi adaptada para compatibilidade com navegadores. A solicitação é enviada para um servidor proxy, que converte a solicitação em uma solicitação gRPC padrão e a encaminha para o servidor back-end gRPC. O servidor gRPC processa a solicitação, envia de volta uma resposta ao servidor proxy, e o proxy mais uma vez converte a resposta no formato gRPC-Web antes de passar de volta para o cliente.