REST vs gRPC vs GraphQL
Three API paradigms: REST uses HTTP + JSON with resource-oriented URLs; gRPC uses HTTP/2 + Protobuf with strongly-typed RPC definitions; GraphQL uses HTTP + JSON with a query language where clients declare the exact data shape they need.
REST = a restaurant menu (fixed dishes, you get what's listed). GraphQL = a buffet (pick exactly what you want). gRPC = a drive-through intercom (super fast, pre-defined combos, but you need to speak the lingo).
REST is the most widely adopted, easiest to debug (human-readable JSON, curl-able), and has the best ecosystem support. It over-fetches by default (returns full resource even if you need two fields) and requires multiple round trips for related data. gRPC is 5–10x faster than REST for the same payload due to binary serialization and HTTP/2 multiplexing — ideal for internal service-to-service communication. Its strong schema (proto files) enables automatic code generation and backward-compatibility checks. GraphQL excels for complex UIs with many entity types and client teams with different data needs — one query replaces many REST calls. It introduces N+1 resolver problems and complex authorization at the field level.
gRPC's HTTP/2 transport provides multiplexed streams, enabling bidirectional streaming — a pattern not possible with REST. This is key for real-time data push (server streaming), file uploads (client streaming), and WebRTC signaling. gRPC-Web bridges the gap to browser clients where raw HTTP/2 is not directly accessible. GraphQL's N+1 problem is solved with DataLoader — batching and caching resolver queries within a single request execution. For authorization in GraphQL, field-level permissions require middleware that inspects the query AST before execution, which is significantly more complex than REST endpoint-level auth. Protobuf schema evolution rules: you can add new fields with new field numbers and mark old fields as deprecated, but you can never reuse a field number or change a field type — these are breaking changes.
I use REST for public APIs (developer ergonomics, wide tooling support), gRPC for internal service-to-service calls (performance, strong typing, streaming), and GraphQL for BFF layers serving complex UIs (eliminates over-fetching, single endpoint for all client data needs). The decision is rarely one-or-the-other — a mature system uses all three in different layers.
Using gRPC for public APIs without a transcoding layer. Browser clients cannot call gRPC directly. You need grpc-gateway or Envoy transcoding to expose a REST/JSON facade over your gRPC services for external consumers.