Write a REST to GraphQL Migration Prompt That Maps Endpoints to Schema

A REST endpoint returns a fixed shape. A GraphQL field resolves on demand, and that difference is exactly where a naive migration goes wrong. Convert /users/:id/posts into a posts field without thinking, and you've built an N+1 query that fires once per user in every list. A REST to GraphQL migration prompt drafts the schema, sure, but its real job is flagging the resolver traps that turn a clean API into a slow one.

The guides that rank for this are tool walkthroughs. StepZen, Apollo, Shopify's assistant. Each is tied to one platform and shows the schema generation, not the data-loading strategy or the plan for keeping REST clients alive during the move. That's the gap a reusable, model-agnostic prompt fills.

Why schema generation is the easy part

Turning REST resources into GraphQL types is mostly mechanical. A User resource becomes a User type; its fields map across. Any decent model does this in one pass. The trouble starts at the edges between types, where REST made you fetch separately and GraphQL invites you to nest.

The take worth holding: the schema is 70% of the output and 10% of the risk. The risk lives in the resolvers. A resolver that loads a user's posts by calling the database once per user is correct and catastrophic at the same time. A migration prompt that emits resolvers without flagging the batching strategy is handing you a performance incident wrapped in clean-looking code.

What a REST to GraphQL migration prompt does

A REST to GraphQL migration prompt is an endpoint-to-schema mapper that reads your REST specs, drafts a GraphQL type schema and resolver map, flags N+1 risks, and locks a backward-compatible coexistence plan. It plans the data-loading before it emits a resolver.

Run it to:

• Map each REST resource to a GraphQL type with typed fields
• Draft resolvers and flag every one that risks an N+1 query
• Mark fields that need a DataLoader or batched fetch
• Propose a REST-and-GraphQL coexistence plan for live clients
• Flag REST endpoints that don't map cleanly (file uploads, RPC-style)
• Lock an output contract so each resolver names its data source

The N+1 flag and the coexistence plan are the two things the tool-specific guides leave out.

Anatomy of the prompt

Variables
  {{rest_endpoints}}     → endpoint specs (paths, params, responses)
  {{data_sources}}       → DB tables / services behind the endpoints
  {{existing_clients}}   → who still calls REST (for coexistence)

Prompt
  Role: you are a REST-to-GraphQL migration architect.
  Task: map {{rest_endpoints}} to a GraphQL schema + resolvers.
  Rules:
    - Flag every resolver that risks an N+1 query.
    - Mark fields needing a DataLoader or batch fetch.
    - Output a coexistence plan that keeps {{existing_clients}} working.

Output contract
  Return: schema + resolver map + N+1 flags + coexistence plan.

1. Feed real endpoint specs

The schema is only as good as the input. Paste paths, params, and response shapes into {{rest_endpoints}} so the model maps actual fields, not assumed ones.

2. Name the data sources

A resolver's N+1 risk depends on what it queries. List the tables or services in {{data_sources}} so the model can spot the per-item loop and flag it.

3. Read the coexistence plan

GraphQL rarely replaces REST overnight. The plan says how both run together, which existing clients keep hitting REST while new ones move over. Read it before touching the schema.

Prompt-craft patterns for API migration

Flag N+1 by contract, not by hope. Don't trust the model to write efficient resolvers. Make the output contract mark every resolver that fires per-item and name the batching fix. A flagged risk is one you can address before it ships.

Plan coexistence, never cutover. A prompt that assumes REST disappears the day GraphQL launches is wrong about how migrations actually happen. Force a plan where both run in parallel and clients move on their own schedule.

Quarantine the non-mappable. File uploads, streaming, RPC-style endpoints. These don't have clean GraphQL equivalents. The contract should flag them for a deliberate decision rather than letting the model invent an awkward field.

Where Claude and ChatGPT diverge on resolvers

The two models differ in how cautiously they write resolvers. Claude tends to flag N+1 risk and suggest a DataLoader when the rule is present, and it comments the data source per resolver. GPT-4o drafts a complete schema faster but writes resolvers that call the data source directly in a loop unless the N+1 rule sits on the final line of the prompt.

Both models default to a clean-slate schema that ignores existing clients, so the coexistence requirement has to be explicit or you'll get a design that assumes a cutover. There's also a subtle trap with nullability: GraphQL non-null fields fail the whole query if the resolver returns null, which a REST endpoint would have tolerated as a missing key. Restate the N+1 and coexistence rules for GPT-4o on the last line; pin the model version, because a converter that started writing looser resolvers after an update is a regression you'll meet as a latency spike.

How this fits the broader API work

A REST-to-GraphQL move is one kind of API migration. The contract-testing discipline that keeps consumers working applies whether you're versioning an API or changing its shape entirely. For detecting what breaks consumers, the detect breaking api changes prompt diffs two API surfaces; for the staged-rollout structure behind any large migration, the framework migration prompt covers reversible steps.

Variables you'll set

Getting started

1. Copy the structure into ChatGPT, Claude, or Gemini.
2. Paste your endpoint specs into {{rest_endpoints}}.
3. List the backing tables or services in {{data_sources}}.
4. Run it and read the N+1 flags before adopting any resolver.
5. Address every flagged resolver with a DataLoader or batch fetch.
6. Follow the coexistence plan so REST clients keep working.

For an API migration where contract tests guard every consumer as the shape changes, the API Contract Test Harness Pack generates the tests that catch a break before clients do.

A schema change is also a breaking change for some consumers, so you'll want to communicate it precisely. The Breaking Change Detection Harness Agent Pack diffs the surfaces and recommends the version bump. New to buying packs versus rolling your own? Start with how to choose a reusable AI prompt pack.