Skip to main content
Back to Dev generators

Dev

Fake GraphQL Query Generator

Used by developers, writers, and creators worldwide.

A fake GraphQL query generator removes the tedious work of hand-authoring syntactically correct operations when you need them for testing, mocking, or documentation. Type any resource name — "User", "Order", "Product" — choose query, mutation, subscription, or all three, and set how many fields to include per type. The output follows real GraphQL conventions: list queries use Relay-style cursor pagination with a pageInfo block, mutations receive typed input variables, and subscriptions use proper WebSocket syntax. Field names come from a realistic pool, so the result looks like developer-authored code. Paste it directly into Apollo Client, MSW handlers, or a .graphql fixture file.

Loading usage…

Free forever — no account required

How to use

  1. Choose your options above
  2. Click Generate
  3. Copy your result

Detailed instructions

  1. Type your GraphQL type name into the Resource field using PascalCase, such as "Product" or "OrderItem".
  2. Select an operation type from the dropdown: choose "all" for the full CRUD set, or pick a specific type like "mutation" to generate only those operations.
  3. Set the Fields per Type number to control selection set size — use 3–5 for lean test fixtures or 7–10 for documentation examples.
  4. Click Generate and review the output panel, which contains one complete GraphQL operation block per selected type.
  5. Copy the output and paste it into your .graphql file, test fixture, MSW handler, or GraphQL Playground tab.

Use Cases

  • •Generating MSW graphql.query() and graphql.mutation() handlers with realistic operation names like GetUser or UpdateOrder
  • •Scaffolding Jest or Vitest snapshot fixtures before a backend GraphQL schema is finalized
  • •Populating Insomnia or Postman GraphQL collections with sample operations for a new API resource
  • •Creating concrete query and mutation examples for API reference docs without needing a live schema
  • •Prototyping Apollo Client useQuery hooks in Storybook stories while the backend is still in development

Tips

  • →Set resource to match your exact type name — the generator uses it as the operation name prefix, so "BlogPost" produces GetBlogPost and CreateBlogPost, keeping output paste-ready.
  • →Use fieldCount of 3–4 when generating fixtures for unit tests; bloated selection sets make snapshot diffs noisy and harder to maintain.
  • →Generate the "all" operation type first to get the full picture, then re-run with a specific type selected to get a cleaner block for documentation or a single test file.
  • →The list query's pageInfo and edges structure is Relay-compatible — if you're using Apollo Client with a Relay-style cache policy, the pagination logic maps directly without modification.
  • →Combine multiple runs with different resource names to build a complete mock API layer: generate User, Post, and Comment operations separately, then assemble them into a single MSW handler file.
  • →If your schema uses snake_case field names rather than camelCase, do a quick find-and-replace on the output before committing — the generator always produces camelCase to match GraphQL convention.

FAQ

can I run generated graphql queries against my real api

Not directly — field names come from a generic pool and won't match your schema exactly. Treat the output as a structural template: the syntax, variable declarations, operation names, and pagination patterns are all valid GraphQL, but you'll need to swap in the field names your schema actually defines.

what's the difference between a graphql query mutation and subscription

Queries fetch data without side effects; mutations create, update, or delete records and return the affected object so clients can update their cache. Subscriptions open a persistent WebSocket connection and push updates when specified data changes — useful for chat or live dashboards, but unnecessary for standard data-fetching.

how does the field count setting affect the generated graphql output

fieldCount controls how many fields appear in each operation's selection set. Setting it to 3–4 produces minimal queries ideal for unit tests; 8–10 generates richer examples better suited for documentation or schema exploration demos. List and single-fetch queries sample independently from the field pool, so their fields won't always overlap.