The team has 15 microservices talking to each other over JSON HTTP. The bandwidth bill is real, the type drift between services is constant, and every contract change is a multi-PR coordination dance. Somebody proposes gRPC. Three weeks later they have a working prototype and a question: “is the migration worth it for the rest of the system?”

gRPC is meaningfully better than JSON-over-HTTP for service-to-service communication: smaller payloads (binary protobuf vs verbose JSON), strict typed contracts, generated clients for any language, streaming as a first-class citizen. It is also harder to debug, has worse browser support, and adds a build-tooling dependency. The decision “should we switch” depends on the shape of the work.

This post is the honest comparison, the cases where gRPC wins, and the connect-rpc compromise that gets most of the benefits without the costs.

What gRPC actually is

A .proto file is the schema. From it, gRPC generates server stubs and client SDKs in any language. The wire format is binary protocol buffers; the transport is HTTP/2.

// users.proto
syntax = "proto3";
package users.v1;

service UserService {
  rpc GetUser(GetUserRequest) returns (User);
  rpc StreamUserEvents(StreamRequest) returns (stream UserEvent);
}

message GetUserRequest { string id = 1; }
message User {
  string id = 1;
  string name = 2;
  string email = 3;
}

Generate code:

protoc --go_out=. --go-grpc_out=. users.proto
# or for Node:
protoc --ts_proto_out=. --grpc_out=. users.proto

Use the client:

const client = new UserServiceClient('grpc.example.com:443');
const user = await client.getUser({ id: '42' });
console.log(user.name);

Strongly typed end-to-end. No JSON parsing. No “did the server change the response shape” because the proto file is the contract.

Where gRPC genuinely wins

1. Service-to-service traffic in a polyglot environment. A Go service calling a Python service calling a Node service. With JSON, each side maintains its own client and types. With gRPC, generate from the same proto.

2. High-volume internal traffic. Protobuf is 3-10× smaller than JSON for typical payloads. CPU is lower (no JSON parsing). For services exchanging millions of messages per minute, the difference is real bandwidth and compute savings.

3. Streaming. Server-streaming, client-streaming, and bidirectional streaming are first-class in gRPC. Far cleaner than DIY chunked HTTP or WebSockets for this.

4. Schema-driven workflow. The .proto is the source of truth. Generated clients prevent drift. Backwards compatibility is enforceable via proto rules.

Where REST is still better

1. Public-facing APIs. Browsers and curl speak HTTP/JSON natively. gRPC requires a proxy (gRPC-Web) to reach browsers, and curl-debugging gRPC is painful.

2. Third-party / partner integrations. “Here is our REST endpoint” is universally understood. “Here is our .proto” is not.

3. Caching and CDN-friendliness. REST endpoints can be cached at every layer (browser, CDN, reverse proxy) using standard HTTP semantics. gRPC, being POST-mostly, cannot.

4. Quick prototyping. A new endpoint in Express + JSON is faster to write than the proto + generation + grpc-server boilerplate.

For a public API, stay on REST (or GraphQL). For internal-only service-to-service, gRPC is often the better long-term call.

The connect-rpc middle ground

Connect is a protocol from Buf that wraps gRPC’s strengths in HTTP-friendly ergonomics. Same .proto schema. Generated clients. But the wire protocol can be JSON or protobuf depending on the client’s preference. Browsers and curl can hit the same endpoints that gRPC clients can.

// Server (Connect-Go, similar in TS):
const handler = createConnectHandler(UserService, {
  getUser: async (req) => ({ id: req.id, name: '...', email: '...' }),
});

# Browser / curl uses JSON
curl https://api.example.com/users.v1.UserService/GetUser -d '{"id":"42"}'

# gRPC client uses protobuf
const client = createPromiseClient(UserService, transport);
await client.getUser({ id: '42' });

Same code, two protocols. For most teams that want gRPC’s developer experience without giving up browser/curl access, Connect is the right answer.

Operational considerations

Service discovery. gRPC clients keep long-lived connections; the load balancer story is different than HTTP. Use client-side load balancing or a service mesh.

Observability. Tracing libraries (OpenTelemetry) support gRPC. But “show me the curl that triggered this” is harder. grpcurl exists; it’s not as familiar.

Backwards compatibility. Proto3 makes some things easier (added fields are ignored by old clients) and some harder (changing a field’s type is a break). buf breaking detects schema-breaking changes in CI.

Compression. HTTP/2 + gRPC supports compression natively (gzip, deflate). Configure based on payload sizes.

Migration patterns

If you decide to migrate from REST to gRPC for internal services:

1. Pilot one service-to-service path. Pick a high-volume internal hop. Implement gRPC alongside REST. Measure latency, payload size, code maintenance.

2. Generate types from proto for everyone. Even before switching the wire protocol, the typed contract is a win. Generate TypeScript / Go types from the proto and use them in your existing REST handlers.

3. Switch one direction at a time. Server adds gRPC support; clients move over one by one. REST endpoint stays alive during the migration.

4. Don’t migrate the public API. Customers want REST. Keep REST at the edge; use gRPC internally.

A typical migration of a 10-service mesh takes 3-6 months. The win compounds as more services move over.

A small concrete win

Before / after on a typical service hop:

Metric	REST/JSON	gRPC
Avg payload size	4.2 KB	0.9 KB
Avg request latency (p99)	35 ms	18 ms
Generated client maintenance	per-language hand-written	generated
Schema drift incidents/quarter	3-5	0

Numbers vary, but the pattern is consistent: smaller payloads, lower latency, fewer drift bugs. The trade-off is the proto build pipeline and harder ad-hoc debugging.

The team-process change

gRPC works best when proto files are reviewed like API contracts. Some teams put protos in a separate repo (buf.build registry, or a dedicated proto/ repo) and require PRs to be reviewed by the consuming team.

This is a culture shift. With JSON, services often “just shipped” changes hoping consumers caught up. With protos, changes are reviewed and breaking changes are explicit. The friction is positive; it forces conversations that should have been happening anyway.

The takeaway

gRPC is the right tool for internal high-volume polyglot service-to-service communication. REST is still the right tool for public APIs. Connect is the middle ground if you want gRPC’s schema and code generation without losing browser / curl support.

The migration is real work. Don’t switch out of fashion. Switch when you have evidence of the JSON tax (bandwidth bills, drift bugs, slow service-to-service calls) and a clear case for the gRPC win. For most internal-mesh teams of moderate complexity, the case is real.

---

A note from Yojji

The kind of architecture judgment that picks the right protocol for service-to-service communication (gRPC when its strengths matter, REST when its simplicity matters more) is the kind of senior engineering Yojji’s teams bring to client work.

Yojji is an international custom software development company founded in 2016, with teams across Europe, the US, and the UK. They specialize in the JavaScript ecosystem, cloud platforms, and microservices architectures, including the API and protocol decisions that decide whether your internal mesh stays manageable as it grows.