REST vs GraphQL vs gRPC

REST: The Ubiquitous Foundation

Representational State Transfer (REST) is the standard architectural style for public-facing web services because it leverages existing Hypertext Transfer Protocol features. It treats every resource as a unique URI, allowing clients to interact with data using standard verbs like GET, POST, PUT, and DELETE. The core philosophy is statelessness: every request from the client must contain all necessary information for the server to fulfill it, which simplifies horizontal scaling of services behind a load balancer. Because it relies on text-based formats like JSON, it is highly interoperable across virtually any platform. However, REST often leads to 'over-fetching' or 'under-fetching' data because endpoints return fixed structures. When you need to retrieve nested relationships, you often end up making multiple sequential requests, which increases round-trip latency. It is ideal for public APIs where ease of consumption and caching at the CDN level are more important than minimizing the payload size for every internal call.

import requests

# Standard REST approach: accessing a specific resource
def get_user_profile(user_id):
    # REST relies on standard HTTP methods and URL paths
    url = f"https://api.example.com/users/{user_id}"
    response = requests.get(url)
    return response.json() # Returns a complete, predefined resource object

GraphQL: Solving Over-fetching

GraphQL was developed to solve the rigidity of REST by allowing clients to explicitly define the structure of the data they require in a single request. Instead of multiple endpoints, a GraphQL API exposes a single 'schema' that defines the graph of all available data. When a client performs a query, it specifies exactly which fields to return, preventing the overhead of transferring unused data. This is particularly valuable for mobile applications where bandwidth might be limited and battery life is a concern. The server validates the requested fields against the schema and executes 'resolvers' to fetch the data from underlying databases or microservices. While this flexibility is powerful, it shifts the complexity to the server, which must now handle complex query parsing, recursive relationship resolution, and protection against malicious, deeply nested queries that could exhaust system resources during execution.

import requests

# GraphQL allows the client to define the exact shape of the response
query = """
query GetUser($id: ID!) {
  user(id: $id) {
    name
    email
  }
}
"""
# Single request, only the fields 'name' and 'email' are returned
response = requests.post("https://api.example.com/graphql", json={'query': query, 'variables': {'id': 1}})

gRPC: Binary Efficiency

gRPC shifts the communication paradigm from resource-oriented text exchange to Remote Procedure Calls using a binary protocol. It uses Protocol Buffers (protobuf) as its interface definition language, which forces strict type checking on both the client and server sides. Because data is serialized into a compact binary format, it is significantly faster and more efficient than JSON-based text formats. Furthermore, gRPC is built on top of the multiplexing capabilities of HTTP/2, allowing multiple concurrent requests over a single TCP connection, which drastically reduces head-of-line blocking and connection handshake overhead. This makes it the preferred choice for internal microservices where high-performance, low-latency communication is non-negotiable. However, because it requires generating client-side stubs and is harder to debug through standard proxies or browser tools, it is typically restricted to internal server-to-server traffic rather than public-facing API exposure.

import grpc
# Assuming a pre-compiled protobuf stub
# gRPC uses binary serialization for extreme efficiency
def call_remote_service(user_id):
    channel = grpc.insecure_channel('internal-service:50051')
    stub = UserServiceClient(channel)
    # The request is strictly typed and serialized as binary data
    response = stub.GetUser(UserRequest(id=user_id))
    return response

Protocol Buffers: The Contract

The defining characteristic of gRPC is the usage of Protocol Buffers, which act as a contract for all communication. In REST or GraphQL, the data contract is often loose or inferred from JSON objects. With Protocol Buffers, you define messages and services in a `.proto` file, which is then used to generate boilerplate code for different programming environments. This ensures that the client and server are always in sync regarding data types and field IDs. If a field changes or is removed, the compilation step fails, preventing runtime serialization errors that are common in loosely typed environments. This structural rigor forces developers to design their service boundaries more thoughtfully, as changing the schema requires regenerating and redeploying the stubs. While this introduces a slightly higher overhead during the development lifecycle, it results in a much more stable and predictable production environment.

syntax = "proto3";

// Strict schema definition
message UserRequest {
  int32 id = 1;
}

message UserResponse {
  string name = 1;
  string email = 2;
}

Choosing the Right Tool

When designing a system, the choice of communication protocol is driven by the architectural boundaries. Use REST if you are building an open ecosystem where ease of integration for third-party developers is the highest priority. It remains the most widely supported standard, benefiting from ubiquitous tooling for documentation and caching. Choose GraphQL when you have a complex data graph and need to empower frontend clients to minimize the data retrieved per view, specifically in high-frequency mobile environments. Finally, deploy gRPC when building internal microservice meshes where low latency and high throughput are critical. The combination of binary serialization and HTTP/2 transport provides performance that text-based protocols simply cannot match at scale. Always evaluate the trade-off between the development speed of flexible protocols versus the operational stability of strictly typed systems to ensure your architecture remains performant and maintainable over the long term.

# Decision matrix logic
def select_protocol(env):
    if env == "public_api": return "REST"
    if env == "mobile_client": return "GraphQL"
    if env == "internal_microservices": return "gRPC"

Interview questions

All System Design interview questions →

Check yourself

Take the full System Design quiz →