gRPC: High-Performance Remote Procedure Calls

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71

// The Same Operation in REST vs gRPC
 
// ========== REST ==========
// GET /users/123
// Host: api.example.com
// Accept: application/json
// Authorization: Bearer <token>
 
// Response:
// HTTP/1.1 200 OK
// Content-Type: application/json
// 
// {
//   "id": "123",
//   "name": "Alice",
//   "email": "alice@example.com",
//   "_links": {
//     "self": "/users/123",
//     "orders": "/users/123/orders"
//   }
// }
 
// REST Client Code (TypeScript)
async function getUserREST(userId: string): Promise<User> {
    const response = await fetch(`https://api.example.com/users/${userId}`, {
        headers: {
            'Accept': 'application/json',
            'Authorization': `Bearer ${token}`,
        },
    });
    
    if (!response.ok) {
        throw new Error(`HTTP ${response.status}`);
    }
    
    const data = await response.json();
    
    // Manual validation/transformation
    return {
        id: data.id,
        name: data.name,
        email: data.email,
    };
}
 
// ========== gRPC ==========
// Proto:
// rpc GetUser(GetUserRequest) returns (User);
 
// gRPC Client Code (TypeScript)
async function getUserGRPC(userId: string): Promise<User> {
    return new Promise((resolve, reject) => {
        // Fully typed - errors if arguments wrong
        client.getUser(
            { userId },  // Type-checked against GetUserRequest
            (error, response) => {
                if (error) {
                    reject(error);  // Error has .code (gRPC status)
                } else {
                    resolve(response);  // Type-checked User
                }
            }
        );
    });
}
 
// Key Difference: With gRPC, the IDE knows:
// - What fields GetUserRequest has
// - What fields User response has  
// - What error codes are possible
// - All at compile time, before running any code

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83

// Performance Analysis: When Does It Matter?
 
// Scenario 1: Low-traffic web API
// - 100 requests/second
// - Average payload: 2 KB JSON vs 600 bytes Protobuf
// - REST overhead: negligible (~0.1% CPU)
// - Winner: Either works fine
 
// Scenario 2: High-traffic microservice
// - 50,000 requests/second
// - Average payload: 5 KB JSON vs 1.5 KB Protobuf
//
// REST performance:
// - Bandwidth: 250 MB/s
// - Parse CPU: ~15% of modern core
// - Memory for parsing: ~500 MB (buffers, strings)
//
// gRPC performance:
// - Bandwidth: 75 MB/s (70% reduction)
// - Parse CPU: ~2% of modern core
// - Memory for parsing: ~50 MB
//
// Winner: gRPC saves $X,000/month in infrastructure
 
// Scenario 3: Mobile application
// - Slow/metered network
// - Battery-constrained device
// - 60% smaller payloads = faster load, less data usage
// - Binary parsing = less CPU = better battery
// Winner: gRPC (but requires gRPC-Web)
 
// Scenario 4: Real-time streaming
// - 10,000 events/second per client
// - REST: Long polling or WebSocket (not native)
// - gRPC: Native bidirectional streaming with flow control
// Winner: gRPC (not even close)
 
// Latency Breakdown Comparison
interface LatencyBreakdown {
    dns: number;           // Same for both
    tcpConnect: number;    // Same for both  
    tlsHandshake: number;  // Same for both
    requestSerialization: number;  // gRPC: 5-10x faster
    networkTransmit: number;       // gRPC: 60-75% less data
    serverParse: number;           // gRPC: 5-10x faster
    businessLogic: number;         // Same for both
    responseSerialization: number; // gRPC: 5-10x faster
    networkReceive: number;        // gRPC: 60-75% less data
    clientParse: number;           // gRPC: 5-10x faster
}
 
// For a typical microservice call:
const restLatency = {
    dns: 0,              // Cached
    tcpConnect: 0,       // Keep-alive
    tlsHandshake: 0,     // Session resumption
    requestSerialization: 2,   // ms
    networkTransmit: 5,        // ms (2KB)
    serverParse: 3,            // ms
    businessLogic: 10,         // ms
    responseSerialization: 3,  // ms
    networkReceive: 8,         // ms (4KB)
    clientParse: 4,            // ms
    // Total: 35ms
};
 
