GraphQL vs REST

NetworkingSeniorapidata-structuresnetworking

The Question

What are the differences between GraphQL and REST?

What a Strong Answer Covers

• over/under-fetching
• "single endpoint
• "caching downside

Senior-Level Answer

REST and GraphQL are both API paradigms, but they optimise for different constraints. The right choice depends on client diversity, data shape variability, team structure, and caching requirements.

**Data fetching model**: REST organises resources at fixed URLs; a client fetches `/users/1` and `/users/1/orders` in two round trips. GraphQL exposes a single endpoint where the client specifies exactly which fields it needs in one query, eliminating over-fetching (receiving unused fields) and under-fetching (needing multiple requests). This is the primary driver for GraphQL adoption in mobile clients where bandwidth and latency are constrained.

**Schema and type system**: GraphQL has a mandatory, strongly-typed schema (SDL) that serves as a contract between client and server. Introspection lets tooling auto-generate documentation, type-safe clients, and mocks. REST has no built-in schema standard, though OpenAPI/Swagger fills this gap. The GraphQL schema makes breaking changes visible immediately and enables powerful developer tooling (GraphiQL, code generators).

**Versioning**: REST APIs typically version via URL (`/v2/`) or headers. GraphQL avoids versioning by evolving the schema additively—new fields are added, old ones deprecated. This requires careful schema governance but eliminates the maintenance burden of parallel API versions.

**Caching**: REST maps naturally to HTTP caching—GET requests are cacheable by URL at CDN and browser layers with no extra work. GraphQL queries are typically POST requests to a single URL, which breaks HTTP caching. Per-query caching requires either query hashing, persisted queries, or application-layer caches (DataLoader, Redis). This is a meaningful operational complexity cost.

**N+1 problem**: GraphQL's flexible resolution model can trigger N+1 database queries (one query per list item for a nested field). The standard mitigation is the DataLoader pattern—batching and deduplicating resolver calls within a single request.

**When to choose each**: REST is simpler, benefits from HTTP caching natively, and is well-understood by every HTTP toolchain. Choose GraphQL when you have multiple clients (web, mobile, third-party) with divergent data requirements, or when reducing mobile round trips is a priority. Many organisations use REST for public APIs (cacheability, simplicity) and GraphQL for internal/BFF (Backend-for-Frontend) layers.

Key Differences

What Separates a 2/3 from a 3/3

Common Mistakes

• Saying GraphQL is strictly better—ignoring the HTTP caching regression and operational complexity.
• Not mentioning the N+1 problem and DataLoader pattern.
• Treating GraphQL versioning as automatic—it still requires schema governance and careful deprecation.
• Claiming REST can't have a type system—OpenAPI provides this.

Follow-Up Questions

• How does DataLoader solve the N+1 problem in a GraphQL server? — It batches all resolver calls for the same resource within a single request tick, then issues one bulk query.
• How would you implement caching for a GraphQL API served behind a CDN? — Use persisted queries (hash → query string) so GET requests with the hash are cacheable by URL.
• When would you use a REST API for a public API even if you use GraphQL internally? — Public APIs benefit from HTTP caching, simpler client libraries, and are easier for third-party developers who may not know GraphQL.
• How do you handle authorization at the field level in GraphQL? — Resolver-level checks, schema directives (@auth), or a dedicated authorization layer like GraphQL Shield.

Related Questions

• TCP — 3-Way Handshake
• TLS — Certificate, DH, AES
• TCP vs UDP
• HTTP vs HTTPS
• WebSockets