RPC
1. Pesquisa Conceitual
O que é RPC (Remote Procedure Call)
O RPC é um protocolo que permite a um programa solicitar um serviço de um programa localizado em outro computador em uma rede, sem ter que entender os detalhes da rede. Basicamente, o programador escreve código como se estivesse chamando uma função local (ex: calcularSalario()), mas essa função é executada em um servidor remoto.
Analogia do Restaurante: Imagine que você está em um restaurante. No RPC, você tem um botão na mesa que diz “Trazer Prato Feito”. Você aperta, e a comida aparece. Você não precisa saber se o cozinheiro está na cozinha ao lado ou em um prédio anexo; você apenas invoca uma ação direta. Você não negocia recursos, você comanda ações.
Diferença Conceitual: RPC vs. REST
Enquanto o REST (Representational State Transfer) é orientado a recursos (substantivos) e usa verbos HTTP (GET, POST, PUT) para manipular esses recursos, o RPC é orientado a ações (verbos).
- REST:
POST /contas/123/transferencia(Crie um recurso de transferência na conta 123). - RPC:
transferirDinheiro(123, valor)(Execute a função transferir).
Analogia da Correspondência:
- REST é como enviar uma carta formal via correio. Você preenche o envelope (cabeçalhos HTTP), escreve o conteúdo num padrão aceito (JSON) e coloca na caixa de correio (endpoint).
- RPC é como usar um Walkie-Talkie. Você aperta o botão e fala o comando direto: “Câmbio, inicie a operação X”. É mais imediato e focado no comando.
O que é gRPC
O gRPC (gRPC Remote Procedure Calls) é um framework de RPC de alto desempenho e código aberto, desenvolvido inicialmente pelo Google. Ele roda sobre o protocolo HTTP/2, o que permite funcionalidades avançadas como streaming bidirecional, compressão de cabeçalhos e multiplexação (várias requisições na mesma conexão TCP).
Por que o gRPC foi criado?
O Google criou o gRPC (baseado internamente no projeto Stubby) para conectar sua enorme quantidade de microsserviços. O REST com JSON era verboso demais, lento para serializar/deserializar e não tinha contratos rígidos, o que causava erros em sistemas gigantescos. O gRPC resolve isso sendo mais rápido, menor e mais seguro quanto aos tipos de dados.
O que é Protocol Buffers (Protobuf)
O Protobuf é o mecanismo de serialização de dados do gRPC. Diferente do JSON (que é texto legível), o Protobuf é binário. Ele transforma seus dados em sequências de bytes extremamente compactas para trafegar na rede.
Analogia da Mudança:
- JSON é como fazer uma mudança carregando caixas abertas, onde você vê o que tem dentro (legível), mas ocupam muito espaço no caminhão.
- Protobuf é usar uma máquina a vácuo que comprime todas as roupas em sacos minúsculos e planos. Ninguém sabe o que tem dentro olhando por fora (binário), mas você consegue colocar 10x mais itens no mesmo caminhão (rede).
Relação .proto e gRPC
O arquivo .proto é o contrato. É nele que você define a estrutura dos dados e os serviços. O compilador do gRPC lê esse arquivo e gera automaticamente o código (stubs) nas linguagens de programação escolhidas (Java, Python, Go, C#, etc.). Sem o .proto, o cliente e o servidor não saberiam “falar a mesma língua”.
2. Comparações Fundamentadas
RPC vs. REST
| Tema | RPC (foco em gRPC) | REST |
|---|---|---|
| Modelo de comunicação | Orientado a Ação/Comando (Funções). | Orientado a Recursos (Substantivos e Verbos HTTP). |
| Formato de dados | Geralmente Binário (Protobuf). | Geralmente Texto (JSON, XML). |
| Performance | Alta (serialização rápida, payload menor, HTTP/2). | Média (JSON é mais pesado e lento para processar). |
| Acoplamento | Alto/Forte (Cliente e servidor precisam do mesmo contrato .proto). | Baixo (O cliente precisa saber pouco sobre o servidor). |
| Facilidades/Dificuldades | Difícil de debugar (não legível por humanos), requer ferramentas específicas. | Fácil de debugar (basta abrir no navegador ou Postman). |
| Casos de uso comuns | Comunicação interna entre microsserviços, sistemas em tempo real, IoT. | APIs Públicas, integrações web simples, SPAs. |
Protobuf vs. JSON
| Tema | Protobuf | JSON |
|---|---|---|
| Estrutura | Fortemente tipada (exige esquema pré-definido). | Flexível (schema-less), estrutura dinâmica. |
| Desempenho | Excelente (arquivos menores, parsing muito rápido). | Inferior (arquivos maiores, parsing custoso para CPU). |
| Legibilidade humana | Nula (é formato binário). | Alta (qualquer pessoa consegue ler). |
| Casos de uso | Sistemas críticos, alto tráfego, mobile (economia de bateria/dados). | Configurações, APIs Web, armazenamento de dados simples. |
3. Leitura de um Arquivo .proto
Aqui está um exemplo clássico de um serviço de biblioteca.
Conteúdo do Arquivo (biblioteca.proto):
syntax = "proto3"; // Define a versão da sintaxe do Protobuf
package biblioteca; // Namespace para evitar conflitos de nomes
// Definição do Serviço (a "interface" que o servidor vai implementar)
service SistemaBiblioteca {
// Um método RPC: recebe um ID e retorna um Livro
rpc BuscarLivro (BuscaLivroRequest) returns (LivroResponse);
}
// Mensagem de requisição (Input)
message BuscaLivroRequest {
string id_livro = 1; // Campo string, tag numérica 1
}
// Mensagem de resposta (Output)
message LivroResponse {
string titulo = 1; // Título do livro
string autor = 2; // Autor do livro
int32 ano_publicacao = 3; // Ano (inteiro)
bool disponivel = 4; // Se está disponível para empréstimo
}Explicação dos Comentários:
syntax = "proto3": Indica que estamos usando a versão mais moderna.service: Define o contrato da API. É aqui que dizemos “O servidor sabe fazer a açãoBuscarLivro“.rpc: A palavra-chave que define um método remoto.message: Define a estrutura dos dados (como uma struct em C ou class em Java).= 1,= 2: Importante: Esses não são valores atribuídos, são tags numéricas únicas. O Protobuf usa esses números para identificar os campos no binário, economizando espaço por não enviar o nome do campo (ex: ele envia o campo1em vez da palavra “titulo”).
Diagrama de Fluxo:
graph TB
A["Cliente (Chama BuscarLivro)"] -->|"Stub serializa para Binário"| B("Rede HTTP/2")
B -->|"Servidor recebe Binário"| C["Servidor (Deserializa)"]
C -->|"Executa Lógica"| D{"Livro Encontrado?"}
D -->|"Serializa Resposta"| B
B -->|"Retorna Binário"| A
4. Estudo de Caso: Netflix
- Contexto: A Netflix migrou de uma arquitetura monolítica para microsserviços. Eles têm milhares de serviços conversando entre si para montar a sua página inicial (recomendações, lista de filmes, status da conta).
- Uso do gRPC: A Netflix utiliza gRPC massivamente para a comunicação Leste-Oeste (comunicação interna entre os servidores deles).
- Por que faz sentido: Com milhões de requisições por segundo, economizar milissegundos na serialização do JSON e reduzir o tamanho dos pacotes de rede resulta em uma economia gigantesca de infraestrutura e latência menor para o usuário final. O contrato rígido do
.protoimpede que uma atualização em um serviço quebre outro serviço dependente. - Uso Combinado: Sim! Eles usam REST/GraphQL na borda (Edge), ou seja, na comunicação entre o seu aplicativo de TV/Celular e os servidores da Netflix, mas usam gRPC lá dentro, na comunicação profunda entre os servidores.
5. Reflexão Crítica
Vale aprender RPC na era REST?
Sim. Embora o REST domine a web pública, o mercado de desenvolvimento backend de alta performance (bancos digitais, streaming, big tech) exige gRPC. Aprender RPC ensina sobre contratos de interface, tipos de dados e eficiência de rede, conceitos que tornam você um engenheiro melhor, mesmo se usar REST.
Situações onde REST é preferível
REST ainda é rei para APIs Públicas. Se você quer que qualquer desenvolvedor no mundo integre com seu sistema usando apenas um navegador e documentação simples, REST (com JSON) é imbatível pela sua facilidade de leitura e ferramentas universais.
Principal desafio para equipes iniciantes
A Curva de Aprendizado e Tooling. Configurar o compilador protoc, gerar os códigos automáticos e debugar um erro que está em formato binário (ilegível) é frustrante para quem está acostumado a ver o JSON na tela. Exige uma cultura de engenharia mais disciplinada em manter os arquivos .proto organizados.