Modifying gRPC Services Over Time [I]
summary
Covers concrete rules and tools for evolving gRPC APIs: put v1 in package and add per-RPC Request/Response messages so new parameters fit, use field mask for partial updates to avoid accidentally clearing new fields, rely on proto3.5’s unknown fields pass-through when persisting serialized messages, return structured error details with Google RPC status Any for rich troubleshooting, occasionally terminate long-lived streams to force client retry, and prefer server-first upgrades to keep wire and binary compatibility.
AI-written summary · about
chapters (14)
- 0:00Intro
- 0:36Intended Audience
- 1:25Assumptions
- 2:55What Type of Compatibility?
- 3:46Binary/Source Compatibility
- 4:48Library Service (conceptual)
- 5:50Best Practices
- 7:36Library Service (improved)
- 10:38Wire Compatibility - Protobuf
- 13:09Behavior Compatibility
- 13:45New primitive fields default to
- 15:51Avoid updates clearing new fields
- 21:33Use google.rpc. Status for error details
- 24:57Break long-lived RPC occasionally
related talks
16mStop Breaking the Proto! Designing for Change in an Microservices World
41mgRPC Practical Things
46mIntroduction to gRPC
14mOverview of gRPC
11m"RPC Frameworks Overview"
50mEnabling Googley microservices with gRPC
23mRunning gRPC services for serving legacy RESTful APIs on Kubernetes
24mgRPC Communication Patterns – A Deep Dive