Querying Static Data: Returning Objects from GraphQL Resolvers

Previously in this course, we covered creating basic resolvers to establish the link between your schema and the server execution logic. In this lesson, we take that bridge and start crossing it with actual data.

Up until now, your resolvers have likely returned empty objects or null. While this satisfies the server, it doesn't give your clients anything to work with. Today, we’ll move from "placeholder" code to returning functional, hardcoded static data that matches the custom object types you’ve already defined.

From Placeholder to Provider

In GraphQL, a resolver is simply a function that is responsible for populating the data for a specific field in your schema. If your schema expects a User type, the resolver for the query that fetches that user must return an object that contains the fields defined for that User.

When we talk about static data in the context of a GraphQL server, we mean hardcoded JavaScript objects—often stored in a constant or a separate data file—that act as a temporary "database" while we build out the architecture.

The Anatomy of a Static Data Return

Let's look at a concrete example. Suppose you have a schema that defines a Book type and a query to fetch a single book:

GraphQL
type Book {
  id: ID!
  title: String!
  author: String!
}

type Query {
  getBook: Book
}

To return this data, your resolver for getBook needs to return a JavaScript object that mirrors the keys of the Book type exactly.

JAVASCRIPT
const books = [
  { id: CE9178">'1', title: CE9178">'The Great Gatsby', author: CE9178">'F. Scott Fitzgerald' },
  { id: CE9178">'2', title: CE9178">'1984', author: CE9178">'George Orwell' }
];

const resolvers = {
  Query: {
    // This resolver returns a hardcoded object
    getBook: () => {
      return books[0]; // Returns the first book from our static list
    },
  },
};

Why Return Objects?

Returning an object is the foundational mechanism of GraphQL's execution model. When a client sends a query, the GraphQL engine traverses the fields requested. If you ask for title, the engine looks at the object returned by the parent resolver and checks for a key named title.

If your resolver returns null or an object missing the required keys, the GraphQL engine will be unable to fulfill the request for those fields. By returning a complete object, you satisfy the contract defined in your non-null fields.

Hands-on Exercise: Populating Your Project

In your current project, identify the root query resolver you created in previous lessons.

1. Define a constant variable outside of your resolvers object containing an array or a single object representing your primary domain model (e.g., a Product, Project, or User).
2. Update your resolver function to return that object.
3. Restart your server and use Apollo Sandbox to execute a query requesting specific fields from that object.

Goal: Ensure the result in your Sandbox matches the object you defined in your code.

Common Pitfalls

Even with static data, there are a few common ways developers run into trouble:

• Case Sensitivity Mismatches: If your schema defines a field as title (lowercase), but your object uses Title (uppercase), the resolver will return null for that field because the keys don't match. GraphQL is strictly case-sensitive.
• Returning the Wrong Shape: If your schema expects a Book type, but your resolver returns an array [] instead of an object {}, the server will throw an execution error. Always ensure the return type of the function matches the type defined in the SDL.
• Forgetting to Export: In a multi-file setup, ensure your data constant is either in the same file or properly exported/imported into the resolver file.

FAQ

Q: Can I return more data than the schema asks for? Yes. GraphQL will simply ignore any keys in your returned object that aren't requested in the client's query. This is a core feature—over-fetching is avoided by the client, even if the server provides a "fat" object.

Q: Does the order of fields in my object matter? No. JavaScript objects are unordered, and the GraphQL execution engine looks up fields by key, not by index.

Q: Should I put all my static data in the resolvers.js file? While you can, it's better practice to keep your data in a separate file (e.g., data.js) to keep your resolver logic clean as the project grows.

Recap

In this lesson, we moved from empty resolvers to functional ones by returning concrete JavaScript objects. You now know that:

• Resolvers must return data that matches the fields in your schema.
• Field names in your return object must match the schema keys exactly (case-sensitive).
• Returning an object allows the GraphQL engine to resolve specific child fields requested by the client.

Up next, we will refine this process by learning how to map specific schema fields to object properties, especially when your internal data structure doesn't perfectly mirror your API contract.