gRPC & Protocol Buffers

What is gRPC?

gRPC (gRPC Remote Procedure Calls) is a high-performance, open-source RPC framework developed by Google. It enables you to call remote functions as if they were local functions, abstracting away the complexity of network communication.

The Core Concept

gRPC uses Protocol Buffers (protobuf) for serialization and HTTP/2 for transport. This combination provides significant performance advantages over traditional REST APIs using JSON over HTTP/1.1. The framework generates client and server code from .proto files, ensuring type safety and reducing boilerplate code.

Key Insight: gRPC is designed for inter-service communication in microservices architectures. It’s optimized for performance, with binary serialization reducing payload sizes by 50-70% compared to JSON, and HTTP/2 providing multiplexing and header compression.

Simple Analogy

Think of REST like sending a letter (JSON text) through regular mail. gRPC is like sending a compressed package (binary) through express delivery (HTTP/2). It’s faster, more efficient, and can handle multiple packages at once.

Why gRPC?

Feature	REST/JSON	gRPC
Speed	Slower (text parsing)	Faster (binary)
Payload Size	Larger (text)	Smaller (binary)
Streaming	Limited	Full support
Type Safety	Runtime	Compile-time
Code Generation	Manual	Automatic
Browser Support	Excellent	Limited

---

Protocol Buffers: The Foundation

Protocol Buffers (protobuf) is a binary serialization format. Think of it as a more efficient alternative to JSON.

JSON vs Protocol Buffers

JSON (text-based):

{
  "id": 12345,
  "name": "John Doe",
  "email": "[email protected]",
  "age": 30
}

Size: ~80 bytes

Protocol Buffers (binary):

[encoded binary data]

Size: ~25 bytes (3x smaller!)

Why Binary?

1. Smaller size - No field names, just values
2. Faster parsing - No string parsing
3. Type safety - Schema enforces types
4. Backward compatible - Can evolve schemas

---

Defining a Service: .proto Files

.proto files define your service contract. They’re like API documentation + code generator input.

Basic .proto Example

syntax = "proto3";

package user_service;

// Message definition (like a struct/class)
message User {
  int32 id = 1;
  string name = 2;
  string email = 3;
  int32 age = 4;
}

message GetUserRequest {
  int32 user_id = 1;
}

message GetUserResponse {
  User user = 1;
}

// Service definition
service UserService {
  // Unary RPC: one request, one response
  rpc GetUser(GetUserRequest) returns (GetUserResponse);

  // Server streaming: one request, multiple responses
  rpc ListUsers(GetUserRequest) returns (stream User);

  // Client streaming: multiple requests, one response
  rpc CreateUsers(stream User) returns (CreateUsersResponse);

  // Bidirectional streaming: multiple requests, multiple responses
  rpc ChatUsers(stream ChatMessage) returns (stream ChatMessage);
}

Field Numbers

Field numbers (1, 2, 3…) are important:

• Used for binary encoding (not field names!)
• Must be unique within message
• Once used, never change (backward compatibility)
• Use 1-15 for frequently used fields (1 byte encoding)

Message Types

Common types:

• int32, int64 - Integers
• float, double - Floating point
• bool - Boolean
• string - UTF-8 string
• bytes - Raw bytes
• repeated - Arrays/lists
• map - Key-value pairs

---

gRPC Service Types

1. Unary RPC (Request-Response)

One request, one response. Like a function call.

service UserService {
  rpc GetUser(GetUserRequest) returns (GetUserResponse);
}

Flow:

Client → Request → Server
Client ← Response ← Server

2. Server Streaming

One request, multiple responses. Server sends stream of data.

service UserService {
  rpc ListUsers(GetUserRequest) returns (stream User);
}

Flow:

Client → Request → Server
Client ← User 1 ← Server
Client ← User 2 ← Server
Client ← User 3 ← Server
...

Use cases:

• Streaming search results
• Real-time updates
• Large dataset transfer

3. Client Streaming

Multiple requests, one response. Client sends stream of data.

service UserService {
  rpc CreateUsers(stream User) returns (CreateUsersResponse);
}

Flow:

Client → User 1 → Server
Client → User 2 → Server
Client → User 3 → Server
Client ← Response ← Server

Use cases:

• Batch uploads
• Collecting metrics
• Aggregating data

4. Bidirectional Streaming

Multiple requests, multiple responses. Both sides stream.

service ChatService {
  rpc Chat(stream ChatMessage) returns (stream ChatMessage);
}

Flow:

Client → Message 1 → Server
Client ← Message 2 ← Server
Client → Message 3 → Server
Client ← Message 4 ← Server
...

Use cases:

• Chat applications
• Real-time collaboration
• Interactive games

---

Implementing gRPC Services

Server Implementation

Client Implementation

---

Error Handling in gRPC

gRPC uses status codes (similar to HTTP but different):

Code	Meaning	HTTP Equivalent
OK	Success	200
INVALID_ARGUMENT	Bad request	400
NOT_FOUND	Resource not found	404
ALREADY_EXISTS	Conflict	409
PERMISSION_DENIED	Forbidden	403
UNAUTHENTICATED	Unauthorized	401
RESOURCE_EXHAUSTED	Rate limited	429
INTERNAL	Server error	500

Error Handling Example

---

When to Use gRPC

Use gRPC When:

• Microservices communication (internal APIs) - Perfect for service-to-service calls where performance matters
• High-performance needs (low latency, high throughput) - 5-10x faster than REST/JSON
• Streaming required (real-time data) - Built-in support for server, client, and bidirectional streaming
• Strong typing needed (compile-time safety) - Protocol Buffers provide type safety at compile time
• Polyglot environments (multiple languages) - Generate client/server code in any language from .proto files

Don’t Use gRPC When:

• Public APIs (browser support limited) - Browsers have limited gRPC support (gRPC-Web exists but adds complexity)
• Simple CRUD (REST is simpler) - REST is easier to understand and debug for simple operations
• Human-readable needed (JSON is better) - JSON is easier to read and debug than binary protobuf
• Firewall restrictions (HTTP/2 may be blocked) - Some firewalls/proxies don’t support HTTP/2 properly

gRPC-Web

gRPC-Web allows gRPC in browsers, but it’s more complex than REST. Use REST for public web APIs, gRPC for internal services.

---

Performance Comparison

REST vs gRPC Benchmarks

Typical performance differences:

Metric	REST/JSON	gRPC
Latency	10-50ms	2-10ms
Throughput	1K-10K req/s	10K-100K req/s
Payload Size	100%	30-50%
CPU Usage	Higher	Lower

Why gRPC is faster:

1. Binary encoding (no JSON parsing)
2. HTTP/2 (multiplexing, header compression)
3. Connection reuse (less overhead)
4. Efficient serialization (protobuf)

---

LLD Connection: Designing gRPC Services

At the code level, gRPC translates to service interfaces, message types, and streaming handlers.

Service Interface Design

---

Key Takeaways

Performance First

gRPC is 5-10x faster than REST due to binary encoding and HTTP/2. Perfect for microservices.

Streaming Support

gRPC supports four streaming types: unary, server, client, and bidirectional. REST can’t do this.

Strong Typing

Protocol Buffers provide compile-time type safety. Schema defines contract, code is generated.

Service Contracts

.proto files define service contracts. Generate client/server code in any language automatically.

---

Next Steps

• Learn API Gateway Pattern - single entry point for APIs
• Understand Backend for Frontend - tailored APIs for clients
• Master Rate Limiting - controlling API usage