Objetivos de Aprendizagem

• Conhecer a arquitetura interna do gRPC.
• Entender como o gRPC se baseia no HTTP/2 para multiplexação e comunicação.
• Avaliar trade‑offs entre REST/JSON e gRPC/Protobuf.

Microsserviços

Definição: Um estilo arquitetural onde uma aplicação é estruturada como um conjunto de serviços pequenos, independentes e fracamente acoplados.

Princípios Fundamentais

1. Desacoplamento (Loose Coupling): Serviços comunicam-se via APIs bem definidas, permitindo evolução independente.
2. Deploy Independente: Mudanças em um serviço não exigem recompilação ou redeploy do sistema inteiro.
3. Especialização de Dados: Cada serviço gerencia seu próprio modelo de dados (Database per Service).

Comunicação via HTTP

• Microsserviços são frequentemente programados para se comunicar via REST.
• REST não é um protocolo, mas um estilo arquitetural.

• Stateless: Cada requisição deve conter todas as informações necessárias para ser processada.
• Client-Server: Separação clara entre quem consome a API e quem fornece os recursos.
• Cacheable: Respostas devem indicar se podem ser armazenadas em cache.
• Uniform Interface: Padronização de como clientes e servidores interagem (URIs, métodos HTTP).

Fonte da imagem ao lado: SystemDesign.us Blog

REpresentational State Transfer (REST)

GET    /api/alunos/123         # Leitura
POST   /api/alunos             # Criação
PUT    /api/alunos/123         # Atualização
DELETE /api/alunos/123         # Exclusão

{
    "id": "123",
    "email": "ana@exemplo.com",
    "idade": 25
}

Limitação do Tradicional REST/JSON

• Overhead: Serialização JSON é verbosa. Grande consumo de banda.
• Contrato Fraco: Falta tipagem forte entre o cliente e o servidor.
• Problema: Em microsserviços internos (Service-to-Service), precisamos de mais eficiência.
• Exemplo: Um sistema com 50 microsserviços REST precisa enviar milhões de pequenos JSONs, gastando muita banda desnecessariamente.

Problema na Comunicação de Dados: Exemplo

• Contexto: Desenvolvimento de uma agenda de contatos simples em arquitetura cliente-servidor.
  • Estrutura: Nome, ID, Email, Telefone.
  • Requisito: Capacidade de leitura e escrita desses dados em um stream ou arquivo persistente.
• Quais alternativas no contexto de comunicação via HTTP?

Problema na Comunicação de Dados: Exemplo (cont.)

• Contexto: Desenvolvimento de uma agenda de contatos simples em arquitetura cliente-servidor.
  • Estrutura: Nome, ID, Email, Telefone.
  • Requisito: Capacidade de leitura e escrita desses dados em um stream ou arquivo persistente.
• Alternativas:
  • Python Pickling: Serialização nativa da linguagem. Baixa interoperabilidade (com C++ ou Java, por exemplo).
  • XML: Linguagem baseada em marcação (DOM). Consumo excessivo de espaço (space-intensive).
  • Ad-Hoc: Criar seu próprio parser e codificador. Boa sorte...

Exemplo baseado em https://protobuf.dev/getting-started/pythontutorial/

Remote Procedure Call (RPC)

def mult(a, b):
    return a * b

def main():
    l = mult(5, 7)
    k = add(1, 5)

def add(i, j):
    return i + j

Visão geral do gRPC

• gRPC (Google Remote Procedure Call): Um framework de comunicação.
• Permite chamar métodos em um servidor remoto como se fossem locais.
• Transporte: HTTP/2.
• Serialização padrão: Protocol Buffers.
• Modelos de chamada: Unary, Server Streaming, Client Streaming, Bidirectional.

Fonte da imagem ao lado: bytebytego

Por que precisamos de gRPC?

• HTTP/1.1 sofre com Head‑of‑Line Blocking: paralelismo limitado.
• Necessidade de parsing complexo para ignorar comentários ou espaços extras; vulnerável a ataques de injeção de linha.
• APIs modernas exigem latência baixa e streaming (ex.: microsserviços).
• gRPC oferece RPCs tipados, multiplexação e compressão de cabeçalhos.

Fonte da imagem ao lado: Cloudfare

HTTP/2

Protocol Buffers (Protobuf)

edition = "2023";

package addressbook;

message Person {
  string name = 1;
  int32 id = 2;
  string email = 3;

  enum PhoneType {
    PHONE_TYPE_MOBILE = 1;
    PHONE_TYPE_WORK = 2;
  }

  message PhoneNumber {
    string number = 1;
    PhoneType type = 1 [default = PHONE_TYPE_MOBILE];
  }

  repeated PhoneNumber phones = 4;
}

