Learn gRPC - History, Background & Why We Need gRPC

#Introduction

Every great technology is born from a real problem, and gRPC is no exception. Episode 1 tells the story of why gRPC exists: how Google struggled to connect millions of internal services, how Stubby was born as the solution, and how gRPC was rebuilt as an open source project for the world.

In this episode you'll understand the historical journey, the position of Protocol Buffers as the default contract language, and most importantly: when gRPC wins over REST/JSON and when it should be avoided. This understanding shapes the architectural decisions throughout the rest of the series.

We'll also touch on the industry context: why tech giants choose gRPC, and how those decisions can — or cannot — be applied to your project.

#Evolution from Stubby to gRPC

#Born at Google

In the early 2000s, Google ran thousands of services inside a single datacenter that had to communicate with each other. The solution was Stubby, an internal RPC framework handling trillions of calls per day. Stubby used protobuf as its data format and supported features like timeouts, retries, and load balancing.

The problem: Stubby was tightly coupled to Google's internal infrastructure. There was no public documentation, no installable version, and it wasn't designed for the public internet. When the external ecosystem started adopting protobuf through the open source Protocol Buffers release, it became clear the communication framework also needed to be opened up.

#Open Source Release and CNCF

gRPC was announced as open source in March 2015 and reached stable version 1.0 in August 2016. Three key design choices set it apart from Stubby:

• Transport uses HTTP/2, not a private protocol, so it can work over standard internet infrastructure.
• Multi-language from the start: Go, Java, C++, Python, Node.js, and more.
• Contracts are written in a simplified protobuf version 3 to be friendly to new developers.

In 2017 gRPC was donated to the Cloud Native Computing Foundation (CNCF), joining Kubernetes and Prometheus. Cross-industry adoption grew rapidly — from Netflix and Dropbox to the major cloud platforms. gRPC is now also the default transport for many observability systems and service meshes.

This evolution continued through the latest stable releases: features like server reflection, standard health checking, and xDS support for dynamic load balancing arrived gradually. To check the gRPC version installed in a Go project, open go.mod and run go list -m google.golang.org/grpc to see the exact version in use.

A pattern you can observe from this history: gRPC always evolves from real needs, not just chasing trends. Every major feature we use in this series — streaming, metadata, reflection, health checks — exists because there was a concrete problem to solve, not because it sounded cool on paper.

#Protocol Buffers as the Default IDL

Choosing protobuf as the IDL (Interface Definition Language) is the most influential architectural decision. A .proto file describes data and services declaratively:

syntax = "proto3";
 
message Item {
  string id = 1;
  string name = 2;
}
 
service Catalog {
  rpc GetItem(Item) returns (Item);
}

The contract above is read by the protoc compiler and generates code in all target languages. With this schema-first model, clients and servers can't invent contracts: anything not in the .proto file cannot be called. The protoc command for generating code is one we'll use starting from episode 4.

Before continuing, make sure the protobuf compiler is installed on your system by running protoc --version. Output like libprotoc 3.21.x means the environment is ready — this is the same verification you did in episode 0.

#gRPC vs REST/JSON

#Performance and Payload Size

The most visible difference: REST usually uses text-based JSON, while gRPC uses binary protobuf. Imagine sending the same data down two different paths:

curl -X POST http://localhost:8080/items \
  -H "Content-Type: application/json" \
  -d '{"id":"a1","name":"Kursi"}'

versus a gRPC call that is much smaller because data is serialized to binary and HTTP/2 headers are compressed. For large payloads and high traffic, this bandwidth savings is immediately felt in cost and latency.

Here's a brief comparison: to call the same endpoint, curl -X POST http://localhost:8080/items -d '{...}' sends JSON text plus text headers, while a gRPC call sends binary protobuf plus HPACK-compressed headers. The more often it's called, the bigger the difference.

#Strongly-Typed and Schema-First

In REST, requests and responses are validated manually on both sides; a typo in a field name is only caught at runtime. In gRPC, the .proto contract enforces data types at compile time — errors are detected much earlier. Cross-team collaboration is also easier because .proto becomes the single source of truth shared across all languages.

#Streaming and Contract-Driven Development

gRPC provides four communication patterns — unary, server streaming, client streaming, and bidirectional streaming — all over a single HTTP/2 connection. REST is fundamentally one request, one response, so real-time streaming requires extra solutions like WebSocket. For microservices that need streaming communication, built-in observability, and tested contracts, gRPC is the natural choice.

The other, less-discussed side: with contracts generated into many languages, backend and frontend teams share the same definitions without going back and forth fixing documentation. A field change that breaks clients is visible immediately at compile time, not after users report it. This is the value of contract-driven development that you'll fully experience in episode 8 about schema evolution.

#When gRPC Isn't the Right Choice

No solution is perfect for every case. Avoid gRPC when:

• Direct browser applications: browsers can't send raw gRPC requests without an intermediary like Envoy or gRPC-Web (episode 16).
• Public APIs for external consumers: JSON and REST are more universal, easier to debug from a browser, and supported by every tool.
• A strong HTTP-based ecosystem already exists: if the whole system already uses REST/OpenAPI, adding gRPC means managing two stacks at once.
• Very simple needs: a single small endpoint with low traffic won't feel gRPC's advantages, but will still carry protobuf's complexity.

A case that's often overlooked: gRPC is also a poor fit for consumers with very limited bandwidth who only need one small piece of data, or for systems that require infrastructure-level HTTP caching. REST with correct GET semantics can leverage CDN and reverse-proxy caching, while unary gRPC doesn't naturally take advantage of them. Consider these factors when designing APIs for public scale.

The principle: gRPC excels at internal service-to-service communication with high traffic and streaming needs; REST remains the champion for edge APIs facing the public.

As a practical guideline when choosing: first ask who the consumers are. If the consumers are other services inside your system with high traffic, choose gRPC. If the consumers are browsers, third-party apps, or external partners, choose REST with JSON and document it via OpenAPI. This decision should be made per API, not forced uniformly across the whole system.

Also keep in mind that the two technologies don't have to compete — many production architectures use both at once. Internal services speak gRPC, and in front of them sits a gateway that translates to REST for the public (episode 16). With this pattern, you get gRPC's performance advantages and REST's universality in a single system.

#Closing

Key takeaways:

• gRPC evolved from Stubby, Google's internal RPC framework, then was released open source in 2015.
• Protobuf as an IDL gives gRPC a strong schema, small binary payloads, and cross-language code generation.
• gRPC excels in performance, strongly-typed contracts, and streaming compared to REST/JSON.
• gRPC isn't the right choice for public browsers or external APIs without a gateway.
• The gRPC versus REST decision is an architectural one, not just a technology preference.

In episode 2 next, we'll dissect gRPC's core concepts and main architecture — how protobuf becomes client and server code, the role of HTTP/2 multiplexing and HPACK, the stub and channel components, and the metadata, deadlines, and status codes that govern every RPC's lifecycle. Keep the .proto contract in mind, because this architectural foundation is what every following episode builds on.