Backend
GraphQL
A query language where the client asks for exactly the fields it wants from a single endpoint, eliminating over- and under-fetching and most versioning churn. It shines for rich frontends and mobile on slow networks. The costs: server-side complexity, POST queries that are hard to cache, and N+1 resolver problems you must batch away.
Purpose
GraphQL is a query language and runtime where the client declares exactly which fields it wants from a single endpoint, and the server returns that shape and nothing more. It was created to cure the over- and under-fetching and endpoint sprawl that REST accumulates as user interfaces grow.
When to Use It
It shines for rich, fast-changing frontends and mobile clients on slow networks, and for stitching several backends together behind one graph. When many client teams consume one API, they can evolve independently without new endpoints.
It is overkill for simple CRUD or internal service-to-service calls, and its caching story is weaker than REST's — plain REST is often better for small or public APIs.
Trade-offs
You trade REST's simplicity and free HTTP caching for client flexibility. Costs include server-side complexity, queries sent as POST that a CDN cannot cache by URL, the risk of expensive deeply-nested queries, and the N+1 problem where a naive resolver hits the database once per item.
Implementation
Define a typed schema (types, queries, mutations) and write resolvers per field. Batch and cache datastore access with a tool like DataLoader to kill N+1 queries, and defend the endpoint with query depth/complexity limits and timeouts. Persisted queries let you cache responses and restrict which operations clients may run.