REST vs GraphQL vs gRPC: How to Choose

When someone asks you in an interview "which API style would you use and why?" — a lot of junior developers freeze. Not because they don't know what REST or GraphQL is, but because they've never had a clear framework for making that call.

This post breaks down all three — what they are, what they're good at, where they fall short — and gives you a practical decision framework you can actually use, both on the job and in interviews.

REST

REST (Representational State Transfer) is the most widely used API style on the web. It's built around resources and HTTP methods. You have a URL that represents something — a user, a product, an order — and you interact with it using GET, POST, PUT, DELETE, and so on.

The idea is simple: your API mirrors the structure of your data. Want a user? GET /users/1. Want their orders? GET /users/1/orders. It's intuitive, stateless, and works with every HTTP client out there.

Strengths:

Simple to understand and document
Works natively with browsers and HTTP tools
Great caching support via HTTP
Huge ecosystem of tooling and knowledge

Weaknesses:

Over-fetching: you get back more data than you need
Under-fetching: one request often isn't enough, so you end up chaining multiple calls
Versioning gets messy (/v1/, /v2/) as your API evolves

GraphQL

GraphQL was created by Facebook to solve a specific problem: mobile clients on slow networks were getting hammered by over-fetching and multiple round trips. The idea is to give the client control over exactly what data it asks for — in a single request.

Instead of multiple endpoints, you have one (/graphql) and the client sends a query describing exactly the shape of the data it wants. The server returns exactly that — nothing more, nothing less.

Strengths:

Clients ask for exactly what they need — no wasted data
One endpoint, one request — eliminates chaining
Self-documenting via the schema (introspection)
Great for complex, nested data relationships

Weaknesses:

More complex to set up and reason about on the server side
Caching is harder — you can't rely on HTTP cache the same way
Can be overkill for simple APIs
N+1 query problems on the backend if not handled carefully (e.g. with DataLoader)

gRPC

gRPC is a framework built by Google. It's fundamentally different from REST and GraphQL because it doesn't use JSON over HTTP/1.1 — it uses Protocol Buffers (a binary serialization format) over HTTP/2.

You define your service and messages in a .proto file, and gRPC generates client and server code for you in multiple languages. It's fast, strongly typed, and built for service-to-service communication.

Strengths:

Very fast — binary format is smaller and faster to parse than JSON
Strongly typed contracts via .proto files
Built-in support for streaming (client, server, and bidirectional)
Great for polyglot environments (generates code for Go, Java, Python, Node.js, etc.)

Weaknesses:

Not browser-friendly out of the box (requires gRPC-Web as a workaround)
Harder to debug — binary format isn't human-readable
Steeper learning curve
Overkill for public-facing APIs

How They Compare

	REST	GraphQL	gRPC
Protocol	HTTP/1.1	HTTP/1.1	HTTP/2
Data format	JSON (usually)	JSON	Protocol Buffers (binary)
Best for	Public APIs, CRUD apps	Complex frontends, mobile clients	Internal microservices
Caching	Excellent (HTTP native)	Difficult	Limited
Streaming	Limited	Subscriptions	First-class support
Type safety	Optional (OpenAPI)	Schema-enforced	Strict `.proto` contracts
Browser support	Native	Native	Requires gRPC-Web
Learning curve	Low	Medium	High

How a Client Talks to Each

Here's a visual of how a client might fetch a user's profile and their recent posts using each API style:

sequenceDiagram
    participant Client
    participant REST_API
    participant GraphQL_API
    participant gRPC_Service

    Note over Client, REST_API: REST — multiple round trips
    Client->>REST_API: GET /users/1
    REST_API-->>Client: { id, name, email, address, ... }
    Client->>REST_API: GET /users/1/posts
    REST_API-->>Client: [{ id, title, body, ... }, ...]

    Note over Client, GraphQL_API: GraphQL — one request, exact shape
    Client->>GraphQL_API: query { user(id:1) { name posts { title } } }
    GraphQL_API-->>Client: { user: { name, posts: [{ title }] } }

    Note over Client, gRPC_Service: gRPC — binary, typed, fast
    Client->>gRPC_Service: GetUserWithPosts(userId: 1)
    gRPC_Service-->>Client: UserWithPosts { name, posts }

The REST example needs two requests. GraphQL collapses that into one, and returns only what you asked for. gRPC skips JSON entirely and sends a compact binary message defined by a .proto contract.

Decision Framework: How to Choose

This is the part that actually matters in interviews. Don't think about which technology is "best" — think about what the system needs.

Ask yourself these questions:

1. Who is consuming the API?

External developers or browsers → REST is the safest default. It's universally understood.
Your own frontend or mobile app with complex data needs → GraphQL is worth the setup cost.
Internal services talking to each other → gRPC is likely the right call.

2. How varied are the clients?

One frontend with predictable data needs → REST is fine.
Multiple clients (web, mobile, third-party) that need different data shapes → GraphQL saves you from building multiple endpoints or over-fetching.
Backend services with different languages → gRPC's code generation handles this cleanly.

3. Does performance matter at the wire level?

Standard web traffic → REST or GraphQL, JSON overhead is negligible.
High-throughput, low-latency internal communication → gRPC's binary format gives you a real edge.

4. Do you need streaming?

Real-time updates (chat, live feeds) → GraphQL subscriptions or gRPC streaming.
Simple request/response → REST or GraphQL queries.

5. What's the team's familiarity?

Junior team or new project → REST is the lowest-friction starting point.
Team already using a schema-first workflow → GraphQL or gRPC fits naturally.

A simple rule of thumb:

Public API → REST
Complex frontend / multiple clients → GraphQL
Internal microservices → gRPC

🚩 Red Flags: Wrong Reasons to Pick Each One

Watch out for these in interviews — and in real projects:

Picking GraphQL because "it's modern" — GraphQL adds real complexity. If your API is simple CRUD and you have one client, REST is genuinely better. Don't use GraphQL to sound trendy.

Picking gRPC for a public API — gRPC isn't browser-native. If external developers need to consume your API, gRPC is the wrong tool unless you're providing SDK wrappers. REST is the standard for a reason.

Picking REST for everything, always — REST is great, but it has real limits. If you have 10 microservices talking to each other at high frequency, you're leaving performance on the table compared to gRPC.

Avoiding gRPC because it "looks complicated" — It has a learning curve, but the .proto contract is actually one of its best features. Strongly typed service contracts reduce bugs between teams significantly.

Conclusion

There's no universally correct answer to "which API style should I use?" — and that's exactly what makes it a good interview question. What interviewers are really testing is whether you can reason about trade-offs rather than recite a favourite.

The mental model is straightforward: public-facing and simple → REST; client-driven and data-heavy → GraphQL; internal and performance-critical → gRPC. From there, layer in your team's experience, your caching needs, and your streaming requirements.

Know why you're picking something. That's the answer they're looking for.

Daily Chronicle

REST vs GraphQL vs gRPC: How to Choose

REST

GraphQL

gRPC

How They Compare

How a Client Talks to Each

Decision Framework: How to Choose

A simple rule of thumb:

🚩 Red Flags: Wrong Reasons to Pick Each One

Conclusion

Related Posts