const grpcLatency = {
    dns: 0,
    tcpConnect: 0,
    tlsHandshake: 0,
    requestSerialization: 0.2,  // ms
    networkTransmit: 1.5,       // ms (600 bytes)
    serverParse: 0.3,           // ms
    businessLogic: 10,          // ms (same)
    responseSerialization: 0.4, // ms
    networkReceive: 2.5,        // ms (1.2KB)
    clientParse: 0.3,           // ms
    // Total: 15.2ms
};
 
// For business-logic-heavy operations: 30% improvement
// For data-transfer-heavy operations: 50-70% improvement
// For ping-pong chatty protocols: 40-60% improvement

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39

# Debugging REST APIs
 
# Simple curl to test endpoint
curl -X GET https://api.example.com/users/123 \
  -H "Authorization: Bearer token123"
 
# Pretty-printed response (human readable)
{
  "id": "123",
  "name": "Alice",
  "email": "alice@example.com"
}
 
# View in browser Network tab - full inspection
# Postman/Insomnia - visual API testing
# Charles Proxy - inspect any HTTP traffic
 
# ========================================
 
# Debugging gRPC APIs
 
# Using grpcurl (gRPC equivalent of curl)
grpcurl -plaintext \
  -d '{"user_id": "123"}' \
  localhost:50051 \
  com.example.UserService/GetUser
 
# Requires reflection enabled OR proto files available
# Output is JSON-ish (grpcurl converts for readability)
 
# Using grpcui (web-based gRPC testing)
grpcui -plaintext localhost:50051
# Opens browser with Postman-like interface
 
# Viewing raw bytes - not practical for debugging
# Must decode with proto schema
 
# Wireshark - supports HTTP/2 but gRPC is complex
# BloomRPC - GUI client for gRPC services

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67

// Infrastructure Support Comparison
 
// API Gateways
const restGateways = [
    'Kong (excellent REST support)',
    'AWS API Gateway',
    'Google Cloud Endpoints',
    'Azure API Management',
    'Nginx (native)',
    'HAProxy (native)',
    'Traefik',
    'Ambassador',
];
 
const grpcGateways = [
    'Envoy (excellent gRPC support)',
    'gRPC-Gateway (REST↔gRPC transcoding)',
    'Kong (with plugin)',
    'Nginx (with grpc_pass)',
    'Traefik (with gRPC)',
    'Linkerd (service mesh)',
    'Istio (service mesh)',
];
 
// Load Balancers
const loadBalancerSupport = {
    REST: {
        L4_balancing: true,       // TCP load balancing
        L7_balancing: true,       // HTTP routing
        sticky_sessions: true,    // Cookie-based
        health_checks: 'HTTP',    // Standard HTTP checks
        support: 'Universal',
    },
    gRPC: {
        L4_balancing: true,       // Works but suboptimal
        L7_balancing: 'Requires HTTP/2 support',  // Not all LBs
        sticky_sessions: 'Complex',  // No cookies
        health_checks: 'gRPC Health Checking Protocol',  // Different
        support: 'Envoy, modern LBs',
    },
};
 
// CRITICAL: gRPC load balancing caveat
// HTTP/2 multiplexes all requests on single connection
// L4 load balancer just sees one connection per client
// All requests go to same backend = no load distribution!
// 
// Solutions:
// 1. Client-side load balancing (gRPC supports this)
// 2. L7 load balancer that understands HTTP/2 streams (Envoy)
// 3. Periodic connection recycling
 
