Schema-first uses typePaths to point at .graphql SDL files and a definitions config to generate TypeScript interfaces from them. Resolvers reference the generated types. Choose schema-first when the SDL is the team's API contract or when frontend developers write the schema and backend implements against it.
Choose schema-first when the SDL is the team's shared API contract (API-design-first workflow).
Choose schema-first when frontend developers write the schema and backend implements against it.
Choose code-first when TypeScript is the single source of truth and you want full IDE support.
Schema-first risk: interface drift — SDL and generated TypeScript can diverge if code generation is skipped.
Code generation must be re-run whenever the SDL changes — automate this in CI.
You need to add a new GraphQL query to a NestJS service using the schema‑first approach. Walk me through the files you would create or modify and how NestJS wires them together.
If you forget to import the generated GraphQL types module after switching to schema‑first, what runtime error would you see and why?
We have an existing NestJS code‑first GraphQL API, and the product wants to expose a third‑party SDL file. How would you migrate the relevant parts to schema‑first, and what pitfalls might cause mismatched resolvers?
During a sprint a teammate added a new field to the SDL but the corresponding resolver never fired. How would you debug that issue in a schema‑first setup?
At scale we have dozens of microservices each exposing GraphQL schemas. Discuss the trade‑offs of using schema‑first across services versus code‑first, focusing on build pipelines, type safety, and runtime performance.
Suppose you need to generate TypeScript types from a large SDL for validation in a NestJS gateway. What design would you choose to keep the generated types in sync without slowing CI, and why might schema‑first be advantageous here?
Our organization is consolidating multiple legacy GraphQL services, some built with schema‑first, others with code‑first. Propose a migration strategy that minimizes downtime and maintains contract stability, and argue when you would keep schema‑first for new services.
If we plan to expose the GraphQL API to external partners and want to version the contract, how does choosing schema‑first affect our versioning, documentation, and cross‑team governance compared to code‑first?