A dream query is a GraphQL operation you write before the schema supports it. It describes what a UI or client needs — not what the graph can do today. Hub uses dream queries as the starting point for schema design. You write the query first, then change the schema to match.Documentation Index
Fetch the complete documentation index at: https://hub-docs.wundergraph.com/llms.txt
Use this file to discover all available pages before exploring further.
The idea comes from Mark Larah’s work at Yelp, where teams wrote the queries they wished they could run and shaped the schema around them.
How it drives schema design
- A feature or screen defines what data must appear.
- You write the query, including fields that don’t exist yet.
- You compare it to the current graph. The gaps show what to add.
- You create and assign those fields.
- Fission generates the subgraph schemas.
When to use one
Write a dream query when:- A new feature needs data the graph doesn’t have.
- A redesign changes the shape of the data.
- A new consumer needs a different query shape.
- Teams need a shared definition of an API requirement.
Why start here
Most federated graphs grow from services up. Teams model subgraphs around their own data, then compose a supergraph. The API shape follows service structure — not product needs. Dream queries flip this. Define the consumer need first. Shape the schema to meet it. Teams discover gaps early and align on the requirement before anyone writes a resolver.What a dream query does not do
- It doesn’t define how resolvers work.
- It doesn’t replace domain modeling.
- It doesn’t validate against live traffic.
- It doesn’t create schema changes on its own.