Skip to main content
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.
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

  1. A feature or screen defines what data must appear.
  2. You write the query, including fields that don’t exist yet.
  3. You compare it to the current graph. The gaps show what to add.
  4. You create and assign those fields.
  5. Fission generates the subgraph schemas.
The dream query itself doesn’t ship. The fields and types it creates do.

​
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.
Each dream query covers one use case. A full schema needs many.
See Design a Query from a Mockup for the step-by-step workflow in Hub.

​
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.
Validation and review happen later through proposals and schema checks.