Bird
Raised Fist0
GraphQLquery~5 mins

Persisted queries in GraphQL

Choose your learning style10 modes available

Start learning this pattern below

Jump into concepts and practice - no test required

or
Recommended
Test this pattern10 questions across easy, medium, and hard to know if this pattern is strong
Introduction

Persisted queries help make GraphQL requests faster and safer by storing queries on the server. This way, clients only send a small ID instead of the full query text.

When you want to reduce the amount of data sent over the network for repeated queries.
When you want to improve security by allowing only predefined queries to run.
When you want to speed up query execution by caching query plans on the server.
When building mobile apps with limited bandwidth to save data usage.
When you want to simplify client code by referencing queries by ID.
Syntax
GraphQL
1. Store your GraphQL query on the server and assign it a unique ID.
2. Client sends a request with the query ID instead of the full query.
3. Server looks up the query by ID and executes it.

The exact method to store and retrieve persisted queries depends on your GraphQL server setup.

Clients must know the query IDs beforehand to use persisted queries.

Examples
This is the original GraphQL query saved on the server with a unique ID.
GraphQL
# Example of a stored query on the server:
query GetUser {
  user(id: "123") {
    name
    email
  }
}

# This query is saved with ID: "getUser123"
The client sends just the ID instead of the full query text.
GraphQL
# Client sends only the ID:
{
  "id": "getUser123"
}
The server uses the ID to find and execute the stored query.
GraphQL
# Server receives the ID, finds the query, and runs it.
# Server returns the user data as usual.
Sample Program

This example shows how a client sends a query ID, the server looks up the full query, runs it, and returns the data.

GraphQL
# Simulated example using a JSON request for a persisted query
# Client request:
{
  "id": "getUser123"
}

# Server stored queries:
{
  "getUser123": "query GetUser { user(id: \"123\") { name email } }"
}

# Server executes the stored query and returns:
{
  "data": {
    "user": {
      "name": "Alice",
      "email": "alice@example.com"
    }
  }
}
OutputSuccess
Important Notes

Persisted queries reduce bandwidth by sending only IDs instead of full queries.

They improve security by limiting which queries can run on the server.

Make sure to handle errors when an unknown query ID is sent.

Summary

Persisted queries store GraphQL queries on the server with unique IDs.

Clients send only the ID to run a query, saving data and improving speed.

This technique also helps secure your API by controlling allowed queries.

Practice

(1/5)
1. What is the main benefit of using persisted queries in GraphQL?
easy
A. The server stores user credentials for faster login.
B. Clients send only a unique ID instead of the full query, saving bandwidth.
C. Queries are automatically optimized by the client.
D. It allows clients to write queries without validation.

Solution

  1. Step 1: Understand what persisted queries do

    Persisted queries store the full GraphQL query on the server with a unique ID.
  2. Step 2: Identify the client-server interaction

    Clients send only the ID to run the query, reducing the data sent over the network.
  3. Final Answer:

    Clients send only a unique ID instead of the full query, saving bandwidth. -> Option B
  4. Quick Check:

    Persisted queries reduce data sent = Clients send only a unique ID instead of the full query, saving bandwidth. [OK]
Hint: Persisted queries send IDs, not full queries [OK]
Common Mistakes:
  • Thinking clients send full queries every time
  • Confusing persisted queries with client-side caching
  • Believing persisted queries store user data
2. Which of the following is the correct way to send a persisted query request in GraphQL?
easy
A. { "id": "12345", "variables": { "userId": "1" } }
B. { "query": "{ user(id: 1) { name } }" }
C. { "mutation": "updateUser" }
D. { "headers": { "Authorization": "token" } }

Solution

  1. Step 1: Identify the persisted query request format

    Persisted queries send the unique query ID and variables, not the full query string.
  2. Step 2: Match the correct JSON structure

    { "id": "12345", "variables": { "userId": "1" } } sends an ID and variables, which is the correct persisted query format.
  3. Final Answer:

    { "id": "12345", "variables": { "userId": "1" } } -> Option A
  4. Quick Check:

    Persisted query request = ID + variables [OK]
Hint: Persisted queries use ID field, not full query [OK]
Common Mistakes:
  • Sending full query instead of ID
  • Using mutation key instead of id
  • Confusing headers with query payload
3. Given the following persisted query setup, what will the server return when the client sends { "id": "abc123", "variables": { "limit": 5 } } if the query with ID abc123 fetches the first limit users?

Assume the database has 10 users named User1 to User10.

Options:
medium
A. []
B. [{"name": "User6"}, {"name": "User7"}, {"name": "User8"}, {"name": "User9"}, {"name": "User10"}]
C. [{"name": "User1"}, {"name": "User2"}, {"name": "User3"}, {"name": "User4"}, {"name": "User5"}]
D. Error: Query ID not found

Solution

  1. Step 1: Understand the query and variables

    The query with ID 'abc123' fetches users limited by the 'limit' variable, which is 5 here.
  2. Step 2: Determine the expected result

    Since the database has users User1 to User10, fetching the first 5 returns User1 to User5.
  3. Final Answer:

    [{"name": "User1"}, {"name": "User2"}, {"name": "User3"}, {"name": "User4"}, {"name": "User5"}] -> Option C
  4. Quick Check:

    Limit 5 users returns first 5 users [OK]
Hint: Variables control query output; check their values [OK]
Common Mistakes:
  • Assuming query returns last users
  • Thinking ID is invalid
  • Ignoring variables in query
4. A developer tries to use persisted queries but gets an error: Query ID not found. What is the most likely cause?
medium
A. The client sent a query ID that the server does not recognize.
B. The client sent the full query instead of the ID.
C. The server does not support GraphQL.
D. The client forgot to include variables.

Solution

  1. Step 1: Analyze the error message

    The error 'Query ID not found' means the server cannot find the query matching the sent ID.
  2. Step 2: Identify the cause

    This usually happens if the client sends an ID that was never registered or stored on the server.
  3. Final Answer:

    The client sent a query ID that the server does not recognize. -> Option A
  4. Quick Check:

    Unknown query ID causes 'Query ID not found' error [OK]
Hint: Check if query ID is registered on server [OK]
Common Mistakes:
  • Assuming full query sent causes this error
  • Blaming missing variables for this error
  • Thinking server lacks GraphQL support
5. You want to secure your GraphQL API by allowing only persisted queries. Which approach best achieves this?
hard
A. Disable persisted queries and use API keys instead.
B. Allow all queries but log those without IDs for review.
C. Require clients to send full queries and IDs together.
D. Reject any request that does not include a valid persisted query ID.

Solution

  1. Step 1: Understand API security with persisted queries

    Allowing only persisted queries means the server accepts requests only if they have a valid stored query ID.
  2. Step 2: Identify the best enforcement method

    Rejecting requests without valid IDs ensures only approved queries run, improving security.
  3. Final Answer:

    Reject any request that does not include a valid persisted query ID. -> Option D
  4. Quick Check:

    Only accept valid persisted query IDs to secure API [OK]
Hint: Block requests missing valid persisted query IDs [OK]
Common Mistakes:
  • Allowing all queries weakens security
  • Sending full queries defeats persisted query purpose
  • Relying only on API keys without query control