How does a GraphQL server give behaviour to a custom directive applied in its schema?

### The server has to go looking Because GraphQL defines no execution semantics for a custom directive, giving one behaviour means writing code that (a) finds the applications and (b) changes what happens at those locations. There are two well-established shapes, and a mature codebase often uses both. ### Strategy A — transform the schema once, at build time After the executable schema is assembled, walk it: every field definition, argument definition, enum value, type. At each location, ask whether the directive you care about is applied there and read its argument values. When it is, replace what you found — most often by swapping the field's resolver for a wrapper that calls the original and adds the behaviour around it. The appeal is that the cost is paid once. At request time there is no directive lookup at all; there is simply a resolver that happens to convert kilograms, or trim a string, or record a metric. It also keeps the concern out of every resolver: the resolver an engineer writes for `Animal.birthWeight` knows nothing about units. The catches are real. The wrapping exists only in the schema object that pass produced — if anything later rebuilds the schema, or prints it to SDL and re-parses it, the *text* of the applied directive survives and the wrapper does not. Merging additional SDL after the pass has run produces fields that carry the annotation and none of the behaviour. And when several directives apply to one field, wrapping order becomes visible behaviour that you, not the specification, have to define and document. ### Strategy B — read the applied directive at execution time Alternatively, leave the schema alone and have the code that runs a field consult the field's own schema definition: is the directive applied here, and with what arguments? Branch accordingly. This usually lives in a generic hook or middleware that wraps every field's execution, rather than being copy-pasted into individual resolvers. This is the right shape when the decision genuinely depends on request state — the same annotation producing different behaviour per caller, per locale, per feature flag — because nothing was frozen at build time. It also survives schema rebuilds, since there is nothing baked in to lose. The cost is a lookup on every annotated field on every request, which is worth memoizing by field definition, and a diffuse concern: whatever runs the field must remember to check, so a resolution path that bypasses the hook silently bypasses the directive. ### Directives that are not on a field definition Wrapping a resolver only reaches directives applied at output-field locations. An annotation on an argument definition or an input field has to be honoured *before* the resolver runs, by transforming or validating the incoming argument values in the wrapper. An annotation on an object type or on the schema does not cascade to fields on its own — the specification defines no inheritance. If you want `@unit` on the `Animal` type to apply to every weight field beneath it, you write that expansion yourself during the walk, and you decide and document what happens when both the type and the field carry the directive. ### Directives consumed before runtime Not every directive should reach the server at all. Some are read by a schema linter to enforce a naming or ownership convention. Some are read by a typed client generator so an annotated field produces a different generated type. Some are read by a composition step and stripped from the schema it publishes. These are legitimate uses, and being explicit about which consumer reads a given directive is most of what keeps a directive-heavy schema comprehensible. ### Choosing, and being honest about the cost For a small team the deciding question is usually: does the behaviour depend only on the schema, or also on the request? Schema-only behaviour — unit conversion, formatting, a static cost weight, a cache hint — is a natural build-time transform. Request-dependent behaviour belongs at execution time. The tradeoff to name in an interview is comprehensibility. A directive moves behaviour out of the resolver an engineer is reading and into a pass they may not know exists. That is a genuine win for consistency across hundreds of fields and a genuine loss for local readability — which is why directive machinery earns its place when many fields need the same treatment, and rarely when three do.