GraphQL versus REST data fetching

WHAT THIS TESTS 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.

A GOOD ANSWER COVERS 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.

COMMON WRONG ANSWERS 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.

LIKELY FOLLOW-UPS 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?

ONE 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.