Mock GraphQL Response Generator
When you are building a frontend against a GraphQL API that does not exist yet, you need response data that matches the real shape: the data envelope, nested objects, lists, and pagination metadata. This tool generates that JSON for you so you can wire up components, loading states, and pagination controls before the backend is ready.
How it works
Every GraphQL response is a JSON object with a top-level data key whose properties mirror the query selection set. The generator builds data[rootField] according to your configuration. For a plain list it emits an array of objects with an id, a name-like string, and a few typed fields. For a Relay-style connection it wraps the items in an edges array, where each entry has a node and a cursor, alongside a pageInfo object.
Cursors follow the common Relay convention: the string cursor:N for item index N, base64-encoded so it reads as an opaque token. The pageInfo.endCursor is the last item’s cursor and hasNextPage is set when the requested count fills the page, mirroring how a real resolver paginates.
Tips and notes
- Use the connection option when your UI uses infinite scroll or cursor pagination; use the plain list otherwise.
- The output is spec-valid JSON, so it drops straight into Apollo
MockedProvider, MSW handlers, or fixture files. - Decode a cursor in your console with
atob("...")to confirm it readscursor:N. - Increase the item count to stress-test rendering and virtualization in long lists.
Plain list vs. Relay connection — when to use each
The two output shapes serve different UI patterns:
Plain array — use this when your query returns a fixed list that your component maps directly to rendered items. For example, a tags query that returns all tags for a post, or a topProducts list on a landing page where there is no pagination at all.
Relay connection — use this when your component uses cursor-based pagination. The Relay specification defines a standard shape used by many GraphQL servers (not only those built with the Relay framework) because it cleanly supports forward-only pagination, bidirectional pagination, and refetching from any point in the list. The key fields are:
{
"data": {
"users": {
"edges": [
{ "cursor": "Y3Vyc29yOjA=", "node": { "id": "1", "name": "Alice" } },
{ "cursor": "Y3Vyc29yOjE=", "node": { "id": "2", "name": "Bob" } }
],
"pageInfo": {
"hasNextPage": true,
"endCursor": "Y3Vyc29yOjE="
}
}
}
}
The endCursor from pageInfo is passed as the after argument in the next query to fetch the following page.
How to use the output in common frameworks
Apollo Client MockedProvider — wrap the generated JSON in a mocks array entry:
const mocks = [{
request: { query: USERS_QUERY },
result: { data: generatedJson.data }
}];
Mock Service Worker (MSW) — return the generated object from a graphql.query handler:
graphql.query('GetUsers', (req, res, ctx) =>
res(ctx.data(generatedJson.data))
);
Fixture files — save the generated JSON as a .json file and import it directly in Jest tests using jest.mock or inline fixture imports. Because the structure matches the real API shape, your component tests exercise the same data path as production.