Skip to content
tezvyn:
Menu

GraphQL versus REST data fetching

Source: interviewMediumHow cards are made

Summary

understanding of query-driven fetching.

Key points

one endpoint, client-specified fields avoid over- and under-fetching; Apollo's useQuery returns loading, error, and data while caching results.

What's really being asked

Whether you understand the structural difference between REST's server-defined responses and GraphQL's client-defined queries, and how a client library manages the resulting state.

The full answer

REST offers multiple endpoints each returning a fixed payload, so a screen often over-fetches unused fields or under-fetches and makes several round trips to assemble data. GraphQL exposes a single endpoint and a typed schema; the client sends a query naming exactly the fields and nested relations it wants, and the server returns precisely that shape in one request, eliminating over- and under-fetching. Apollo Client wraps this: you define a query with gql, call useQuery(QUERY, { variables }), and receive { loading, error, data } so the component renders the right state without manual flags. Apollo also normalizes responses into an in-memory cache keyed by type and id, so repeated or overlapping queries are served instantly and updates propagate.

The mistakes people make

Thinking GraphQL needs many endpoints, that it cannot be cached, or that it always outperforms REST. Ignoring that a poorly designed query can still be expensive on the server, or that GraphQL pushes complexity to the resolver layer, shows incomplete understanding.

What usually comes next

How does Apollo's normalized cache work? What are mutations and how do they update the cache? How do over-fetching and the N+1 resolver problem relate? When is REST simpler?

A concrete example

Instead of GET /users/1 then GET /users/1/posts, a single GraphQL query asks { user(id: 1) { name posts { title } } } and returns just the name and post titles. In React Native, const { loading, error, data } = useQuery(GET_USER, { variables: { id: 1 } }); renders a spinner while loading, an error view on failure, and the user once data arrives, with the result cached for the next render.

Interview question

What problem common to REST does a GraphQL query directly solve when a screen needs only a few fields from related resources?

  • a.Client-side caching, which REST APIs are technically incapable of supporting
  • b.Type safety, because REST responses can never be validated against a schema
  • c.The need for authentication, since GraphQL endpoints are public by design
  • d.Over-fetching and multiple round trips, by returning exactly the requested fields in one requestCorrect
Why?

GraphQL lets the client request precisely the fields it needs in a single call, avoiding REST's over-fetching and extra round trips. GraphQL still needs auth, REST can be cached, and REST responses can be schema-validated, so those options are false.

Just read this? Test yourself on what you have been reading.

Read the original → apollographql.com

Put your scrolling time to good use

Learn one idea, try a quiz and save useful cards for revision. Tezvyn makes it easy to learn and stay current in your tech field, a few minutes at a time.

The iPhone app is on the way

We are building it. Until it lands, nothing here is held back from you: every interview card, your saved cards, streaks and the job board all work in Safari, plus hundreds of free practice quizzes of thirty questions each. Sign in and it all carries over to the app the day it arrives.

Want it as an icon? Tap Share at the bottom of Safari, then Add to Home Screen. It opens full screen and the cards you have read stay available offline.

Get it on Google PlayiPhone app coming soon

We are hiring for this. Every open role lists the topics its interview covers, so you can prepare for the real thing rather than guessing.

See open roles