When people (Devs) first hear about gRPC, the usual description is that it’s a high-performance RPC framework built on top of HTTP/2, using Protocol Buffers.
That’s accurate.
But it doesn’t really help you understand anything.
Because the real confusion doesn’t come from what gRPC is, it comes from how it actually behaves when you’re building with it.
The moment you open a .proto file for the first time, it feels unfamiliar. You’re defining services, messages, fields with numbers attached to them. It doesn’t look like the typical request-response structure you’re used to with REST.
And that’s where the shift begins.
Instead of thinking in terms of URLs and JSON payloads, gRPC asks you to think in terms of contracts.
The .proto file is not just a schema. It’s more like an agreement between two systems. It defines what can be said, how it should be said, and in what structure. Before any communication happens, both sides already understand the language.
Those numbers you see attached to fields are not random. They exist so that the message can be serialized efficiently. The system doesn’t care about the field names as much as it cares about those tags. That’s part of what makes it fast, but also part of what makes it feel strange at first.
Then comes the generated code.
At this point, it can feel like magic. You write a .proto file, and suddenly you have client and server code generated for you. Functions appear, request and response objects are already defined, and you’re expected to just use them.
But what’s really happening is simple.
The .proto file defines the contract.
The generated code enforces that contract.
Now when a client wants to talk to a server, it doesn’t “construct” a request manually like in REST. It simply calls a function, almost like calling a local method. Under the hood, gRPC takes that function call, serializes the data using Protocol Buffers, sends it over HTTP/2, and reconstructs it on the server side.
So instead of thinking:
“I’m sending an HTTP request”
It’s more accurate to think:
“I’m calling a function that happens to exist on another machine.”
That mental shift is where things start to make sense.
At first, everything feels abstract. The .proto file, the generated code, the client and server setup. It can feel like you’re just wiring things together without understanding the flow.
But once you build a few small examples, the pattern becomes clearer.
The client calls a method.
The method follows a contract.
The contract was defined before anything was built.
And everything else is just implementation detail.
That’s the entry point into understanding gRPC.
Not just what it is, but how to think with it.
Follow for Part 2 -> streaming (where it gets really interesting).
Top comments (0)