GraphQL vs REST vs gRPC: Choosing the Right API Protocol in 2026

Every backend team eventually faces this decision. REST is familiar. GraphQL promises flexibility. gRPC claims performance. In practice, each protocol solves a different problem — and choosing the wrong one for your use case creates real costs.

This guide cuts through the marketing to show where each protocol wins, with working code for the same product catalog API implemented in all three.

---

The Problem Each Protocol Solves

The common mistake: choosing GraphQL because it sounds modern, then spending weeks implementing subscriptions and cache invalidation for a basic CRUD API that REST would have handled in days.

---

REST: The Baseline

REST's strength is ubiquity. Every HTTP client speaks it. CDNs cache it. Browser DevTools display it natively. For most APIs serving external clients or browser frontends, REST remains the safest default.

Product catalog REST API (Fastify + TypeScript):

// routes/products.ts
import { FastifyInstance } from 'fastify';
import { z } from 'zod';

const ProductQuerySchema = z.object({
  category: z.string().optional(),
  minPrice: z.coerce.number().optional(),
  maxPrice: z.coerce.number().optional(),
  page: z.coerce.number().default(1),
  limit: z.coerce.number().max(100).default(20),
});

export async function productRoutes(app: FastifyInstance) {
  // GET /products — paginated list with filters
  app.get('/products', async (request, reply) => {
    const query = ProductQuerySchema.parse(request.query);
    const offset = (query.page - 1) * query.limit;

    const [products, total] = await Promise.all([
      db.product.findMany({
        where: {
          categorySlug: query.category,
          price: {
            gte: query.minPrice,
            lte: query.maxPrice,
          },
        },
        skip: offset,
        take: query.limit,
        orderBy: { createdAt: 'desc' },
      }),
      db.product.count({ where: { categorySlug: query.category } }),
    ]);

    return reply.send({
      data: products,
      pagination: {
        page: query.page,
        limit: query.limit,
        total,
        pages: Math.ceil(total / query.limit),
      },
    });
  });

  // GET /products/:id — single product with relations
  app.get<{ Params: { id: string } }>('/products/:id', async (request, reply) => {
    const product = await db.product.findUnique({
      where: { id: request.params.id },
      include: {
        category: true,
        variants: true,
        reviews: { take: 5, orderBy: { createdAt: 'desc' } },
      },
    });

    if (!product) return reply.code(404).send({ error: 'Product not found' });
    return reply.send({ data: product });
  });
}

REST's Achilles heel: the mobile app wants product name + thumbnail only. The endpoint returns the full object including variants and reviews. That's over-fetching — wasted bandwidth on mobile networks.

---

GraphQL: When Clients Drive the Query Shape

GraphQL shines when different clients (mobile, web, third-party) need different data shapes from the same API. Instead of versioning endpoints or adding ?fields= hacks, clients declare exactly what they need.

Same product catalog in GraphQL (Apollo Server):

// schema/product.graphql
type Product {
  id: ID!
  name: String!
  slug: String!
  price: Float!
  images: [String!]!
  category: Category!
  variants: [ProductVariant!]!
  reviews(limit: Int = 5): [Review!]!
  averageRating: Float
  inStock: Boolean!
}

type Category {
  id: ID!
  name: String!
  slug: String!
}

type Query {
  product(id: ID!): Product
  products(
    category: String
    minPrice: Float
    maxPrice: Float
    page: Int = 1
    limit: Int = 20
  ): ProductConnection!
}

type ProductConnection {
  nodes: [Product!]!
  pageInfo: PageInfo!
  totalCount: Int!
}

// resolvers/product.ts
export const productResolvers = {
  Query: {
    product: async (_: unknown, { id }: { id: string }) => {
      return db.product.findUnique({ where: { id } });
    },
    products: async (_: unknown, args: ProductQueryArgs) => {
      const offset = (args.page - 1) * args.limit;
      const [nodes, totalCount] = await Promise.all([
        db.product.findMany({
          where: buildProductWhere(args),
          skip: offset,
          take: args.limit,
        }),
        db.product.count({ where: buildProductWhere(args) }),
      ]);
      return { nodes, totalCount };
    },
  },
  Product: {
    // DataLoader prevents N+1 queries for nested fields
    category: async (product: Product, _: unknown, { loaders }: Context) => {
      return loaders.category.load(product.categoryId);
    },
    reviews: async (product: Product, { limit }: { limit: number }) => {
      return db.review.findMany({
        where: { productId: product.id },
        take: limit,
        orderBy: { createdAt: 'desc' },
      });
    },
    averageRating: async (product: Product) => {
      const result = await db.review.aggregate({
        where: { productId: product.id },
        _avg: { rating: true },
      });
      return result._avg.rating;
    },
  },
};

