GraphQL Query Builder
Build GraphQL queries, mutations, and subscriptions visually. Add fields, arguments, variables, nested types, and fragments.
Operation
Variables
Root Selection
Fragments
How to Use the GraphQL Query Builder
- Choose an operation type — Query (read), Mutation (write), or Subscription (real-time).
- Name your operation — give it a descriptive name like
getUserorcreatePost. Named operations are required for persisted queries and easier debugging. - Define variables — declare
$variableName: Type!pairs to parameterise the operation. - Add fields — type field names; use the nested option to add sub-selection sets for object types.
- Add arguments — attach argument name/value pairs to any field, referencing your variables with
$varName. - Copy the output — paste into Apollo Client, urql, Postman, GraphiQL, or any GraphQL endpoint.
GraphQL vs REST
REST APIs use multiple endpoints, each returning a fixed data shape. To build a profile page you might need three requests: GET /user/123, GET /user/123/posts, and GET /user/123/followers. With GraphQL you write a single query that requests exactly the fields you need across all related types. The server returns everything in one round trip. This is especially impactful on mobile networks where latency is high. However, REST has advantages too — HTTP caching is easier, the mental model is simpler, and REST APIs are ubiquitous. GraphQL shines in data-dense applications with complex, interconnected data models (social networks, e-commerce, dashboards).
Understanding the Type System
GraphQL has a strong type system. Every field has a type: scalars (String, Int, Float, Boolean, ID), object types, enums, interfaces, and unions. Types can be nullable (optional) or non-null (marked with !). Arrays use bracket notation: [User] is a nullable list of nullable users, [User!]! is a required list of required users. Understanding types is critical when defining variables — a type mismatch causes the server to reject the operation before execution.
Variables and Security
Always use variables instead of inline literal values for user-supplied inputs. Hardcoding a user ID like user(id: "abc123") is fine for exploration, but in production code the value should come from a variable: user(id: $userId). Variables are passed as a separate JSON object outside the query string. This prevents injection attacks, enables automatic query caching on the client, and makes operations reusable across calls with different inputs. Declare variables with their types in the operation signature: query GetUser($userId: ID!, $includeEmail: Boolean = false).
Fragments and Code Reuse
Fragments solve the DRY problem in GraphQL. When the same set of fields appears in multiple queries — a user card component, a user list row, and a user profile page all need id, name, avatarUrl — define it once as a fragment and spread it everywhere. Fragments also improve colocation: with Apollo Client and Relay, each UI component defines its own fragment, and parent queries compose those fragments automatically. This means component data requirements are encapsulated with the component itself, not scattered across the codebase. See our API Mock Generator to create fake data for testing your queries.