message AddressBook {
  repeated Person people = 1;
}

Protocol Buffers (Protobuf)

edition = "2023";

package addressbook;

message Person {
  string name = 1;
  int32 id = 2;
  string email = 3;

  enum PhoneType {
    PHONE_TYPE_MOBILE = 1;
    PHONE_TYPE_WORK = 2;
  }

  message PhoneNumber {
    string number = 1;
    PhoneType type = 1 [default = PHONE_TYPE_MOBILE];
  }

  repeated PhoneNumber phones = 4;
}

message AddressBook {
  repeated Person people = 1;
}

Como o gRPC usa HTTP/2

Multiplexação: Permite enviar múltiplos streams em uma única conexão TCP.

• Compressão eficiente: Compacta cabeçalhos (HPACK), economizando banda.
• Controle de fluxo por flow‑control windows.

Métodos de Streaming RPC

• 1. Unary RPC: A chamada clássica (Cliente Servidor, Resposta única).
• 2. Server Streaming: Cliente envia 1x. Servidor devolve um fluxo de dados contínuo.
• 3. Client Streaming: Cliente envia um fluxo contínuo de dados. Servidor responde uma vez com o resultado final.
• 4. Bidirectional Streaming: Fluxo constante e simultâneo nas duas direções.

Limitações

• Acoplamento Forte (Tight Coupling): O cliente depende da interface binária específica do servidor, o que pode dificultar a evolução independente dos componentes.
• Complexidade de Versioning: Alterações no esquema do serviço (schema evolution) exigem atualização simultânea ou migração gradual complexa, gerando problemas de compatibilidade retroativa.
• Descoberta de Serviços Limitada: O cliente precisa conhecer antecipadamente a estrutura dos métodos disponíveis.

Modo híbrido: REST + API Gateway + gRPC

• REST para requisições externas via API Gateway.
• Comunicação interna via gRPC.

Conclusão e Próximos Passos

• REST/HTTP: Melhor para APIs Client-to-Gateway (externa). Simples, fácil consumo por navegadores e terceiros.
• gRPC: Ideal para comunicação Service-to-Service (interna). Alta performance, exige contrato estrito.
• Protobuf: Define um contrato binário de alto desempenho.
• HTTP/2: Base para baixa latência e multiplexação.
• Comunicação Híbrida em Microsserviços: Usar gRPC dentro do seu backend de microsserviços e expor uma camada REST ou GraphQL no Edge/API Gateway.
  • Exemplo: O front-end (cliente) fala REST com o API Gateway, que por sua vez usa gRPC para conversar otimamente com os serviços internos.
• Material Adicional: Protocol Buffers Crash Course | 99% of Developers Don't Get gRPC | gRPC Dicionário do Programador |

Exercícios Teóricos

1. (Conceito) Qual é o principal benefício de usar Protocol Buffers (Protobuf) em comparação com JSON?
2. (Definição) O que significa dizer que um sistema utiliza "tipagem forte" no contexto do gRPC?
3. (Identificação) Qual protocolo de transporte deve ser usado pelo gRPC para garantir a eficiência e o streaming avançado?
4. (Comparação) Um time decide criar uma API pública que será consumida por diversos aplicativos legados (que só entendem JSON). Onde, dentro da arquitetura de microsserviços, seria mais apropriado usar gRPC e onde deveria ser usado REST? Justifique a separação.

Lab Prático 1

Siga o tutorial do Google Codelabs Getting Started with gRPC-Python.

Para outras linguagens de programação, siga os tutoriais em https://grpc.io/ e https://protobuf.dev/getting-started/

Lab Prático 2

Objetivo: Implementar a leitura e atualização de dados simples em um serviço centralizado.

Você está construindo o módulo de perfil de usuário de uma plataforma. Este módulo deve interagir com um serviço remoto para buscar informações e atualizar campos específicos.

Componentes:

• Mensagem UserRequest: Deve conter apenas o user_id (string).
• Mensagem UserResponse: Deve conter user_id, name e email.
• Serviço UserService com dois métodos:
  • GetUserDetails(UserRequest): Retorna um único UserResponse. Simule buscar um usuário (pode ser um dicionário estático) baseado no ID fornecido. Se o usuário não existir, lance uma exceção apropriada.
  • UpdateEmail(UserRequest, UserResponse): Recebe o ID e retorna uma confirmação de sucesso. Imprima um log simulando a atualização bem-sucedida no banco de dados.

Dúvidas e Discussão