GraphQL vs gRPC: which API technology should you choose?

GraphQL and gRPC are the two most hyped alternatives to REST-style APIs, and people often ask which one to adopt. The honest answer is that they solve different problems. GraphQL is a data query language that runs over HTTP and returns JSON — it is a client-driven way to fetch and shape data. gRPC is a remote procedure call (RPC) framework that runs over HTTP/2 and sends binary Protocol Buffers — it is a high-performance, strongly typed way for services to call each other. GraphQL shines on the client-facing edge, where you do not control the consumers. gRPC shines in the service-to-service core, where you control both ends. This guide compares them across the choices that actually matter.

What GraphQL is

GraphQL is a data query and manipulation language that lets a client specify exactly what data it wants, and nothing more. Facebook started developing it in 2012 and released a draft specification and reference implementation as open source in 2015; in 2018 the project moved to the GraphQL Foundation, hosted by the non-profit Linux Foundation.

A GraphQL API is built around a schema: you define types and their fields, then provide resolvers — functions that fetch the data for each field. The type system is the contract. The root Query type names every field a client can ask for, and fields are typed, nullable by default with ! marking a required (non-null) field.

Clients send a query to a single endpoint. The server validates it against the schema, executes it, and returns a result that mirrors the shape of the query, typically as JSON:

query CurrentUser {
  currentUser {
    name
    age
  }
}

{ "currentUser": { "name": "John Doe", "age": 23 } }

Because the client names the exact fields, one round-trip can fetch precisely the nested data a screen needs — no over-fetching and no under-fetching, and no need for the server to invent a bespoke endpoint for every client shape. GraphQL also supports mutations for creating, updating, and deleting data, and subscriptions for live updates pushed from the server to subscribed clients (commonly implemented over WebSockets).

GraphQL takes a strong opinion against versioning. New fields or types can be added without a breaking change, old ones can be marked with the @deprecated directive, and servers commonly stay versionless.

What gRPC is

gRPC is an open-source RPC framework originally developed by Google and released in August 2016. Its core idea is that a client application can call a method on a server application on another machine as if it were a local object — making distributed applications feel like normal function calls.

gRPC uses Protocol Buffers (protobuf) both as its Interface Definition Language and as its binary message format. You write a .proto file that defines your service (with named RPC methods) and the messages those methods send and receive:

service Greeter {
  rpc SayHello (HelloRequest) returns (HelloReply) {}
}

message HelloRequest {
  string name = 1;
}

message HelloReply {
  string message = 1;
}

You then run the protoc compiler with a gRPC plugin, which generates client and server code in your language from that definition. The generated code handles serialization, deserialization, and the network call automatically.

Protocol Buffers use a compact binary encoding. A message encodes field numbers and wire types rather than repeating human-readable key names, so a protobuf payload is smaller and faster to parse than equivalent JSON. gRPC runs over HTTP/2, which brings multiplexing (many calls share one connection), header compression, and native bi-directional streaming.

The key differences

When GraphQL is the better choice

GraphQL wins on the client-facing edge, where consumers are varied and you cannot control them:

• Web and mobile clients that need exactly the right data. The client states its shape in the query; the server returns matching JSON with no over-fetching. This collapses many round-trips in data-heavy apps.
• Many unknown consumers. A schema is self-documenting, and clients can explore it via introspection without you shipping generated stubs.
• Public-facing APIs. Because GraphQL is just HTTP + JSON, browsers can call it natively with no proxy and no build step.
• Iterating without version hell. Add fields and mark old ones @deprecated; existing clients keep working while new clients adopt the addition.

GraphQL's main costs: a schema and resolvers are extra server machinery compared to plain REST; caching is harder because queries are per-client and don't map to fixed URLs; and one complex query can be expensive unless you add query-cost analysis and depth limiting.

When gRPC is the better choice

gRPC wins in the service-to-service core, where you control both ends:

• Internal microservices. A shared .proto contract generates compatible stubs in every supported language (Go, Java, Python, C#, Ruby, and more), so client and server stay in sync at compile time. This kills a whole class of serialization bugs.
• Low latency and high throughput. Binary protobuf is smaller and faster than JSON, and HTTP/2 multiplexing lets many calls share one connection. At scale this cuts latency and bandwidth.
• Bi-directional streaming. Server push and request/response streams are first-class, which is awkward with request/response REST or GraphQL subscriptions.
• Strongly typed, polyglot teams. The .proto file is the single source of truth, and codegen prevents drift.

gRPC's main costs: generated code and a build step rule out casual browser clients; the wire format is binary, so payloads are hard to read in logs; and it needs a proxy (or gRPC-Web) to work from a browser.

The honest downsides

GraphQL's flexibility has a real price: because the client dictates the query, servers need protection against abusive or accidental over-fetching (cost analysis, depth limits), and caching at the CDN level is hard since responses vary per query rather than per URL.

gRPC's price is ergonomics for people, not machines: it demands code generation, does not work directly in browsers, and produces binary payloads that are painful to debug. It also gives the client no power to shape responses — you get whatever the .proto defines.

FAQ

Is GraphQL faster than gRPC?

Not inherently. gRPC's binary Protocol Buffers and HTTP/2 multiplexing typically give lower latency and higher throughput than GraphQL's JSON over plain HTTP — the reason gRPC dominates internal service-to-service traffic. GraphQL's value is not raw speed but precise data fetching: it can reduce the number of round-trips a client needs, which often feels faster even though each call may be heavier. For small payloads with no nesting or streaming, the difference is usually negligible.

Can I use GraphQL and gRPC together?

Yes, and many systems do. A common pattern is GraphQL on the client-facing edge — where many unknown consumers query a schema over HTTP and get JSON — backed by gRPC services internally, where strongly typed, binary, low-latency calls happen between your own services. The GraphQL layer can resolve its fields by making gRPC calls to the services behind it.

Does gRPC use HTTP?

Yes. gRPC runs over HTTP/2 exclusively and leans on its features — multiplexing, header compression, and bi-directional streams. GraphQL, by contrast, is transport-agnostic in design but is almost always served over plain HTTP as JSON.

How do I expose a gRPC API to a browser?

Not directly. Browsers cannot send the HTTP/2 trailers gRPC uses for metadata, so you need either a proxy that translates between gRPC and HTTP/1.1, or the gRPC-Web protocol with its own proxy. gRPC-Web covers a subset of gRPC and does not support full bi-directional streaming. If your primary consumers are browsers, GraphQL (or REST) over plain HTTP is the practical choice.

Verdict

Choose GraphQL when your API sits on the edge and serves many clients you do not control — web apps, mobile apps, third parties — and you want them to fetch exactly the data they need over HTTP with a self-documenting schema. Choose gRPC when you control both ends of the connection and need the performance, strong typing, and streaming of an internal service mesh. If you have both, the strongest architecture is usually GraphQL in front, gRPC behind: GraphQL owns the developer-facing contract, gRPC owns the machine-to-machine trunk.