GraphQL & API Gateway Language Exercises — English for Developers

The Schema Definition Language (SDL) is the human-readable syntax used to define a GraphQL schema. Key SDL vocabulary includes: type (an object definition), field (a property on a type), scalar (a primitive value like String, Int, Boolean, ID), non-null modifier (the exclamation mark ! meaning a field cannot return null), interface (an abstract type multiple concrete types can implement), union (a type that can be one of several concrete types), and enum (a fixed set of allowed values). The SDL is the contract between a GraphQL API and its consumers.

A resolver is a function that returns the data for a specific field in a GraphQL schema. Every field in a GraphQL query is ultimately fulfilled by a resolver. You might explain it as: "A resolver is the server-side function that knows how to fetch the data for a given field — it might query a database, call another API, or compute a value. GraphQL calls each resolver in the query tree to assemble the final response." Resolver performance and the N+1 problem (a resolver making one database call per item in a list) are central topics in GraphQL optimization.

The N+1 problem occurs when a GraphQL query for a list of N items triggers N additional database queries — one per item — instead of a single batched query. For example, fetching 100 posts and then resolving the author field for each post with a separate query results in 101 total queries. The standard solution is DataLoader (originally from Facebook), which batches and caches these calls. In a code review you might say: "This resolver will cause an N+1 — we should use DataLoader here to batch the user lookups."

GraphQL federation is an architecture for composing multiple GraphQL APIs (called subgraphs) into a single unified API (called the supergraph). Key federation vocabulary: subgraph (an individual GraphQL service that owns part of the schema), supergraph (the composed unified graph), router/gateway (the component that receives client queries and routes them to the correct subgraphs), @key directive (marks the field(s) that uniquely identify an entity across subgraphs), and entity (a type that can be referenced and extended across subgraphs). Apollo Federation and GraphQL Mesh are the most common federation implementations.

These are the three GraphQL operation types. A query is a read-only data fetch — it retrieves data without side effects. A mutation is a write operation that modifies server-side data (creating, updating, or deleting records) and returns the result. A subscription is a long-lived operation that establishes a real-time connection (typically over WebSocket) and pushes data to the client when specified events occur. In code reviews you might hear: "This should be a mutation, not a query — it's modifying state."

The Backend for Frontend (BFF) pattern creates a dedicated API layer for each client type (web, mobile, third-party). Rather than all clients sharing a single general-purpose API, each BFF aggregates and transforms data optimised for its specific client's needs. In an API gateway context, you might implement BFFs as separate routing configurations or separate gateway instances. You would say: "We have a BFF for the mobile app that aggregates the user profile and notification data in a single call, reducing the number of round trips on mobile networks."

Schema governance is the set of processes and tooling that control how a GraphQL schema evolves across teams. It includes: breaking change detection (preventing changes that would break existing clients), schema review processes (requiring approval before schema changes are deployed), deprecation workflows (marking fields as deprecated before removing them), schema changelogs, and cost analysis (estimating the query complexity before execution to prevent expensive queries). Large organisations use tools like Apollo Studio or Hive for schema governance.

Rate limiting is a control that restricts how many requests a client can make in a given time window, protecting backend services from overload. In API gateway discussions: "We have a rate limit of 1,000 requests per minute per API key. If you exceed that, you'll receive a 429 Too Many Requests response with a Retry-After header indicating when you can retry." Rate limiting vocabulary also includes: throttling (gradually slowing requests rather than hard-blocking), burst capacity (allowing short-term spikes above the sustained rate), and quota (a total request allowance over a longer period like a day or month).

GraphQL introspection is the built-in mechanism that allows clients to query the schema itself — discovering all available types, fields, and operations. It is what powers GraphQL IDEs like GraphiQL and Apollo Sandbox. In production, many organisations disable introspection to prevent exposing their schema to potential attackers: "We've disabled introspection on the production endpoint. Use the Apollo Studio schema explorer with your API key instead." The trade-off is that disabling introspection breaks standard tooling for legitimate developers.

A persisted query stores a pre-approved GraphQL query on the server, identified by a hash, so clients send only the hash rather than the full query string. This reduces request payload size, improves performance (the server can cache the parsed query), and enhances security (only pre-registered queries are allowed, preventing arbitrary queries from untrusted clients). You might say in a design review: "We're implementing persisted queries to lock down our public API — no ad hoc queries will be accepted from the mobile client in production."