Why internal gRPC and external REST can coexist cleanly, and how to explain that trade-off like a senior backend engineer.
Your win: explain when native gRPC is right, when grpc-gateway or REST is better at the boundary, and how to think about one contract serving two audiences.
In plain English Plain English: internal and external consumers often want different ergonomics, even when they touch the same underlying business capability.
The problem: the best internal interface is not always the best public one
Internal services like typed clients, binary payloads, and shared conventions. Browsers and third parties often like JSON, HTTP tooling, easier curlability, and broader ecosystem support. That is why API-boundary design is not just transport preference.
The senior move here is to stop asking “which protocol is better?” and start asking “better for which audience, at which boundary, with which maintenance cost?” That question produces much better architecture answers.
The decision rule Use gRPC where typed service-to-service calls, streaming, and internal efficiency matter most. Use a gateway or REST edge where external compatibility and tooling matter more.
Questions senior engineers ask
These questions keep the conversation architectural instead of ideological.
Who is the consumer?
Do they naturally speak gRPC?
Will HTTP/JSON ergonomics reduce integration cost?
Does one proto contract make sense for both internal and external semantics?
Should the public edge deliberately own a simpler surface than the internal one?
Anchor — what this repo already does This repo already shows the mixed model: internal service-to-service gRPC plus grpc-gateway for selected public HTTP/JSON paths. That is not inconsistency — it is boundary-aware design. The same system can make different interface choices at different edges and still be coherent.
Common mistake Treating the gateway as automatic proof that the same API shape is equally good for internal and external callers.
Read this next
gRPC-Gateway docs + gRPC introduction
Read the gateway docs together with the core gRPC framing so the trade-off stays architectural instead of tool-specific.
Q1. The best reason to put REST/JSON at the edge is…
Boundary choice is about audience fit, not about one protocol being globally superior.
Why can one system reasonably use both gRPC and REST?
recall, then click to reveal
Because internal and external boundaries often have different needs: internal callers benefit from typed efficient RPC, while external clients often benefit from JSON/HTTP ergonomics and broader tooling.
Want a side-by-side “internal gRPC vs external edge” explanation using our repo’s gateway paths, the same way Lesson 17 closes the loop? Ask me.