Mobile client query — only what it needs:

query MobileProductCard($id: ID!) {
  product(id: $id) {
    id
    name
    price
    images
    inStock
  }
}

Web client query — full detail:

query ProductDetail($id: ID!) {
  product(id: $id) {
    id
    name
    price
    images
    category { name slug }
    variants { id size color price stock }
    reviews(limit: 10) { id rating body author { name } }
    averageRating
  }
}

GraphQL's real costs: You need DataLoaders to prevent N+1 queries, a caching strategy that isn't just Cache-Control headers, query depth limiting to prevent DoS, and more complex error handling than HTTP status codes. Factor this into your decision.

---

gRPC: Service-to-Service Performance

gRPC uses Protocol Buffers (binary serialization) over HTTP/2. It's not designed for browser clients — it's designed for internal microservice communication where latency and throughput matter.

Same product catalog in gRPC (proto definition):

// product.proto
syntax = "proto3";
package catalog;

service ProductService {
  rpc GetProduct(GetProductRequest) returns (Product);
  rpc ListProducts(ListProductsRequest) returns (ProductList);
  rpc StreamProductUpdates(StreamRequest) returns (stream ProductEvent);
}

message GetProductRequest {
  string id = 1;
}

message ListProductsRequest {
  optional string category = 1;
  optional float min_price = 2;
  optional float max_price = 3;
  int32 page = 4;
  int32 limit = 5;
}

message Product {
  string id = 1;
  string name = 2;
  string slug = 3;
  float price = 4;
  repeated string images = 5;
  bool in_stock = 6;
  string category_id = 7;
}

message ProductList {
  repeated Product products = 1;
  int32 total_count = 2;
}

message ProductEvent {
  string event_type = 1;  // "created" | "updated" | "deleted"
  Product product = 2;
  int64 timestamp = 3;
}

// gRPC server (Node.js)
import * as grpc from '@grpc/grpc-js';
import * as protoLoader from '@grpc/proto-loader';

const packageDef = protoLoader.loadSync('product.proto');
const proto = grpc.loadPackageDefinition(packageDef) as any;

const server = new grpc.Server();
server.addService(proto.catalog.ProductService.service, {
  GetProduct: async (call: any, callback: any) => {
    try {
      const product = await db.product.findUnique({
        where: { id: call.request.id },
      });
      if (!product) {
        return callback({ code: grpc.status.NOT_FOUND });
      }
      callback(null, productToProto(product));
    } catch (err) {
      callback({ code: grpc.status.INTERNAL });
    }
  },

  StreamProductUpdates: (call: any) => {
    // Redis pub/sub → stream to gRPC client
    const sub = redis.subscribe('product-events', (message) => {
      call.write(JSON.parse(message));
    });

    call.on('cancelled', () => sub.unsubscribe());
  },
});

gRPC benchmarks vs REST (same payload, same hardware, Vegeta load test):

These numbers matter when your order service calls the product service 50,000 times per minute.

---

Decision Framework

Is this a browser/mobile client-facing API?
├── YES → REST or GraphQL
│   ├── Multiple client types need different data shapes? → GraphQL
│   ├── Simple CRUD / standard resource model? → REST
│   └── Real-time updates needed? → REST + WebSocket or GraphQL Subscriptions
└── NO → Internal service communication?
    ├── Latency-critical / high throughput? → gRPC
    ├── Streaming (server push, bidirectional)? → gRPC
    └── Simple, low-frequency calls? → REST (lower ops overhead)

Common combinations that work well:

• Public API: REST → standard, cacheable, CDN-friendly
• BFF (Backend for Frontend): GraphQL → different clients, one flexible API
• Internal services: gRPC → performance, strong contracts, code generation
• Mixed: REST public + gRPC internal (most production systems eventually land here)

---

Feature Comparison

---

Implementation Cost

A typical REST API layer for a mid-size app: 40–80 hours. Equivalent GraphQL with DataLoaders and subscriptions: 80–140 hours. gRPC service pair with proto definitions and generated clients: 60–100 hours.

---

Working With Viprasol

We've designed and built API layers in all three protocols — REST for public integrations, GraphQL for multi-client products, and gRPC for high-throughput internal services. Our recommendations are driven by your actual client surface and traffic patterns, not protocol preference.

→ Talk to our API team about your architecture.

---

See Also

• GraphQL API Development — deep dive on schema design and resolvers
• API Security Best Practices — securing any protocol
• Microservices Development — gRPC in a service mesh
• API Gateway Patterns — routing and auth in front of any protocol
• Web Development Services — backend API design and implementation