How GraphQL works inside

A schema defines types, and each field has a resolver, a small function that knows where to get that field (a DB query, a REST call, a gRPC call, another service). The server parses the query, runs only the resolvers for requested fields, and assembles one JSON response. If you ask only for name, the email resolver never runs.

Query: { users(ids: [1..100]) { name } }. A naive name resolver that calls the user service once per user makes 1 call for the list plus 100 for the items. The fix is batching: a tool like DataLoader collects all 100 lookups from one query and issues one batched call.

SELECT id, name FROM users WHERE id IN (1, 2, ..., 100)   -- 1 call, not 100

• Batching and column picking happen in your resolver and data-layer code, not in GraphQL itself.
• A well-built resolver reads which fields were requested and selects only those columns (SELECT name). Prisma, Hasura and Postgraphile can do this automatically.
• The naive version does SELECT * and lets GraphQL filter the response. The client still gets only name; the waste is between your server and the DB.
• ORMs help but do not batch by themselves; you wire DataLoader up.

Client query -> GraphQL layer (which fields?) -> resolver -> batched DB or service call

Federation (Apollo Federation) lets each team own part of the schema while one gateway stitches them together.

• Pro: no over-fetching or under-fetching, and fewer round trips for mobile.
• Con: one expensive query can overload backends, so add depth and complexity limits.
• Con: HTTP caching is harder than REST (everything is a POST to one URL), so caching moves to the resolver or field level.
• Con: you must handle N+1 yourself.

Pick it when many clients (web, mobile, partners) have different data needs. Skip it for simple CRUD or internal service-to-service calls, where REST or gRPC is simpler.