gRPC vs REST

Most of what gets written about this choice compares numbers a reader has no way to check: gRPC is faster, REST is simpler, pick one. That framing skips the one property of your situation that actually decides it, and it has nothing to do with either technology’s top speed. It is who is going to call the service you have not built yet — a browser, a partner integrating from outside, or a team on the other side of the same deploy pipeline. Answer that first and the rest of the comparison mostly answers itself.

What the contract changes#

gRPC normally defines service methods and message types in a .proto file and generates client/server code. Protobuf binary fields carry numeric tags, not field names. REST is an architectural style, not a JSON encoding rule; this comparison uses the common HTTP/JSON implementation. JSON carries names, but names alone do not explain allowed values or business meaning. A REST API can publish a schema through OpenAPI and generate clients too.

Generated APIs can catch some source-level changes during a typed-language build. They do not prove that deployed old and new services interoperate, and dynamic-language clients may discover a changed API at runtime. Protobuf’s evolution rules distinguish these boundaries: keep field numbers stable and reserve removed numbers instead of reusing them. A name-only rename may preserve the binary value; assigning a new meaning to the old tag may still compile and silently mislead an old reader.

# generated from the .proto — field names never travel on the wire
reply = orders_client.GetOrder(GetOrderRequest(order_id="ord-abcde"))

# illustrative hand-written HTTP/JSON call, not a generated client
resp = requests.get(f"{base_url}/orders/ord-abcde")
resp.raise_for_status()
order = resp.json()  # parses JSON; does not validate the order schema

Illustrative calls, with setup, credentials, timeouts and schema validation omitted. The HTTP example decodes JSON without validating its shape; a generated or validating client could do more. Neither call demonstrates business compatibility or safe retries.

Schema evolution needs compatible deployments or an explicit migration/versioning plan, whichever API style you choose. Regenerating clients alone does not upgrade callers already deployed. gRPC libraries can apply configured retry policies and limited transparent retries. Caller and server must agree which effects are safe to repeat; see idempotency keys and safe retries.

Who can actually call you#

A browser cannot call a gRPC service directly. gRPC’s messages travel inside HTTP/2 frames and depend on one part of HTTP/2 a browser’s own request APIs do not expose: the trailers that carry a call’s final status after the body has already streamed. Fetch and XMLHttpRequest give a script no way to read them, so a browser talking to a gRPC service needs something in front of it — a proxy, or middleware doing the same job in the same process — translating the call into something the browser can actually send and read. That layer is one more thing to deploy and keep working, not a rounding error.

HTTP/JSON has broad browser and request-tool support. gRPC callers need tooling that understands the protocol and message schema, but not necessarily a generated SDK: server reflection can let tools such as grpcurl discover the contract. Some partners already support gRPC well. Ask what their actual integration environment permits.

Native gRPC defines unary, server-streaming, client-streaming and bidirectional-streaming calls. Check the selected client: gRPC-Web support does not automatically include every native streaming mode. HTTP responses can stream too, for example through server-sent events; bidirectional browser designs often use WebSockets. Compare the needed communication shape, cancellation and backpressure rather than assuming HTTP means only a short response.

Choosing the encoding before the caller#

Consider a hypothetical browser API with small payloads and expensive database work. Smaller wire messages might save little of its overall latency, while a translation layer adds operational work. A different browser workload may benefit substantially. Measure representative payloads, tail latency, server cost and required tooling before attributing an improvement to the protocol.

Plan incident tooling as part of that decision: available schemas, reflection policy, request tracing and safe payload inspection. These are costs to investigate, not measured evidence that one protocol necessarily costs more than it saves.

Internal RPCs with supported clients and a useful streaming or generation model are strong candidates for gRPC; HTTP/JSON can also be a good internal choice. Retries, partial failure and timeouts apply to both. Continue with the distributed-systems path for those concerns.