TopolearnKnowing where gRPC fits helps you choose between it, REST and GraphQL.
gRPC is a remote procedure call framework originally built at Google and now a CNCF project. You describe an API as services with methods and typed messages in a .proto file (Protocol Buffers). Code generators then produce a client stub whose methods look like local functions, and a server interface you implement.
What you get compared with JSON over REST:
- A strict contract shared by all languages: Go, Java, C++, Python, Node, C#, Kotlin, Swift, Rust and more.
- Compact binary messages (protobuf) that are faster to encode and smaller on the wire.
- HTTP/2 transport: many concurrent calls multiplexed over one connection, plus streaming in either or both directions.
- Built-in deadlines, cancellation, metadata (headers) and standard status codes.
Where it is weaker: browsers cannot speak native gRPC directly (you need gRPC-Web or Connect through a proxy), payloads are not human-readable without tools, and L7 load balancers must understand HTTP/2.
Typical use: internal service-to-service communication in microservices, mobile clients talking to backends, and streaming pipelines. Public, browser-facing APIs more often use REST or GraphQL, sometimes generated from the same proto definitions.
Example
// hello.proto: the contract shared by client and server
syntax = "proto3";
package hello.v1;
service Greeter {
rpc SayHello (HelloRequest) returns (HelloReply);
}
message HelloRequest { string name = 1; }
message HelloReply { string message = 1; }
// Generated client usage (any language), conceptually:
// reply = greeter.SayHello({ name: "Ann" })
// reply.message == "Hello, Ann" Remember
- Contract-first: services and messages in .proto files
- Generated stubs make remote calls look like local ones
- Binary protobuf over HTTP/2 with streaming and deadlines
Watch out for
- Expecting browsers to call a gRPC server directly without gRPC-Web or Connect.