Lesson 25 / 25
GraphQL & gRPC
Compare REST, GraphQL and gRPC and learn when each style fits public APIs, rich UIs or internal services.
GraphQL: one endpoint, exact fields
GraphQL exposes a single endpoint where the client specifies exactly which fields it wants across related resources in one query — fixing REST's over-fetching (unused fields) and under-fetching (needing several round trips) at the cost of a more complex server and caching story.
gRPC: binary, typed, fast
gRPC calls typed functions over HTTP/2 using compact binary Protocol Buffers instead of JSON text — much faster to (de)serialize, with strict schemas and streaming built in. It's less browser-friendly and less human-readable than REST.
When you'd reach for each
REST: public APIs, simple resources, wide tooling and caching support. GraphQL: rich UIs (mobile/web) pulling nested data from many sources with varying needs per screen. gRPC: service-to-service calls inside your own infrastructure where speed and strict contracts matter more than browser access.
Quick check: A mobile app screen needs a user's profile, their last 3 orders, and their unread notification count in one round trip, with minimal extra data. What fits best?
- A single GraphQL query naming exactly those fields
- Three separate REST calls
- A gRPC streaming call
- Polling a SOAP service
Answer
A single GraphQL query naming exactly those fields — GraphQL is built for exactly this: one query pulling exactly the needed fields across multiple resources, avoiding both extra round trips and unused data.
Final quiz 1 of 8
Final quiz
Quick check: Which HTTP method replaces a resource entirely and is idempotent?
- POST
- PATCH
- PUT
- GET
Answer
PUT — PUT replaces the resource with the supplied body, so repeating it gives the same result.
Final quiz 2 of 8
Final quiz
Quick check: Which status code fits a successful POST that created a resource?
- 200 OK
- 204 No Content
- 302 Found
- 201 Created
Answer
201 Created — 201 signals creation and usually includes a Location header.
Final quiz 3 of 8
Final quiz
Quick check: Why prefer cursor pagination for large changing datasets?
- It stays fast and stable under inserts
- It lets you jump to page 10
- It needs no limit
- It avoids sorting
Answer
It stays fast and stable under inserts — Cursors avoid slow OFFSET scans and shifting pages.
Final quiz 4 of 8
Final quiz
Quick check: Which change is breaking and needs a new API version?
- Adding an optional field
- Renaming a response field
- Adding a new endpoint
- Improving docs
Answer
Renaming a response field — Clients that read the old field name would fail.
Final quiz 5 of 8
Final quiz
Quick check: Why keep a JWT access token short-lived?
- Because it is large
- Because it needs a database
- Because it cannot be easily revoked
- Because it is encrypted
Answer
Because it cannot be easily revoked — Short expiry limits damage if a token leaks; refresh tokens renew it.
Final quiz 6 of 8
Final quiz
Quick check: What should an API return when a client exceeds its rate limit?
- 403 Forbidden
- 200 OK
- 404 Not Found
- 429 Too Many Requests
Answer
429 Too Many Requests — 429 plus Retry-After helps clients back off.
Final quiz 7 of 8
Final quiz
Quick check: What does an Idempotency-Key header protect against?
- Duplicate processing of retried requests
- Slow queries
- Cross-site scripting
- Large payloads
Answer
Duplicate processing of retried requests — The server replays the first result when the same key returns.
Final quiz 8 of 8
Final quiz
Quick check: What does a matching ETag with If-None-Match return?
- 200 with the full body
- 304 Not Modified with no body
- 404 Not Found
- 409 Conflict
Answer
304 Not Modified with no body — The body stays off the wire while freshness is confirmed.