APIs are how different parts of a software system communicate.
A browser talks to a backend. A mobile app talks to services. Microservices talk to each other. External partners consume our APIs.
But not every API needs to work the same way.
Three approaches we encounter frequently are:
- REST: resource-oriented APIs
- GraphQL: query-oriented APIs
- gRPC: service-oriented, strongly typed APIs
They solve similar communication problems, but make very different tradeoffs.
The Big Picture
The easiest way to understand them is:
That's the fundamental difference.
1. REST
REST is built around resources.
For example:
GET /users/123
POST /users
GET /products
GET /orders/456
DELETE /orders/456
The client interacts with resources using standard HTTP methods.
A typical response might be:
{
"id": 123,
"name": "Alice",
"email": "alice@example.com"
}
The problem
REST endpoints often return a predefined representation.
Our UI might need only:
name
avatar
but the endpoint might return:
name
address
orders
preferences
subscriptions
...
This is over-fetching.
The opposite problem is under-fetching, we might need data from several endpoints to build one screen.
REST is great when:
- Our API maps naturally to resources
- We want a simple public API
- HTTP caching is important
- We need broad compatibility
- Our clients don't require highly customized responses
2. GraphQL
GraphQL changes the model.
Instead of asking:
"Give me the user resource."
the client asks:
"Give me exactly the fields I need."
For example:
query {
user(id: "123") {
name
avatar
posts {
title
}
}
}
The server resolves that query.
GraphQL is especially useful when different clients need different data.
For example:
Web → name + avatar + posts + comments
Mobile → name + avatar
TV → name + avatar + recommended videos
One schema can support all three without creating completely different REST endpoints.
GraphQL is great when:
- Frontend requirements change frequently
- Multiple clients need different data
- We have deeply related data
- We want clients to control the response shape
- Combining multiple data sources into one request is valuable
The tradeoff
GraphQL isn't automatically faster.
A poorly designed GraphQL query can trigger many backend operations.
We also need to think about:
- Query complexity
- Authorization
- Caching
- Resolver performance
- N+1 queries
3. gRPC
gRPC takes another approach. Instead of thinking primarily in terms of resources or queries, we have to think in terms of services and methods.
For example:
UserService
GetUser()
CreateUser()
DeleteUser()
ListUsers()
The service contract can be defined using Protocol Buffers.
service UserService {
GetUser(...)
CreateUser(...)
}
The communication flow looks like:
gRPC commonly uses:
- HTTP/2
- Protocol Buffers
- Binary serialization
- Strongly typed contracts
- Generated client/server code
- Streaming
This makes it particularly attractive for internal service-to-service communication.
Why gRPC Can Be Fast
JSON is text-based. Protocol Buffers encode data into a compact binary representation.
Instead of:
{
"userId": 123,
"name": "Alice"
}
the data is encoded according to a predefined schema.
This generally means smaller payloads and efficient serialization.
HTTP/2 also provides capabilities such as multiplexing and streaming.
gRPC is great when:
- Services communicate internally
- Low latency matters
- Strong contracts are important
- We control both client and server
- Streaming is useful
- We have many microservices
The downside?
It's less convenient for browsers and public APIs compared with REST or GraphQL.
REST vs GraphQL vs gRPC
| REST | GraphQL | gRPC | |
|---|---|---|---|
| Model | Resources | Queries | Services |
| Common format | JSON | JSON | Protobuf |
| Transport | HTTP | HTTP | HTTP/2 |
| Data fetching | Fixed responses | Client-defined | Method-defined |
| Browser support | Excellent | Excellent | More complex |
| Performance | Good | Good | Excellent |
| Caching | Easy | More complex | Different model |
| Streaming | Possible | Possible | Excellent |
| Best use | Public APIs | Frontend APIs | Internal services |
They Can Work Together
Here's the important part:
We don't necessarily have to choose one.
A large system might use GraphQL at the frontend boundary and gRPC internally.
For example:
Browser
↓
GraphQL
↓
Backend Services
↓
gRPC
↓
Internal Microservices
We could still expose REST APIs for external consumers.
This is often more realistic than trying to force an entire organization onto one API technology.
How Do We Choose?
Use this mental model:
This is not a strict rule, but it's a useful starting point.
Key Takeaways
- REST → resource-oriented communication.
- GraphQL → client-defined data queries.
- gRPC → strongly typed service communication.
- REST is often a strong choice for public APIs.
- GraphQL shines when frontend data requirements are complex.
- gRPC is excellent for internal microservices and high-performance communication.
- We can combine all three in the same architecture.
Conclusion
REST, GraphQL, and gRPC aren't simply competing technologies. They represent different ways of thinking about communication.
REST asks for a resource.
GraphQL asks for a specific data shape.
gRPC calls a strongly typed service.
The right choice depends on the clients, data requirements, performance constraints, caching strategy, and system boundaries.
