Don't Build Your API Until You Watch This (REST vs GraphQL vs gRPC)

Overview

The video contrasts REST vs GraphQL vs gRPC, using real-world examples and practical performance/architecture tradeoffs.

Real-world usage examples

• Netflix uses gRPC internally for service-to-service communication.
• GitHub supports REST and has invested in GraphQL.
• Stripe builds its payment API around REST.

REST (architecture + caching + “extra requests” risk)

• REST is described as an architectural style built around resources and a unified interface (HTTP methods).

Example issue

• GitHub’s REST API can display merge requests, but checking “mergeability” requires a separate fetch per item.

Potential cost

• Choosing REST can turn a single UI screen into many additional network requests before data is fully retrieved.

HTTP semantics and caching

• REST uses stateless requests (each request includes needed context).
• Supports caching via:
  • Cache-Control (max-age)
  • ETag validation
• With a matching ETag, servers can respond 304 Not Modified without retransmitting the body.

Composing data from multiple endpoints

• REST can fetch details, seller info, reviews from different endpoints, but dependent data can waste bandwidth and cause “extra cycles.”
• REST can support conventions like aggregated endpoints or field selection, but the team must design and maintain these conventions.

GraphQL (typed queries + field-level selection + batching concerns)

• GraphQL is described as a typed query language + execution system.

Addressing REST’s “N+1 fetch” problem

• Clients can request fields (e.g., mergeability) for the entire list in one query.

Field selection is part of the language

• The client specifies exactly which fields (including nested objects) it needs.
• The server validates queries against its schema, then executes resolvers to fetch requested fields.

Performance caveat

• GraphQL does not automatically transform the request into one optimized SQL query.
• Example: fetching 50 posts and each author.
  • Without optimization, resolvers might trigger many database requests (e.g., 51 DB requests per HTTP request).
• A data loader pattern can batch/reuse results, reducing many requests down to a small number.

Limits and safety controls

Nested lists can increase work, so you need:

• Pagination limits
• Query cost budgets

Caching note

• GraphQL GET requests can leverage HTTP caching, especially if using hashes of stored queries.
• A “single POST endpoint” setup doesn’t automatically get the same caching behavior.

gRPC (service contracts + Protocol Buffers + streaming)

• gRPC is described as a framework for Remote Procedure Calls based on a service contract.

Service contracts and generated code

• Developers define services and message types in a .proto file:
  • Code generation creates client stubs and server interfaces.
  • Application calls methods like getProduct; the stub handles serialization and transport.

Protocol Buffers encoding efficiency

• Uses numbered fields rather than sending field names every time.
• The video explains how an int32 field with a specific tag ID is encoded using a compact binary format before gRPC framing/HTTP overhead.

Streaming and call patterns

gRPC supports four RPC types:

1. Unary (request/response)
2. Server streaming
3. Client streaming
4. Bidirectional streaming (both sides send message sequences independently)

• Example: Google Cloud Speech-to-Text uses gRPC streaming (audio upstream, transcripts downstream).

Costs and operational considerations

• Tooling/code generation
• Schema compatibility management
• Infrastructure supporting gRPC
• Binary messages require decoding tools for verification

Browser integration

• Often relies on gRPC-web and a streaming proxy, which differs from native gRPC.

HTTP/2 note

• HTTP/2 is not exclusive to gRPC; REST/GraphQL can also use HTTP/2.

Decision guidance (when to use which)

• REST: Prefer when the API is called by partners/clients who benefit from stable resource endpoints and standard HTTP caching, with low need for complex batching.
• GraphQL: Prefer for apps that need custom data combinations per screen (e.g., mobile vs desktop) where batching via resolvers and client-driven field selection pays off—assuming you implement limits/budgets and resolver optimizations like data loaders.
• gRPC: Prefer for internal systems and controlled clients needing typed calls and especially two-way or streaming use cases (e.g., transcription pipelines).

Key takeaway

• Don’t choose purely by theory: measure real-world metrics before rewriting:
  • database query counts
  • payload sizes
  • cache hit rates
  • latencies under load

Main speakers/sources mentioned

• Netflix (uses gRPC)
• GitHub (invested in GraphQL alongside REST)
• Stripe (REST-based payments)
• Google Cloud Speech-to-Text (example of gRPC streaming)
• The video narrator/presenter (not individually identified in the subtitles)