gRPC
High-performance RPC over HTTP/2, with generated clients and servers from a schema.
What it is
gRPC is a high-performance, open-source universal RPC framework developed by Google. It uses HTTP/2 for transport, Protocol Buffers for serialization, and supports features like authentication, load balancing, and bidirectional streaming.
gRPC uses `.proto` files to define service contracts and message schemas. The `protoc` compiler generates C++ stubs, which can be used to implement servers and clients. gRPC supports unary calls, server streaming, client streaming, and bidirectional streaming.
- Licence
- Apache 2.0
- Built on
- HTTP/2 and Protocol Buffers
When to use it
The question documentation cannot answer for you — because it cannot recommend something else.
Reach for it when
- Internal service-to-service communication where efficiency and typed contracts matter
- You need streaming in either direction, or both
- Polyglot systems where one schema should generate clients in every language
Look elsewhere when
- A public-facing API — REST and JSON are far easier for consumers to adopt and debug
- Browser clients, which need a gRPC-Web proxy
Installation
sudo apt install protobuf-compiler libgrpc++-devGetting started
The smallest useful thing you can do with it, and what each part means.
syntax = "proto3";
service Greeter {
rpc SayHello (HelloRequest) returns (HelloReply);
}
message HelloRequest {
string name = 1;
}
message HelloReply {
string message = 1;
}#include "helloworld.grpc.pb.h"
#include <grpcpp/grpcpp.h>
class GreeterServiceImpl final : public Greeter::Service {
grpc::Status SayHello(grpc::ServerContext* context, const HelloRequest* request, HelloReply* reply) override {
reply->set_message("Hello " + request->name());
return grpc::Status::OK;
}
};int main() {
GreeterServiceImpl service;
grpc::ServerBuilder builder;
builder.AddListeningPort("0.0.0.0:50051", grpc::InsecureServerCredentials());
builder.RegisterService(&service);
std::unique_ptr<grpc::Server> server(builder.BuildAndStart());
server->Wait();
}auto channel = grpc::CreateChannel("localhost:50051", grpc::InsecureChannelCredentials());
std::unique_ptr<Greeter::Stub> stub = Greeter::NewStub(channel);
HelloRequest request;
request.set_name("World");
HelloReply reply;
gr::ClientContext context;
grpc::Status status = stub->SayHello(&context, request, &reply);
if (status.ok()) {
std::cout << reply.message() << std::endl;
}Advanced usage
Where the library earns its place over a simpler alternative.
rpc ListFeatures(Rectangle) returns (stream Feature);rpc Chat(stream ChatMessage) returns (stream ChatMessage);grpc::SslServerCredentialsOptions ssl_opts;
builder.AddListeningPort("0.0.0.0:50051", grpc::SslServerCredentials(ssl_opts));context.set_deadline(std::chrono::system_clock::now() + std::chrono::seconds(5));Errors and fixes
The failures you are most likely to hit, and what actually resolves them.
- UNAVAILABLE: failed to connect to all addresses
- Ensure the server is running and reachable at the specified address/port.
- DEADLINE_EXCEEDED
- The client timeout expired. Increase the deadline or optimize server response time.
- PERMISSION_DENIED
- Occurs when credentials are missing or invalid. Ensure proper authentication is configured.
Best practices
- Always define clear and stable `.proto` contracts for services.
- Use TLS for secure communication in production environments.
- Leverage streaming for large datasets or long-lived connections.
- Set deadlines to avoid hanging RPCs.
- Use interceptors or middleware for logging and monitoring.
Alternatives
Comparable options, and the reason you would pick one over the other.
ZeroMQ
Messaging patterns without a service definition or code generation
REST + OpenAPI
Simpler, universally supported, human-debuggable
Background
Why it exists, and what it was reacting to.
gRPC was introduced by Google in 2015 to standardize communication in microservices and distributed systems. It builds upon Protocol Buffers for schema definition and leverages HTTP/2 for efficient transport. Today, gRPC is widely adopted in cloud-native applications, Kubernetes, and service mesh environments as a modern alternative to REST.
