{"id":25615293,"url":"https://github.com/eneas-almeida/grpc","last_synced_at":"2026-05-18T04:05:41.427Z","repository":{"id":220822644,"uuid":"752265615","full_name":"eneas-almeida/grpc","owner":"eneas-almeida","description":"📜 Guia gRPC, elaborado por Enéas Almeida com o principal objetivo de facilitar os repasses de informações à equipe.","archived":false,"fork":false,"pushed_at":"2025-12-17T20:18:50.000Z","size":751,"stargazers_count":0,"open_issues_count":0,"forks_count":0,"subscribers_count":1,"default_branch":"main","last_synced_at":"2025-12-21T05:36:40.779Z","etag":null,"topics":["evans","golang","grpc","protobuf","reflection","sqlite3"],"latest_commit_sha":null,"homepage":"","language":"Go","has_issues":true,"has_wiki":null,"has_pages":null,"mirror_url":null,"source_name":null,"license":null,"status":null,"scm":"git","pull_requests_enabled":true,"icon_url":"https://github.com/eneas-almeida.png","metadata":{"files":{"readme":"README.md","changelog":null,"contributing":null,"funding":null,"license":null,"code_of_conduct":null,"threat_model":null,"audit":null,"citation":null,"codeowners":null,"security":null,"support":null,"governance":null,"roadmap":null,"authors":null,"dei":null,"publiccode":null,"codemeta":null}},"created_at":"2024-02-03T14:26:02.000Z","updated_at":"2025-12-17T20:18:53.000Z","dependencies_parsed_at":"2024-02-11T15:30:22.633Z","dependency_job_id":"42d8f87d-3a38-40c1-9e95-e83d45feb467","html_url":"https://github.com/eneas-almeida/grpc","commit_stats":null,"previous_names":["venzel/grpc","eneas-almeida/grpc"],"tags_count":0,"template":false,"template_full_name":null,"purl":"pkg:github/eneas-almeida/grpc","repository_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/repositories/eneas-almeida%2Fgrpc","tags_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/repositories/eneas-almeida%2Fgrpc/tags","releases_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/repositories/eneas-almeida%2Fgrpc/releases","manifests_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/repositories/eneas-almeida%2Fgrpc/manifests","owner_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/owners/eneas-almeida","download_url":"https://codeload.github.com/eneas-almeida/grpc/tar.gz/refs/heads/main","sbom_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/repositories/eneas-almeida%2Fgrpc/sbom","scorecard":null,"host":{"name":"GitHub","url":"https://github.com","kind":"github","repositories_count":286080680,"owners_count":33164672,"icon_url":"https://github.com/github.png","version":null,"created_at":"2022-05-30T11:31:42.601Z","updated_at":"2026-05-17T22:39:12.733Z","status":"online","status_checked_at":"2026-05-18T02:00:06.436Z","response_time":71,"last_error":null,"robots_txt_status":"success","robots_txt_updated_at":"2025-07-24T06:49:26.215Z","robots_txt_url":"https://github.com/robots.txt","online":true,"can_crawl_api":true,"host_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub","repositories_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/repositories","repository_names_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/repository_names","owners_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/owners"}},"keywords":["evans","golang","grpc","protobuf","reflection","sqlite3"],"created_at":"2025-02-22T03:19:08.086Z","updated_at":"2026-05-18T04:05:41.410Z","avatar_url":"https://github.com/eneas-almeida.png","language":"Go","funding_links":[],"categories":[],"sub_categories":[],"readme":"# gRPC - Guia Completo\n\n\u003e Este guia foi elaborado por **Enéas Almeida** com o principal objetivo de facilitar os repasses de informações à equipe.\n\n```\n  ____  ____   ____   ____\n / ___|  _ \\ / ___| / ___|\n| |  _| |_) | |    | |\n| |_| |  _ \u003c| |___ | |___\n \\____|_| \\_\\\\____| \\____|\n```\n\n## 📋 Índice\n\n- [O que é gRPC?](#o-que-é-grpc)\n- [Características Principais](#características-principais)\n- [Onde Utilizar](#onde-é-ideal-para-utilizar)\n- [Conceitos Fundamentais](#conceitos-fundamentais)\n- [Protocol Buffers](#protocol-buffers)\n- [HTTP/2](#http2)\n- [Tipos de Comunicação](#formatos-de-tráfego-entre-comunicação-grpc)\n- [REST vs gRPC](#rest-vs-grpc)\n- [Instalação e Configuração](#pré-requisitos)\n- [Comandos Úteis](#comandos)\n\n## O que é gRPC?\n\n**gRPC** (gRPC Remote Procedure Call) é um framework moderno de comunicação entre sistemas desenvolvido pelo Google que permite a comunicação eficiente e rápida entre serviços distribuídos.\n\n### Características Principais\n\n-   **Desenvolvedor:** Google\n-   **Mantenedor:** CNCF (Cloud Native Computing Foundation) - mesma organização que mantém Kubernetes e OpenTelemetry\n-   **Lançamento:** Fevereiro de 2015\n-   **Licença:** Código aberto\n-   **Protocolo:** HTTP/2\n-   **Serialização:** Protocol Buffers (protobuf)\n-   **Performance:** Alta velocidade com baixa latência\n-   **Segurança:** Suporte nativo a TLS/SSL\n-   **Independência:** Agnóstico de linguagem de programação\n\n## Links importantes\n\n-   [grpc.io](https://grpc.io/) - Site oficial do gRPC.\n-   [protobuf.dev](https://protobuf.dev/) - Manual Protocol Buffers.\n\n## Onde é ideal para utilizar?\n\n-   Microsserviços;\n-   Aplicações em tempo real;\n-   Sistemas distribuídos;\n-   Aplicações IOT;\n-   Streaming de dados.\n\n## Linguagens com suporte oficial\n\n-   Go\n-   Java\n-   C\n\nAtravés do gRPC-C é possível utilizar python, nodejs, kotlin e etc.\n\n## Conceitos Fundamentais\n\n### O que significa na prática o Remote Procedure Call (RPC)?\n\nRPC permite que um programa execute uma função/procedimento em outro espaço de endereçamento (geralmente em outra máquina) como se fosse uma chamada local.\n\n```\n┌─────────────────────────────────────────────────────────────────┐\n│                     ARQUITETURA gRPC                            │\n└─────────────────────────────────────────────────────────────────┘\n\n    Cliente                                         Servidor\n    ┌──────┐                                        ┌──────┐\n    │      │                                        │      │\n    │ App  │                                        │ App  │\n    │      │                                        │      │\n    └──┬───┘                                        └───┬──┘\n       │                                                │\n       │  ┌──────────────────────────────────┐          │\n       │  │    1. Chamada de Método          │          │\n       ├──┼─────────────────────────────────►│          │\n       │  │    getAccount(id: \"123\")         │          │\n       │  └──────────────────────────────────┘          │\n       │                                                │\n    ┌──┴───────┐                               ┌────────┴───┐\n    │  gRPC    │   ◄───── HTTP/2 ─────►        │   gRPC     │\n    │  Stub    │                               │   Server   │\n    └──┬───────┘                               └────────┬───┘\n       │                                                │\n       │  ┌──────────────────────────────────┐          │\n       │  │    2. Serialização Protobuf      │          │\n       │  │    ┌────────────────┐            │          │\n       │  │    │ Binary Data    │            │          │\n       │  │    │ [01010101...]  │            │          │\n       │  │    └────────────────┘            │          │\n       │  └──────────────────────────────────┘          │\n       │                                                │\n       │  ┌──────────────────────────────────┐          │\n       │  │    3. Transporte HTTP/2          │          │\n       ├──┼─────────────────────────────────►│          │\n       │  │    Headers + Binary Payload      │          │\n       │  └──────────────────────────────────┘          │\n       │                                                │\n       │                                             ┌──┴───┐\n       │                                             │ Exec │\n       │                                             │ Func │\n       │                                             └──┬───┘\n       │                                                │\n       │  ┌──────────────────────────────────┐          │\n       │  │    4. Resposta (Protobuf)        │          │\n       │  │◄─────────────────────────────────┼──────────┤\n       │  │    Account{id, name, email}      │          │\n       │  └──────────────────────────────────┘          │\n       │                                                │\n    ┌──┴───────┐                                    ┌───┴──┐\n    │ Processa │                                    │      │\n    │ Resposta │                                    │      │\n    └──────────┘                                    └──────┘\n\n\nFluxo Detalhado:\n─────────────────\n\n1. Cliente chama método como se fosse local\n2. gRPC Stub serializa parâmetros (Protobuf)\n3. Dados binários são enviados via HTTP/2\n4. Servidor deserializa e executa a função\n5. Resultado é serializado e retornado\n6. Cliente recebe e deserializa a resposta\n```\n\n**Evolução Histórica:**\n- **Passado:** XML-RPC, SOAP (XML) - verboso e lento\n- **Presente:** gRPC (Protobuf) - compacto e rápido\n- **Vantagem:** Contratos fortemente tipados (.proto files)\n\n## Protocol Buffers\n\nProtocol Buffers (Protobuf) é uma linguagem de definição de interface (IDL) criada pelo Google para serialização estruturada de dados.\n\n### Características do Protocol Buffers\n\n```\n┌────────────────────────────────────────────────────────────────┐\n│                    PROTOCOL BUFFERS WORKFLOW                   │\n└────────────────────────────────────────────────────────────────┘\n\n1. DEFINIÇÃO DO CONTRATO (.proto)\n   ┌─────────────────────────────────────┐\n   │ syntax = \"proto3\";                  │\n   │                                     │\n   │ message Account {                   │\n   │   string id = 1;                    │\n   │   string name = 2;                  │\n   │   string email = 3;                 │\n   │ }                                   │\n   └─────────────────────────────────────┘\n                  │\n                  │ protoc compiler\n                  ▼\n2. GERAÇÃO DE CÓDIGO\n   ┌─────────────────────────────────────┐\n   │  Go        │  Java    │  Python     │\n   │  ────────  │  ──────  │  ─────────  │\n   │  account.  │  Account │  account_   │\n   │  pb.go     │  .java   │  pb2.py     │\n   └─────────────────────────────────────┘\n                  │\n                  │\n                  ▼\n3. SERIALIZAÇÃO (Objeto → Binário)\n   ┌─────────────────────────────────────┐\n   │ Account Object                      │\n   │ ┌─────────────────────────────────┐ │\n   │ │ id: \"12345\"                     │ │\n   │ │ name: \"João Silva\"              │ │\n   │ │ email: \"joao@email.com\"         │ │\n   │ └─────────────────────────────────┘ │\n   └─────────────────────────────────────┘\n                  │\n                  │ Marshal/Encode\n                  ▼\n   ┌─────────────────────────────────────┐\n   │ Binary Format (Compact)             │\n   │ [0x0a 0x05 0x31 0x32 0x33 0x34...]  │\n   │ Tamanho: ~45 bytes                  │\n   └─────────────────────────────────────┘\n                  │\n                  │ Network Transfer\n                  ▼\n4. DESERIALIZAÇÃO (Binário → Objeto)\n   ┌─────────────────────────────────────┐\n   │ Unmarshal/Decode                    │\n   │                                     │\n   │ Account Object (Reconstruído)       │\n   └─────────────────────────────────────┘\n```\n\n### Vantagens do Protocol Buffers\n\n-   **Formato Binário:** Dados compactos e eficientes\n-   **Contratos Tipados:** Validação em tempo de compilação\n-   **Serialização Rápida:** Alto desempenho (CPU eficiente)\n-   **Baixo Consumo de Rede:** Arquivos 3-10x menores que JSON\n-   **Retrocompatibilidade:** Evolução de schema sem quebrar compatibilidade\n-   **Multi-linguagem:** Geração automática de código\n-   **Independente:** Pode ser usado sem gRPC\n\n### Protocol Buffers vs JSON\n\n```\n┌────────────────────────────────────────────────────────────────┐\n│              COMPARAÇÃO: PROTOBUF vs JSON                      │\n└────────────────────────────────────────────────────────────────┘\n\nEXEMPLO: Objeto Account\n──────────────────────────────────────────────────────────────────\n\nJSON (Texto)                      │  Protobuf (Binário)\n──────────────────────────────────┼──────────────────────────────\n{                                 │  [Binary Data]\n  \"id\": \"12345\",                  │  0x0a 0x05 0x31 0x32 0x33\n  \"name\": \"João Silva\",           │  0x34 0x35 0x12 0x0b 0x4a\n  \"email\": \"joao@email.com\"       │  0xc3 0xa3 0x6f 0x20 0x53\n}                                 │  ... [compressed]\n                                  │\nTamanho: ~98 bytes                │  Tamanho: ~45 bytes\n──────────────────────────────────┼──────────────────────────────\n✗ Texto legível                   │  ✓ Binário otimizado\n✗ Parsing mais lento              │  ✓ Parsing 3-10x mais rápido\n✗ Mais bytes na rede              │  ✓ Menos uso de banda\n✗ Sem validação de tipo           │  ✓ Validação forte de tipos\n✓ Human-readable                  │  ✗ Não legível (requer decode)\n✓ Debugging mais fácil            │  ✗ Requer ferramentas especiais\n\n\nPERFORMANCE BENCHMARK\n──────────────────────────────────────────────────────────────────\nMétrica              │ JSON       │ Protobuf    │ Ganho\n─────────────────────┼────────────┼─────────────┼─────────────────\nSerialização         │ 1000 ns    │ 300 ns      │ 3.3x\nDeserialização       │ 1200 ns    │ 400 ns      │ 3.0x\nTamanho (10KB JSON)  │ 10,000 B   │ 3,000 B     │ 3.3x\nCPU (Serialize 1M)   │ 100%       │ 30%         │ 3.3x\nUso de Memória       │ Alto       │ Baixo       │ 2-3x\n```\n\n### Estrutura de um Arquivo .proto\n\n```proto\nsyntax = \"proto3\";  // Versão do Protocol Buffers\n\npackage pb;  // Namespace do pacote\n\noption go_package = \"./pb\";  // Caminho de geração para Go\n\n// Definição de mensagem (estrutura de dados)\nmessage Account {\n  string id = 1;      // Campo 1: identificador único\n  string name = 2;    // Campo 2: nome da conta\n  string email = 3;   // Campo 3: email da conta\n}\n\n// Definição de serviço (APIs disponíveis)\nservice AccountService {\n  rpc CreateAccount (Account) returns (Account);\n  rpc GetAccount (AccountRequest) returns (Account);\n  rpc ListAccounts (Empty) returns (stream Account);\n}\n\nmessage AccountRequest {\n  string id = 1;\n}\n\nmessage Empty {}\n```\n\n**Padrão:** Arquivo `.proto` (protofile)\n**Versão Recomendada:** `proto3` (para gRPC)\n**Compilador:** `protoc` (Protocol Buffer Compiler)\n\n## HTTP/2\n\nHTTP/2 é a base de transporte do gRPC, oferecendo recursos avançados para comunicação eficiente.\n\n### Características do HTTP/2\n\n```\n┌────────────────────────────────────────────────────────────────┐\n│                HTTP/1.1 vs HTTP/2 COMPARISON                   │\n└────────────────────────────────────────────────────────────────┘\n\nHTTP/1.1 (Texto)                  HTTP/2 (Binário)\n─────────────────────────────────────────────────────────────────\n\nMÚLTIPLAS REQUISIÇÕES:\n──────────────────────────────────────────────────────────────────\nCliente          Servidor        Cliente          Servidor\n   │                │               │                │\n   ├──── Req 1 ────►│               ├──┬─ Req 1 ────►│\n   │                │               │  ├─ Req 2 ────►│\n   │◄─── Res 1 ─────┤               │  └─ Req 3 ────►│\n   │                │               │                │\n   ├──── Req 2 ────►│               │◄─┬─ Res 1 ─────┤\n   │                │               │  ├─ Res 3 ─────┤\n   │◄─── Res 2 ─────┤               │  └─ Res 2 ─────┤\n   │                │               │                │\n   ├──── Req 3 ────►│             MULTIPLEXING:\n   │                │             Uma única conexão TCP!\n   │◄─── Res 3 ─────┤\n   │                │\n3 conexões TCP                    1 conexão TCP\n\n\nESTRUTURA DE FRAMES:\n──────────────────────────────────────────────────────────────────\n┌─────────────────────────────────────────────────────────────┐\n│                      HTTP/2 FRAME                           │\n├───────────┬─────────────────────────────────────────────────┤\n│  Header   │  Length (24) │ Type (8) │ Flags (8) │  Stream   │\n│  (9 bytes)│              │          │           │  ID(31)   │\n├───────────┼─────────────────────────────────────────────────┤\n│  Payload  │                                                 │\n│  (N bytes)│              Frame Data                         │\n│           │                                                 │\n└───────────┴─────────────────────────────────────────────────┘\n\nFrame Types:\n• HEADERS    - Metadados da requisição/resposta\n• DATA       - Payload da mensagem\n• SETTINGS   - Configurações da conexão\n• PING       - Keep-alive\n• GOAWAY     - Encerramento da conexão\n\n\nMULTIPLEXING EM AÇÃO:\n──────────────────────────────────────────────────────────────────\n    Conexão TCP Única\n    ═════════════════════════════════════════════\n\n    Stream 1  ────►  [HEADERS] [DATA] [DATA]\n    Stream 3  ────►  [HEADERS] [DATA]\n    Stream 5  ────►  [HEADERS] [DATA]\n    Stream 7  ────►  [HEADERS] [DATA]\n\n    ⬇ Mesma Conexão TCP ⬇\n\n    Stream 1  ◄────  [HEADERS] [DATA]\n    Stream 3  ◄────  [HEADERS] [DATA]\n    Stream 5  ◄────  [HEADERS] [DATA]\n    Stream 7  ◄────  [HEADERS] [DATA] [DATA]\n\n\nSERVER PUSH:\n──────────────────────────────────────────────────────────────────\nCliente                          Servidor\n   │                                │\n   ├──── Request: index.html ──────►│\n   │                                │\n   │◄──── Response: index.html ─────┤\n   │◄──── Push: style.css ──────────┤  (Antecipado!)\n   │◄──── Push: script.js ──────────┤  (Antecipado!)\n   │                                │\n   (Cliente recebe recursos antes de solicitar)\n\n\nCOMPRESSÃO DE HEADERS (HPACK):\n──────────────────────────────────────────────────────────────────\nRequest 1:\n┌────────────────────────────────────────┐\n│ :method: GET                           │\n│ :path: /api/accounts/123               │\n│ :authority: api.example.com            │\n│ user-agent: grpc-go/1.50.0             │\n│ content-type: application/grpc+proto   │\n└────────────────────────────────────────┘\nTamanho: ~200 bytes\n\nRequest 2 (mesma conexão):\n┌────────────────────────────────────────┐\n│ [2] [3]                    ← Referências\n│ :path: /api/accounts/456   ← Só o diff\n└────────────────────────────────────────┘\nTamanho: ~15 bytes (93% menor!)\n```\n\n### Benefícios do HTTP/2 para gRPC\n\n-   **Origem:** Criado pela Google como projeto SPDY\n-   **Lançamento:** Maio de 2015 (RFC 7540)\n-   **Formato Binário:** Parsing mais eficiente que texto\n-   **Multiplexing:** Múltiplas requisições simultâneas em uma conexão TCP\n-   **Server Push:** Servidor pode enviar recursos proativamente\n-   **Header Compression (HPACK):** Redução de overhead\n-   **Priorização de Streams:** Controle de precedência de requisições\n-   **Flow Control:** Gerenciamento de backpressure\n-   **Baixa Latência:** Reduz roundtrips\n-   **Economia de Recursos:** Menos conexões TCP = menos overhead\n\n### HTTP/2 vs HTTP/1.1\n\n| Característica | HTTP/1.1 | HTTP/2 |\n|---|---|---|\n| **Formato** | Texto | Binário |\n| **Conexões** | Múltiplas (6-8 por host) | Única por host |\n| **Multiplexing** | Não | Sim |\n| **Header Compression** | Não | Sim (HPACK) |\n| **Server Push** | Não | Sim |\n| **Priorização** | Não | Sim |\n| **Performance** | Moderada | Alta |\n| **Latência** | Alta (head-of-line blocking) | Baixa |\n\n## Formatos de tráfego entre comunicação gRPC\n\ngRPC suporta 4 padrões de comunicação distintos, cada um otimizado para diferentes casos de uso.\n\n### 1. Unary RPC (Requisição-Resposta Simples)\n\nO padrão mais comum, similar ao REST tradicional: uma requisição, uma resposta.\n\n```\n┌──────────────────────────────────────────────────────────────┐\n│                      UNARY RPC FLOW                          │\n└──────────────────────────────────────────────────────────────┘\n\nCliente                                    Servidor\n────────                                   ─────────\n\n  [App]                                      [App]\n    │                                          │\n    │  1. Chamada do método                    │\n    ├──────────────────────────────────────►   │\n    │  GetAccount(id: \"123\")                   │\n    │                                          │\n    │                                       ┌──┴──┐\n    │                                       │Query│\n    │                                       │ DB  │\n    │                                       └──┬──┘\n    │                                          │\n    │  2. Resposta única                       │\n    │  ◄───────────────────────────────────────┤\n    │  Account{id, name, email}                │\n    │                                          │\n    ▼                                          ▼\n [Processa]                                 [Done]\n\n\nEXEMPLO DE CÓDIGO (.proto):\n────────────────────────────────────────────────────────────────\nservice AccountService {\n  rpc GetAccount(AccountRequest) returns (Account);\n}\n\nUSO TÍPICO:\n• APIs CRUD básicas (Create, Read, Update, Delete)\n• Validações simples\n• Operações síncronas\n• Substituição direta de REST/HTTP APIs\n\n\nFLUXO TEMPORAL:\n────────────────────────────────────────────────────────────────\nt=0ms    Cliente envia requisição\nt=50ms   Servidor recebe e processa\nt=100ms  Servidor envia resposta\nt=150ms  Cliente recebe resposta\n\nTotal: ~150ms (roundtrip completo)\n```\n\n### 2. Server Streaming RPC (Servidor Envia Múltiplas Respostas)\n\nCliente envia uma requisição e recebe um stream de múltiplas respostas do servidor.\n\n```\n┌──────────────────────────────────────────────────────────────┐\n│                  SERVER STREAMING RPC FLOW                   │\n└──────────────────────────────────────────────────────────────┘\n\nCliente                                    Servidor\n────────                                   ─────────\n\n  [App]                                      [App]\n    │                                          │\n    │  1. Requisição única                     │\n    ├──────────────────────────────────────►   │\n    │  ListAccounts(filter)                    │\n    │                                          │\n    │                                       ┌──┴──┐\n    │  2. Stream de respostas               │Query│\n    │  ◄──────────────────────────────────┐ │ DB  │\n    │  Account #1                         │ └──┬──┘\n    ├─► [Processa]                        │    │\n    │                                     │    │\n    │  ◄──────────────────────────────────┤    │\n    │  Account #2                         │    │\n    ├─► [Processa]                        │    │\n    │                                     │    │\n    │  ◄──────────────────────────────────┤    │\n    │  Account #3                         │    │\n    ├─► [Processa]                        │    │\n    │                                     │    │\n    │  ◄──────────────────────────────────┤    │\n    │  Account #N                         │    │\n    ├─► [Processa]                        │    │\n    │                                     │    │\n    │  ◄──────────────────────────────────┘    │\n    │  [END OF STREAM]                         │\n    │                                          │\n    ▼                                          ▼\n [Complete]                                 [Done]\n\n\nEXEMPLO DE CÓDIGO (.proto):\n────────────────────────────────────────────────────────────────\nservice AccountService {\n  rpc ListAccounts(ListRequest) returns (stream Account);\n}\n\nUSO TÍPICO:\n• Listagem de grandes volumes de dados\n• Relatórios e exportações\n• Logs em tempo real\n• Notificações push\n• Dashboards com dados ao vivo\n• Download de arquivos em chunks\n\nVANTAGENS:\n• Cliente processa dados incrementalmente (menos memória)\n• Servidor pode enviar dados conforme processa (streaming)\n• Feedback mais rápido (primeira resposta chega antes)\n• Ideal para datasets grandes\n\n\nFLUXO TEMPORAL:\n────────────────────────────────────────────────────────────────\nt=0ms     Cliente envia requisição\nt=50ms    Servidor envia Account #1   ──► Cliente processa\nt=100ms   Servidor envia Account #2   ──► Cliente processa\nt=150ms   Servidor envia Account #3   ──► Cliente processa\nt=200ms   Servidor envia Account #N   ──► Cliente processa\nt=250ms   Stream finalizado\n\nTotal: Cliente começa a processar em ~50ms!\n```\n\n### 3. Client Streaming RPC (Cliente Envia Múltiplas Requisições)\n\nCliente envia um stream de requisições e recebe uma única resposta do servidor.\n\n```\n┌──────────────────────────────────────────────────────────────┐\n│                  CLIENT STREAMING RPC FLOW                   │\n└──────────────────────────────────────────────────────────────┘\n\nCliente                                    Servidor\n────────                                   ─────────\n\n  [App]                                      [App]\n    │                                          │\n    │  1. Abre stream                          │\n    ├──────────────────────────────────────►   │\n    │                                          │\n    │  2. Envia dados #1                    ┌──┴───┐\n    ├──────────────────────────────────────►│Buffer│\n    │  Account{...}                         └──┬───┘\n    │                                          │\n    │  3. Envia dados #2                       │\n    ├──────────────────────────────────────►   │\n    │  Account{...}                            │\n    │                                          │\n    │  4. Envia dados #3                       │\n    ├──────────────────────────────────────►   │\n    │  Account{...}                            │\n    │                                          │\n    │  5. Envia dados #N                       │\n    ├──────────────────────────────────────►   │\n    │  Account{...}                            │\n    │                                          │\n    │  6. Fecha stream (EOF)                   │\n    ├──────────────────────────────────────►   │\n    │                                          │\n    │                                       ┌──┴──┐\n    │                                       │Batch│\n    │                                       │Save │\n    │                                       └──┬──┘\n    │                                          │\n    │  7. Resposta final                       │\n    │  ◄───────────────────────────────────────┤\n    │  Summary{total: N, success: M}           │\n    │                                          │\n    ▼                                          ▼\n [Complete]                                 [Done]\n\n\nEXEMPLO DE CÓDIGO (.proto):\n────────────────────────────────────────────────────────────────\nservice AccountService {\n  rpc CreateAccounts(stream Account) returns (Summary);\n}\n\nUSO TÍPICO:\n• Upload de arquivos grandes em chunks\n• Importação em lote (batch insert)\n• Telemetria e métricas (envio contínuo)\n• Agregações de dados\n• Backup incremental\n\nVANTAGENS:\n• Cliente envia dados conforme disponíveis\n• Servidor processa em lote (mais eficiente)\n• Reduz overhead de múltiplas conexões\n• Ideal para uploads e batch operations\n\n\nFLUXO TEMPORAL:\n────────────────────────────────────────────────────────────────\nt=0ms     Cliente abre stream\nt=10ms    Cliente envia Account #1\nt=20ms    Cliente envia Account #2\nt=30ms    Cliente envia Account #3\nt=40ms    Cliente envia Account #N\nt=50ms    Cliente fecha stream\nt=100ms   Servidor processa todos os dados\nt=150ms   Servidor envia resposta final\n\nTotal: ~150ms (mas dados enviados incrementalmente)\n```\n\n### 4. Bidirectional Streaming RPC (Comunicação Bidirecional)\n\nTanto cliente quanto servidor enviam streams de dados de forma independente e assíncrona.\n\n```\n┌──────────────────────────────────────────────────────────────┐\n│              BIDIRECTIONAL STREAMING RPC FLOW                │\n└──────────────────────────────────────────────────────────────┘\n\nCliente                                    Servidor\n────────                                   ─────────\n\n  [App]                                      [App]\n    │                                          │\n    │  1. Abre stream bidirecional             │\n    ├═════════════════════════════════════════►│\n    │                                          │\n    │  2. Cliente envia msg #1                 │\n    ├──────────────────────────────────────►   │\n    │  CreateAccount{name: \"João\"}             │\n    │                                          │\n    │                                       [Processa]\n    │                                          │\n    │  3. Servidor responde msg #1             │\n    │  ◄───────────────────────────────────────┤\n    │  Account{id: \"123\", name: \"João\"}        │\n    ├─► [Processa]                             │\n    │                                          │\n    │  4. Cliente envia msg #2                 │\n    ├──────────────────────────────────────►   │\n    │  CreateAccount{name: \"Maria\"}            │\n    │                                          │\n    │  5. Servidor responde msg #2             │\n    │  ◄───────────────────────────────────────┤\n    │  Account{id: \"124\", name: \"Maria\"}       │\n    ├─► [Processa]                             │\n    │                                          │\n    │  6. Cliente envia msg #3                 │\n    ├──────────────────────────────────────►   │\n    │  CreateAccount{name: \"Pedro\"}            │\n    │                                          │\n    │  7. Servidor responde msg #3             │\n    │  ◄───────────────────────────────────────┤\n    │  Account{id: \"125\", name: \"Pedro\"}       │\n    ├─► [Processa]                             │\n    │                                          │\n    │  ◄───────────────────────────────────────┤\n    │  [Servidor pode enviar a qualquer momento]\n    │                                          │\n    │  8. Ambos fecham stream                  │\n    ├═════════════════════════════════════════►│\n    │                                          │\n    ▼                                          ▼\n [Complete]                                 [Done]\n\n\nCARACTERÍSTICAS IMPORTANTES:\n────────────────────────────────────────────────────────────────\n• Os streams são INDEPENDENTES:\n  - Cliente pode enviar sem esperar resposta\n  - Servidor pode responder fora de ordem\n  - Ambos podem enviar/receber simultaneamente\n\n• Ordem não é garantida (por padrão)\n• Full-duplex: comunicação simultânea nos dois sentidos\n• Streams podem ser fechados independentemente\n\n\nEXEMPLO DE CÓDIGO (.proto):\n────────────────────────────────────────────────────────────────\nservice AccountService {\n  rpc CreateAccountsStream(stream Account) returns (stream Account);\n}\n\nUSO TÍPICO:\n• Chat em tempo real\n• Jogos multiplayer\n• Trading de alta frequência\n• Sincronização de dados\n• Colaboração em tempo real (Google Docs style)\n• IoT com feedback bidirecional\n• Video/Audio streaming com controles\n\nVANTAGENS:\n• Latência ultra-baixa\n• Comunicação full-duplex\n• Não bloqueia (totalmente assíncrono)\n• Ideal para aplicações interativas em tempo real\n\n\nFLUXO TEMPORAL (Exemplo):\n────────────────────────────────────────────────────────────────\nt=0ms     Stream aberto\nt=10ms    Cliente → Servidor (msg #1)\nt=20ms    Servidor → Cliente (response #1)\nt=25ms    Cliente → Servidor (msg #2)\nt=30ms    Cliente processa response #1\nt=35ms    Servidor → Cliente (response #2)\nt=40ms    Cliente → Servidor (msg #3)\nt=45ms    Cliente processa response #2\nt=50ms    Servidor → Cliente (response #3)\n...\n(Comunicação contínua e assíncrona)\n```\n\n### Comparação dos 4 Padrões\n\n```\n┌────────────────────────────────────────────────────────────────┐\n│           COMPARAÇÃO DOS PADRÕES DE COMUNICAÇÃO                │\n└────────────────────────────────────────────────────────────────┘\n\nPadrão              │ Cliente → │ Servidor → │ Caso de Uso\n                    │  Servidor │  Cliente   │\n────────────────────┼───────────┼────────────┼────────────────────\n1. Unary            │  1 msg    │  1 msg     │ CRUD, APIs simples\n                    │           │            │\n2. Server Streaming │  1 msg    │  N msgs    │ Listagens, logs,\n                    │           │            │ notificações\n                    │           │            │\n3. Client Streaming │  N msgs   │  1 msg     │ Upload, batch,\n                    │           │            │ métricas\n                    │           │            │\n4. Bidirectional    │  N msgs   │  N msgs    │ Chat, jogos,\n    Streaming       │           │            │ real-time sync\n────────────────────┴───────────┴────────────┴────────────────────\n\n\nESCOLHA DO PADRÃO:\n──────────────────────────────────────────────────────────────────\n┌─────────────────────────────────────────────────────────────┐\n│  Precisa enviar/receber múltiplas mensagens?                │\n│                                                             │\n│  Não           Sim, mas só uma direção        Sim, ambas    │\n│   │                    │                          │         │\n│   ▼                    ▼                          ▼         │\n│ UNARY     Quem envia múltiplas?        BIDIRECTIONAL        │\n│           │                   │           STREAMING         │\n│           ▼                   ▼                             │\n│        Cliente           Servidor                           │\n│           │                   │                             │\n│           ▼                   ▼                             │\n│     CLIENT              SERVER                              │\n│     STREAMING           STREAMING                           │\n└─────────────────────────────────────────────────────────────┘\n```\n\n## REST vs gRPC\n\nComparação detalhada entre os dois paradigmas de comunicação mais populares para APIs.\n\n```\n┌────────────────────────────────────────────────────────────────┐\n│                    REST vs gRPC COMPARISON                     │\n└────────────────────────────────────────────────────────────────┘\n\nARQUITETURA DE COMUNICAÇÃO:\n─────────────────────────────────────────────────────────────────\n\nREST API                           gRPC API\n────────────────────────────────   ──────────────────────────────\n\nCliente                            Cliente\n  │                                  │\n  │ HTTP/1.1                         │ HTTP/2\n  │ JSON (Texto)                     │ Protobuf (Binário)\n  │                                  │\n  ├─► POST /api/accounts             ├─► CreateAccount()\n  │   {                              │   Account{...}\n  │     \"name\": \"João\",              │\n  │     \"email\": \"j@mail.com\"        │\n  │   }                              │\n  │                                  │\n  │◄─ 201 Created                    │◄─ Account{id, name, email}\n  │   {                              │\n  │     \"id\": \"123\",                 │\n  │     \"name\": \"João\",              │\n  │     \"email\": \"j@mail.com\"        │\n  │   }                              │\n  │                                  │\nServidor                           Servidor\n\n\nCARACTERÍSTICAS TÉCNICAS:\n────────────────────────────────────────────────────────────────\n\n┌─────────────────────┬──────────────────┬──────────────────┐\n│   Característica    │      REST        │      gRPC        │\n├─────────────────────┼──────────────────┼──────────────────┤\n│ Formato de Dados    │ JSON (Texto)     │ Protobuf (Bin.)  │\n│ Protocolo           │ HTTP/1.1         │ HTTP/2           │\n│ Contrato            │ OpenAPI/Swagger  │ .proto (forte)   │\n│ Geração de Código   │ Manual/Opcional  │ Automática       │\n│ Streaming           │ ✗ Não suportado  │ ✓ Bidirecional   │\n│ Browser Support     │ ✓ Nativo        │ ✗ Requer proxy   │\n│ Multiplexing        │ ✗ Não           │ ✓ Sim            │\n│ Latência            │ Alta            │ Baixa            │\n│ Payload Size        │ Grande           │ Pequeno (60%)    │\n│ Verbos/Métodos      │ GET/POST/PUT/DEL │ Customizáveis    │\n│ Tipo de Comunicação │ Unidirecional    │ Bidirecional     │\n│ Debugging           │ Fácil (cURL)     │ Requer tools     │\n│ Caching             │ ✓ HTTP Cache    │ ✗ Complexo       │\n│ Load Balancing      │ ✓ Padrão        │ ✓ Com config     │\n└─────────────────────┴──────────────────┴──────────────────┘\n\n\nEXEMPLO PRÁTICO - CRIAR UMA CONTA:\n────────────────────────────────────────────────────────────────\n\nREST:\n─────\nRequest:\n  POST /api/v1/accounts HTTP/1.1\n  Host: api.example.com\n  Content-Type: application/json\n  Authorization: Bearer token123\n\n  {\n    \"name\": \"João Silva\",\n    \"email\": \"joao@example.com\"\n  }\n\nResponse:\n  HTTP/1.1 201 Created\n  Content-Type: application/json\n\n  {\n    \"id\": \"acc_123\",\n    \"name\": \"João Silva\",\n    \"email\": \"joao@example.com\",\n    \"created_at\": \"2024-01-15T10:30:00Z\"\n  }\n\n  Tamanho Total: ~250 bytes\n\n\ngRPC:\n─────\nRequest:\n  POST /AccountService/CreateAccount HTTP/2\n  content-type: application/grpc+proto\n\n  [Binary Protobuf Data]\n  0x0a 0x0b 0x4a 0xc3 0xa3 0x6f 0x20 0x53...\n\nResponse:\n  HTTP/2 200 OK\n  content-type: application/grpc+proto\n\n  [Binary Protobuf Data]\n  0x0a 0x07 0x61 0x63 0x63 0x5f 0x31 0x32...\n\n  Tamanho Total: ~80 bytes (68% menor!)\n\n\nQUANDO USAR CADA UM:\n────────────────────────────────────────────────────────────────\n\nUSE REST QUANDO:                   USE gRPC QUANDO:\n───────────────────                ────────────────\n\n✓ APIs públicas/externas           ✓ Microserviços internos\n✓ Navegadores como clientes        ✓ Comunicação servidor-servidor\n✓ Simplicidade é prioridade        ✓ Performance crítica\n✓ Caching HTTP importante          ✓ Streaming necessário\n✓ Ferramentas familiares           ✓ Baixa latência essencial\n✓ Documentação OpenAPI             ✓ Contratos fortemente tipados\n✓ Compatibilidade ampla            ✓ Polyglot (múltiplas linguagens)\n✓ Debug fácil (cURL, Postman)      ✓ Real-time communication\n\n\nPERFORMANCE COMPARISON:\n────────────────────────────────────────────────────────────────\n\nMétrica                  REST          gRPC         Melhoria\n──────────────────────   ────────      ──────       ────────\nLatência (1 req)         50ms          20ms         2.5x\nThroughput               1000 req/s    7000 req/s   7x\nPayload (10KB JSON)      10,000 bytes  3,500 bytes  65% ↓\nSerialização             1000ns        300ns        3.3x\nCPU (10K reqs)           100%          40%          60% ↓\nMemória                  250MB         100MB        60% ↓\nConexões simultâneas     100           500          5x\n\n\nEXEMPLO DE ARQUITETURA:\n────────────────────────────────────────────────────────────────\n\nARQUITETURA HÍBRIDA (Recomendado):\n───────────────────────────────────────────────────────────────\n\n                    ┌──────────────┐\n                    │   Browser    │\n                    │   Mobile     │\n                    └──────┬───────┘\n                           │\n                      REST/JSON\n                      HTTP/1.1\n                           │\n                    ┌──────▼───────┐\n                    │  API Gateway │\n                    │  (gRPC-Web)  │\n                    └──────┬───────┘\n                           │\n                      gRPC/Proto\n                      HTTP/2\n                           │\n         ┌─────────────────┼─────────────────┐\n         │                 │                 │\n    ┌────▼────┐      ┌─────▼───┐      ┌──────▼──┐\n    │ Service │◄────►│ Service │◄────►│ Service │\n    │    A    │ gRPC │    B    │ gRPC │    C    │\n    └─────────┘      └─────────┘      └─────────┘\n\n    Backend: gRPC (performance)\n    Frontend: REST (compatibilidade)\n\n\nTRANSIÇÃO DE REST PARA gRPC:\n────────────────────────────────────────────────────────────────\n\nREST Endpoint              →  gRPC Method\n───────────────────────────   ──────────────────────────────\n\nGET    /accounts/{id}      →  GetAccount(id)\nPOST   /accounts            →  CreateAccount(account)\nPUT    /accounts/{id}       →  UpdateAccount(account)\nDELETE /accounts/{id}       →  DeleteAccount(id)\nGET    /accounts            →  ListAccounts() (stream)\n```\n\n### Resumo Executivo\n\n| **REST** | **gRPC** |\n|----------|----------|\n| Maduro e amplamente adotado | Mais recente, crescendo rapidamente |\n| Ideal para APIs públicas | Ideal para microserviços |\n| Suporte universal (browsers) | Requer cliente específico |\n| Baseado em recursos (CRUD) | Baseado em ações (RPC) |\n| Debugging simples | Requer ferramentas especiais |\n| Payload maior (JSON) | Payload menor (Protobuf) |\n| Uma req/res por vez | Streaming bidirecional |\n| HTTP/1.1 padrão | HTTP/2 obrigatório |\n\n**Conclusão:** Use REST para APIs públicas e interfaces com navegadores. Use gRPC para comunicação entre serviços backend onde performance é crítica.\n\n## Pré requisitos\n\n### ProtoC\n\n-   [Manual de instalação](https://grpc.io/docs/protoc-installation/)\n\n```bash\n# Instalação\napt install -y protobuf-compiler\n# Versão\nprotoc --version\n```\n\n### Pacotes Go\n\n-   [Manual de instalação](https://grpc.io/docs/languages/go/quickstart/)\n\n```bash\n# Generator para go\ngo install google.golang.org/protobuf/cmd/protoc-gen-go@v1.28\n# Generate grpc para go\ngo install google.golang.org/grpc/cmd/protoc-gen-go-grpc@v1.2\n```\n\n### Sqlite3\n\n```bash\n# Instalação\nsudo apt install sqlite3\n# Versão\nsqlite3 --version\n```\n\n### Evans\n\nEvans é um cliente CLI interativo para testar serviços gRPC, similar ao Postman para REST APIs.\n\n-   [Manual de instalação](https://github.com/ktr0731/evans)\n\n```bash\n# Instalação\ngo install github.com/ktr0731/evans@latest\n```\n\n**Características do Evans:**\n- Interface REPL interativa para gRPC\n- Suporte a reflection (descobre serviços automaticamente)\n- Autocomplete para comandos e serviços\n- Suporte a streaming (unary, server, client e bidirectional)\n- Formato JSON e Protobuf\n- Ideal para desenvolvimento e testes\n\n## Recomendações de plugins para VsCode\n\n### vscode-proto3\n\nPlugin essencial para trabalhar com arquivos `.proto` no VSCode.\n\n**Funcionalidades:**\n- Syntax highlighting para Protocol Buffers\n- Autocompletar para mensagens e serviços\n- Validação de sintaxe em tempo real\n- Navegação entre definições (Go to Definition)\n- Formatação automática de código\n- Snippets para estruturas comuns\n\n**Instalação:**\n1. Abra VSCode\n2. Acesse Extensions (Ctrl+Shift+X)\n3. Procure por \"vscode-proto3\"\n4. Clique em \"Install\"\n\n## Comandos\n\n### Rodar o programa\n\n```bash\ngo run cmd/grpc_server/main.go\n```\n\n### Sqlite3\n\n```bash\n# Acessa o banco\nsqlite3 db.sqlite\n# Cria tabela\nsqlite\u003e create table accounts (id string PRIMARY KEY, name string, email string);\n# Lista os dados da tabela\nsqlite\u003e select * from accounts;\n# Para sair\nsqlite\u003e .quit\n```\n\n\u003cdetails\u003e\n\u003csummary\u003eMais comandos do Sqlite3\u003c/summary\u003e\n\n```bash\n# Deleta todos os registros\nsqlite\u003e DELETE FROM accounts;\n# Dropa a tabela\nsqlite\u003e DROP TABLE accounts;\n# Insere um registro\nsqlite\u003e INSERT INTO accounts (id, name, email) VALUES ('xx0011', 'tiago', 'tiago@gmail.com');\n```\n\n\u003c/details\u003e\n\n### ProtolC\n\n```bash\n# Gera os arquivos e interfaces na pasta /internal/pb\nprotoc --go_out=. --go-grpc_out=. proto/account.proto\n# Baixa os pacotes\ngo mod tidy\n```\n\n### Client Evans\n\n```bash\n# 1 - Acessa o client, utilizando reflection\nevans -r repl\n# 2 - Seleciona o package\n\u003e package pb\n# 3 - Seleciona o serviço\n\u003e service AccountService\n# 4 - Executa a chamada ao serviço\n\u003e call CreateAccount\n```\n\n**Atenção:** Para parar o envio de streams no Evans: ctrl + D\n\n## Arquitetura e Boas Práticas\n\n### Estrutura de Projeto Recomendada\n\n```\nprojeto-grpc/\n├── proto/                          # Arquivos .proto\n│   ├── account.proto\n│   ├── user.proto\n│   └── common.proto\n│\n├── internal/                       # Código interno\n│   ├── pb/                        # Código gerado pelo protoc\n│   │   ├── account.pb.go\n│   │   ├── account_grpc.pb.go\n│   │   └── ...\n│   │\n│   ├── service/                   # Implementação dos serviços\n│   │   ├── account_service.go\n│   │   └── user_service.go\n│   │\n│   ├── repository/                # Camada de dados\n│   │   └── account_repository.go\n│   │\n│   └── middleware/                # Interceptors\n│       ├── auth.go\n│       ├── logging.go\n│       └── metrics.go\n│\n├── cmd/\n│   ├── server/                    # Servidor gRPC\n│   │   └── main.go\n│   │\n│   └── client/                    # Cliente gRPC\n│       └── main.go\n│\n├── db/                            # Banco de dados\n│   └── db.sqlite\n│\n├── go.mod\n└── README.md\n```\n\n### Fluxo de Desenvolvimento gRPC\n\n```\n┌────────────────────────────────────────────────────────────────┐\n│              CICLO DE DESENVOLVIMENTO gRPC                     │\n└────────────────────────────────────────────────────────────────┘\n\n1. DEFINIR CONTRATO\n   ┌─────────────────────────────────┐\n   │  Escrever arquivo .proto        │\n   │  - Definir messages             │\n   │  - Definir services             │\n   │  - Definir RPCs                 │\n   └────────────┬────────────────────┘\n                │\n                ▼\n2. GERAR CÓDIGO\n   ┌─────────────────────────────────┐\n   │  protoc --go_out=. \\            │\n   │    --go-grpc_out=. \\            │\n   │    proto/*.proto                │\n   └────────────┬────────────────────┘\n                │\n                ▼\n3. IMPLEMENTAR SERVIDOR\n   ┌─────────────────────────────────┐\n   │  - Implementar interface        │\n   │  - Adicionar lógica de negócio  │\n   │  - Tratar erros                 │\n   │  - Adicionar middleware         │\n   └────────────┬────────────────────┘\n                │\n                ▼\n4. IMPLEMENTAR CLIENTE\n   ┌─────────────────────────────────┐\n   │  - Criar conexão                │\n   │  - Chamar métodos               │\n   │  - Tratar respostas             │\n   └────────────┬────────────────────┘\n                │\n                ▼\n5. TESTAR\n   ┌─────────────────────────────────┐\n   │  - Unit tests                   │\n   │  - Integration tests            │\n   │  - Evans (manual testing)       │\n   └────────────┬────────────────────┘\n                │\n                ▼\n6. DEPLOY\n   ┌─────────────────────────────────┐\n   │  - Docker/Kubernetes            │\n   │  - Service Mesh (Istio)         │\n   │  - Load Balancing               │\n   │  - Monitoring                   │\n   └─────────────────────────────────┘\n```\n\n### Interceptors (Middleware) Pattern\n\n```\n┌────────────────────────────────────────────────────────────────┐\n│                   gRPC INTERCEPTORS CHAIN                      │\n└────────────────────────────────────────────────────────────────┘\n\nCliente                                              Servidor\n────────                                             ─────────\n\n  Request\n    │\n    │     ┌──────────────────────────────────────────┐\n    ├────►│  1. Client Interceptor (Auth)            │\n    │     │     - Adiciona token                     │\n    │     └──────────────────────────────────────────┘\n    │\n    │     ┌──────────────────────────────────────────┐\n    ├────►│  2. Client Interceptor (Logging)         │\n    │     │     - Log da requisição                  │\n    │     └──────────────────────────────────────────┘\n    │\n    ├──────────────────  REDE  ─────────────────────────►\n    │\n    │                     ┌────────────────────────────────┐\n    │                     │  3. Server Interceptor (Auth)  │\n    │                     │     - Valida token             │\n    │                     └────────────────────────────────┘\n    │                                      │\n    │                     ┌────────────────▼───────────────┐\n    │                     │  4. Server Interceptor (Logs)  │\n    │                     │     - Log da requisição        │\n    │                     └────────────────────────────────┘\n    │                                      │\n    │                     ┌────────────────▼───────────────┐\n    │                     │  5. Server Interceptor(Metrics)│\n    │                     │     - Coleta métricas          │\n    │                     └────────────────────────────────┘\n    │                                      │\n    │                     ┌────────────────▼───────────────┐\n    │                     │  6. Handler (Business Logic)   │\n    │                     │     - Processa requisição      │\n    │                     └────────────────┬───────────────┘\n    │                                      │\n    │                                   Response\n    │                                      │\n    │◄─────────────────  REDE  ──────────────────────────┤\n    │\n    │     ┌──────────────────────────────────────────┐\n    │◄────┤  7. Client Interceptor (Response)        │\n    │     │     - Processa resposta                  │\n    │     └──────────────────────────────────────────┘\n    │\n  Response\n\n\nTIPOS DE INTERCEPTORS:\n──────────────────────────────────────────────────────────────────\n\nUnary Interceptor:          Stream Interceptor:\n- Uma req/res por vez       - Streams de dados\n- Simples de implementar    - Mais complexo\n- Uso: auth, logs, metrics  - Uso: conexões persistentes\n```\n\n### Tratamento de Erros em gRPC\n\n```\n┌────────────────────────────────────────────────────────────────┐\n│                   gRPC STATUS CODES                            │\n└────────────────────────────────────────────────────────────────┘\n\nCódigo              │ HTTP    │ Uso\n────────────────────┼─────────┼─────────────────────────────────\nOK                  │ 200     │ Sucesso\nCANCELLED           │ 499     │ Cliente cancelou\nUNKNOWN             │ 500     │ Erro desconhecido\nINVALID_ARGUMENT    │ 400     │ Parâmetros inválidos\nDEADLINE_EXCEEDED   │ 504     │ Timeout\nNOT_FOUND           │ 404     │ Recurso não encontrado\nALREADY_EXISTS      │ 409     │ Recurso já existe\nPERMISSION_DENIED   │ 403     │ Sem permissão\nUNAUTHENTICATED     │ 401     │ Não autenticado\nRESOURCE_EXHAUSTED  │ 429     │ Rate limit / Quota\nFAILED_PRECONDITION │ 400     │ Pré-condição falhou\nABORTED             │ 409     │ Conflito de concorrência\nOUT_OF_RANGE        │ 400     │ Fora do range válido\nUNIMPLEMENTED       │ 501     │ Não implementado\nINTERNAL            │ 500     │ Erro interno\nUNAVAILABLE         │ 503     │ Serviço indisponível\nDATA_LOSS           │ 500     │ Perda de dados\n\n\nEXEMPLO DE TRATAMENTO:\n──────────────────────────────────────────────────────────────────\n\nServidor (Go):\n─────────────\nif account == nil {\n    return nil, status.Error(\n        codes.NotFound,\n        \"account not found\",\n    )\n}\n\nif err := validate(req); err != nil {\n    return nil, status.Error(\n        codes.InvalidArgument,\n        fmt.Sprintf(\"invalid input: %v\", err),\n    )\n}\n\n\nCliente (Go):\n────────────\nresp, err := client.GetAccount(ctx, req)\nif err != nil {\n    st, ok := status.FromError(err)\n    if ok {\n        switch st.Code() {\n        case codes.NotFound:\n            // Trata não encontrado\n        case codes.InvalidArgument:\n            // Trata argumento inválido\n        default:\n            // Trata outros erros\n        }\n    }\n}\n```\n\n### Performance e Otimização\n\n```\n┌────────────────────────────────────────────────────────────────┐\n│              BOAS PRÁTICAS DE PERFORMANCE                      │\n└────────────────────────────────────────────────────────────────┘\n\n1. CONNECTION POOLING\n   ┌────────────────────────────────────────────────┐\n   │  Reutilize conexões gRPC                       │\n   │  - Uma conexão por target                      │\n   │  - HTTP/2 multiplexing automático              │\n   │  - Evite criar/fechar conexões repetidamente   │\n   └────────────────────────────────────────────────┘\n\n2. STREAMING PARA GRANDES VOLUMES\n   ┌────────────────────────────────────────────────┐\n   │  Use streaming ao invés de unary               │\n   │  - Server streaming: listagens grandes         │\n   │  - Client streaming: uploads                   │\n   │  - Bidirecional: real-time                     │\n   └────────────────────────────────────────────────┘\n\n3. COMPRESSÃO\n   ┌────────────────────────────────────────────────┐\n   │  Habilite compressão para payloads grandes     │\n   │  - gzip (padrão)                               │\n   │  - Trade-off: CPU vs Rede                      │\n   └────────────────────────────────────────────────┘\n\n4. TIMEOUTS E DEADLINES\n   ┌────────────────────────────────────────────────┐\n   │  Sempre defina timeouts                        │\n   │  - Context com deadline                        │\n   │  - Previne requisições travadas                │\n   │  - Libera recursos rapidamente                 │\n   └────────────────────────────────────────────────┘\n\n5. LOAD BALANCING\n   ┌────────────────────────────────────────────────┐\n   │  Client-side:                                  │\n   │  - Round-robin                                 │\n   │  - Pick-first                                  │\n   │                                                │\n   │  Server-side:                                  │\n   │  - Nginx                                       │\n   │  - Envoy                                       │\n   │  - Istio                                       │\n   └────────────────────────────────────────────────┘\n\n6. MONITORING\n   ┌────────────────────────────────────────────────┐\n   │  Métricas importantes:                         │\n   │  - Latência (p50, p95, p99)                    │\n   │  - Taxa de erro                                │\n   │  - Throughput (req/s)                          │\n   │  - Conexões ativas                             │\n   │                                                │\n   │  Ferramentas:                                  │\n   │  - Prometheus + Grafana                        │\n   │  - OpenTelemetry                               │\n   │  - Jaeger (tracing)                            │\n   └────────────────────────────────────────────────┘\n```\n\n### Segurança em gRPC\n\n```\n┌────────────────────────────────────────────────────────────────┐\n│                   SEGURANÇA gRPC                               │\n└────────────────────────────────────────────────────────────────┘\n\n1. TLS/SSL (Transport Security)\n   ┌────────────────────────────────────────────────┐\n   │  Cliente                      Servidor         │\n   │    │                              │            │\n   │    ├──── TLS Handshake ──────────►│            │\n   │    │◄─── Certificado ─────────────┤            │\n   │    │                              │            │\n   │    ├──── Dados Criptografados ───►│            │\n   │    │◄─── Dados Criptografados ────┤            │\n   │                                                │\n   │  ✓ Confidencialidade                           │\n   │  ✓ Integridade                                 │\n   │  ✓ Autenticação do servidor                    │\n   │  ✓ (Opcional) Autenticação mútua (mTLS)        │\n   └────────────────────────────────────────────────┘\n\n2. AUTENTICAÇÃO\n   ┌────────────────────────────────────────────────┐\n   │  Métodos:                                      │\n   │  • JWT (JSON Web Tokens)                       │\n   │  • OAuth 2.0                                   │\n   │  • API Keys                                    │\n   │  • mTLS (Mutual TLS)                           │\n   │                                                │\n   │  Implementação:                                │\n   │  • Metadata/Headers                            │\n   │  • Interceptors para validação                 │\n   └────────────────────────────────────────────────┘\n\n3. AUTORIZAÇÃO\n   ┌────────────────────────────────────────────────┐\n   │  Request                                       │\n   │    │                                           │\n   │    ├──► Auth Interceptor                       │\n   │    │    ├─ Valida Token                        │\n   │    │    ├─ Extrai Claims                       │\n   │    │    └─ Verifica Permissões                 │\n   │    │                                           │\n   │    ├──► Handler (se autorizado)                │\n   │    │                                           │\n   │    └──► Error (se não autorizado)              │\n   └────────────────────────────────────────────────┘\n\n4. RATE LIMITING\n   ┌────────────────────────────────────────────────┐\n   │  Protege contra:                               │\n   │  • DoS/DDoS                                    │\n   │  • Abuse de API                                │\n   │  • Custos excessivos                           │\n   │                                                │\n   │  Estratégias:                                  │\n   │  • Token Bucket                                │\n   │  • Leaky Bucket                                │\n   │  • Fixed Window                                │\n   │  • Sliding Window                              │\n   └────────────────────────────────────────────────┘\n```\n\n### Microserviços com gRPC\n\n```\n┌────────────────────────────────────────────────────────────────┐\n│              ARQUITETURA DE MICROSERVIÇOS                      │\n└────────────────────────────────────────────────────────────────┘\n\n                    ┌──────────────────────┐\n                    │    API Gateway       │\n                    │   (gRPC-Web/REST)    │\n                    └──────────┬───────────┘\n                               │\n                   ┌───────────┼───────────┐\n                   │           │           │\n            ┌──────▼─────┐ ┌───▼────┐ ┌────▼───┐\n            │  Service A │ │Service │ │Service │\n            │  (Accounts)│ │   B    │ │   C    │\n            └──────┬─────┘ └────────┘ └────────┘\n                   │\n          ┌────────┼────────┐\n          │        │        │\n     ┌────▼───┐ ┌──▼───┐ ┌──▼───┐\n     │Database│ │Cache │ │Queue │\n     └────────┘ └──────┘ └──────┘\n\n\nCOMUNICAÇÃO ENTRE SERVIÇOS:\n────────────────────────────────────────────────────────────────\n\nSíncrona (gRPC):              Assíncrona (Message Queue):\n─────────────────             ─────────────────────────────\n\nService A ──gRPC──► Service B  Service A ──► Queue ──► Service B\n    │                   │          │                        │\n    └───── Response ────┘          └─── Fire \u0026 Forget ──────┘\n\nVantagens:                    Vantagens:\n• Resposta imediata           • Desacoplamento\n• Simples                     • Escalabilidade\n• Contratos tipados           • Resilência\n\nDesvantagens:                 Desvantagens:\n• Acoplamento                 • Complexidade\n• Cascata de falhas           • Eventual consistency\n\n\nPADRÕES DE DESIGN:\n────────────────────────────────────────────────────────────────\n\n1. SERVICE MESH (Istio, Linkerd)\n   • Observabilidade\n   • Traffic management\n   • Security (mTLS)\n   • Resiliência (retry, timeout)\n\n2. CIRCUIT BREAKER\n   • Previne cascata de falhas\n   • Fail fast\n   • Fallback strategies\n\n3. SAGA PATTERN\n   • Transações distribuídas\n   • Compensação de erros\n   • Consistência eventual\n```\n\n## Recursos Adicionais\n\n### Documentação Oficial\n- **gRPC:** https://grpc.io/\n- **Protocol Buffers:** https://protobuf.dev/\n- **Go gRPC:** https://grpc.io/docs/languages/go/\n\n### Ferramentas Úteis\n- **Evans:** Cliente CLI para gRPC\n- **grpcurl:** cURL para gRPC\n- **Postman:** Suporte a gRPC (versão desktop)\n- **Bloomrpc:** GUI client para gRPC\n- **ghz:** Ferramenta de benchmark para gRPC\n\n### Monitoramento e Observabilidade\n- **Prometheus:** Métricas\n- **Grafana:** Visualização\n- **Jaeger:** Distributed tracing\n- **OpenTelemetry:** Observabilidade completa\n\n### Service Mesh\n- **Istio:** Service mesh completo\n- **Linkerd:** Service mesh leve\n- **Envoy:** Proxy para gRPC\n\n\u003chr /\u003e\n\n\u003cdiv\u003e\n  \u003csub\u003eConteúdo criado por \u003ca href=\"https://github.com/eneas-almeida\"\u003eEnéas Almeida\u003c/a\u003e\u003c/sub\u003e\n\u003c/div\u003e\n","project_url":"https://awesome.ecosyste.ms/api/v1/projects/github.com%2Feneas-almeida%2Fgrpc","html_url":"https://awesome.ecosyste.ms/projects/github.com%2Feneas-almeida%2Fgrpc","lists_url":"https://awesome.ecosyste.ms/api/v1/projects/github.com%2Feneas-almeida%2Fgrpc/lists"}