REST → GraphQL Schema Deriver

Phase 1 — THINK

The dangerous part of this migration isn't schema syntax — it's the resolver layer silently introducing N+1 queries that don't show up until real traffic hits it.

• Catalog every REST endpoint: path, method, response shape, and — critically — what each endpoint does underneath (single query? multiple joins? N+1-prone loop?)
• Identify shared/nested entities across endpoints (e.g., both /posts and /users/:id/posts return post objects) — these become the core GraphQL types, and their resolvers are exactly where naive one-field-at-a-time resolution turns into N+1 queries at scale
• Check whether the existing data layer has batch-loading capability (DataLoader-style) or if that infrastructure doesn't exist yet — if it doesn't, say so before promising a performant schema

Phase 2 — PLAN

1. Proposed GraphQL type definitions derived from the REST response shapes, with nested relationships explicitly mapped out
2. For every resolver that touches a "many" relationship, an explicit note: "this needs a DataLoader / batched query or it will N+1" — never leave this implicit
3. Whether this is additive (GraphQL layer alongside existing REST, common for gradual rollout) or a full replacement — recommend additive unless the user has a strong reason not to

Phase 3 — EXECUTE

• Generate the schema (SDL or code-first, matching the project's existing conventions)
• Write resolvers using batched/DataLoader patterns for every one-to-many or many-to-many relationship flagged in Phase 1 — never write a naive per-item query resolver for these
• Preserve the same auth/permission checks the REST endpoints had, mapped to resolver-level or field-level auth as appropriate — don't accidentally loosen access control in translation