Chapter 1: What is gRPC and Why Does It Exist?

The Problem: How Do Programs Talk to Each Other?

Imagine you have two programs running on different machines. Program A needs to ask Program B to do something — maybe "look up this user" or "process this payment." How do they communicate?

The fundamental challenge is: how do you make calling a function on a remote machine feel as natural as calling a local function?

This is the problem that Remote Procedure Call (RPC) frameworks solve. And gRPC is Google's modern answer to it.

What gRPC Actually Is

gRPC is a high-performance, open-source Remote Procedure Call framework. Let's break that down:

• g — Originally stood for "Google" (they created it). Now each release gives "g" a new meaning (good, green, groovy...)
• RPC — Remote Procedure Call. You call a function, but it executes on another machine
• Framework — It's not just a protocol. It gives you tools, code generation, libraries

At its core, gRPC lets you:

1. Define a service interface in a .proto file (what functions exist, what they accept, what they return)
2. Auto-generate client and server code in your language of choice
3. Call remote functions as if they were local

// This is a .proto file — the contract between client and server
service Greeter {
  rpc SayHello (HelloRequest) returns (HelloReply);
}

message HelloRequest {
  string name = 1;
}

message HelloReply {
  string message = 1;
}

From this single file, gRPC generates client and server code in C++, Java, Python, Go, C#, Ruby, and more. The client calls SayHello() as if it were a local function. Under the hood, gRPC serializes the request, sends it over the network, deserializes it on the server, executes the function, and sends back the response.

Why Google Built It

Google runs billions of RPC calls per second internally. Before gRPC (the open-source version), they had an internal system called Stubby that handled all inter-service communication since ~2001.

By 2015, they decided to open-source a redesigned version because:

• The industry was moving to microservices — everyone needed efficient inter-service communication
• REST/JSON was too slow and too loose for high-performance systems
• They wanted a standard that worked across languages and platforms
• HTTP/2 had just been standardized, providing the perfect transport layer

The Key Ingredients

Three technologies make gRPC what it is:

1. Protocol Buffers (Protobuf)

The serialization format. Like JSON but binary, strongly typed, and 3-10x smaller/faster. You define your data structures in .proto files, and a compiler generates code to serialize/deserialize them.

2. HTTP/2

The transport protocol. Unlike HTTP/1.1, it supports multiplexing (many requests on one connection), header compression, server push, and binary framing. This is what makes gRPC fast.

3. Code Generation

The developer experience. You write a .proto file once, and the protoc compiler generates type-safe client/server code in your language. No hand-writing HTTP handlers or parsing JSON.

Where gRPC Fits in the Real World

gRPC is used when:

• Microservices talk to each other — internal service-to-service communication
• Performance matters — binary serialization is much faster than JSON
• Streaming is needed — real-time data feeds, chat, telemetry
• Polyglot environments — services in different languages need a common interface
• Strong contracts are required — the .proto file IS the API contract

gRPC in the Telecom World

You'll encounter gRPC in cloud-native telecom (CNF) architectures:

• O-RAN — uses gRPC for near-RT RIC communication
• 5G SBA — while the 3GPP SBI uses HTTP/2+JSON, internal microservice communication within a NF (like AMF) often uses gRPC
• Telemetry — gNMI (gRPC Network Management Interface) for streaming telemetry from network devices
• Kubernetes operators — CNF lifecycle management often uses gRPC internally

What gRPC is NOT

• Not a replacement for REST in all cases — browsers can't natively speak gRPC (you need gRPC-Web)
• Not a message queue — it's request/response (or streaming), not pub/sub
• Not tied to Google Cloud — it's fully open-source (Apache 2.0), used everywhere
• Not just for Go — despite the ecosystem being Go-heavy, it supports 11+ languages

The 30-Second Summary