// Monitoring and Tracing
const observabilityTools = {
    REST: {
        metrics: 'All APM tools (Datadog, New Relic, etc.)',
        tracing: 'OpenTelemetry, Jaeger, Zipkin',
        logging: 'Standard HTTP logs, readily parseable',
        debugging: 'Browser DevTools, proxy tools',
    },
    gRPC: {
        metrics: 'Most APM tools (with gRPC support)',
        tracing: 'OpenTelemetry (excellent support)',
        logging: 'Requires custom interceptors for readable logs',
        debugging: 'grpcurl, grpcui, BloomRPC',
    },
};

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32

gRPC-Web Architecture
 
Browser (gRPC-Web Client)              Proxy                   Backend Services
┌─────────────────────┐    ┌─────────────────────┐    ┌─────────────────────┐
│                     │    │                     │    │                     │
│  JavaScript/TS App  │───►│   Envoy Proxy       │───►│  gRPC Server        │
│                     │    │   (or grpc-web)     │    │                     │
│  gRPC-Web Client    │◄───│                     │◄───│  com.example.Svc    │
│                     │    │  Translates:        │    │                     │
│  Protobuf messages  │    │  - gRPC-Web → gRPC  │    │  Native gRPC        │
│                     │    │  - gRPC → gRPC-Web  │    │                     │
└─────────────────────┘    └─────────────────────┘    └─────────────────────┘
 
gRPC-Web Protocol Modes:
 
1. grpc-web (binary):
   - Content-Type: application/grpc-web+proto
   - Binary protobuf payloads
   - Trailers sent as special binary frame
   - ~95% of gRPC efficiency
 
2. grpc-web-text (base64):
   - Content-Type: application/grpc-web-text+proto
   - Base64-encoded payloads
   - Works with simpler proxies
   - ~25% overhead from encoding
 
Limitations of gRPC-Web:
- ❌ No bidirectional streaming (browser limitation)
- ❌ Requires proxy in front of gRPC services
- ⚠️ Unary and server-streaming only
- ⚠️ Some features limited (deadlines, cancellation)

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74

// Schema Evolution: REST vs gRPC
 
// ========== REST Evolution ==========
 
// Version 1 Response
const userV1 = {
    id: '123',
    name: 'Alice Smith',
    email: 'alice@example.com',
};
 
// Version 2 Response (breaking changes)
const userV2 = {
    id: '123',
    firstName: 'Alice',        // Was 'name' - BREAKING
    lastName: 'Smith',         // New field - non-breaking
    email: 'alice@example.com',
    createdAt: '2024-01-01',   // New field - non-breaking
    // phone removed - BREAKING for clients expecting it
};
 
// REST versioning strategies:
// 1. URL versioning: /v1/users, /v2/users
//    Clients explicitly choose version
//    Old versions must be maintained
//
// 2. Header versioning: Accept: application/vnd.api.v2+json
//    Cleaner URLs, harder to debug
//
// 3. No versioning (evolve carefully):
//    Only additive changes
//    Never remove fields, only deprecate
//    Risk of accidental breakage
 
// ========== gRPC Evolution ==========
 
// Version 1 Proto
// message User {
//   string id = 1;
//   string name = 2;
//   string email = 3;
// }
 
// Version 2 Proto (backward compatible)
// message User {
//   string id = 1;
//   // field 2 removed - MUST reserve
//   reserved 2;
//   reserved "name";
//   
//   string first_name = 4;  // New field number
//   string last_name = 5;   // New field number
//   string email = 3;       // Unchanged
//   int64 created_at = 6;   // New field
// }
 
// gRPC compatibility rules:
// ✅ Add new fields (with new field numbers)
// ✅ Remove fields (must reserve number AND name)
// ✅ Rename fields (numbers are used on wire)
// ❌ Change field types incompatibly
// ❌ Reuse field numbers
// ❌ Change field number of existing field
 
// Proto allows detecting what client supports:
// message GetUserRequest {
//   string user_id = 1;
//   repeated string field_mask = 2;  // What fields client wants
// }
 
// Key difference: gRPC evolution is STRUCTURED
// Compiler catches many breaking changes
// Old clients still work with new servers (unknown fields ignored)
// New clients still work with old servers (missing fields = default)