GraphQL Interview Questions and Answers

Because clients can compose arbitrarily deep and wide queries, a single request can exhaust the database.

Defences:

• Limit query depth, for example reject anything deeper than ten levels.
• Assign a cost to each field and reject queries whose total exceeds a budget, charging more for list fields and expensive joins.
• Require persisted queries so only pre-approved operations run in production, which also shrinks payloads.
• Disable or restrict introspection in production, and apply per-client rate limits and timeouts.
• Cap pagination arguments and reject requests without a limit.

const server = new ApolloServer({
  validationRules: [depthLimit(10), createComplexityLimitRule(1000)],
});

Combine these with database query timeouts and monitoring so a bad query is cut off before it degrades shared resources. Depth alone is insufficient because a shallow query can still request huge lists.

Federation lets several teams own separate GraphQL subgraphs and compose them into one graph for clients. Each subgraph declares the entities it owns with a key directive, and a gateway or router plans and stitches queries across them.

type User @key(fields: "id") {
  id: ID!
  name: String!
}

When a query asks for User.name and User.orders, the router fetches the entity from the users subgraph and the orders subgraph and merges the results. Apollo Federation is the best-known implementation; schema stitching is an older, more manual alternative.

You need federation when a single monolithic schema becomes a bottleneck for multiple teams, or when services are owned independently. Costs include router complexity, extra network hops, careful entity key design and harder debugging. For a single team and a small schema, a modular monolith schema is simpler and faster.