7. Follow-along: Using `@defer`
1m

The slowest field sets the pace

When exploring in Sandbox earlier, we ran a few different s—and one of them took a lot longer than the other to resolve! Let's return to this operation now, specifically to one of its s: recentlyAddedRecipes.

query GetRecentlyAddedRecipes {
recentlyAddedRecipes {
prepTime
name
cookingTime
servings
}
}

We'll find that any s containing this inevitably take a lot longer to resolve than they should. This field is backing everything up!

Follow-along: Using @defer

We've isolated our problem—fortunately, there's a way to break apart the really slow s from everything else. This mechanism is called @defer.

The has this built-in capability to handle s in a query that resolve more slowly than the rest. Using the @defer , we can specify which s to defer—meaning that our query doesn't have to wait on the slowest pieces before it can return some data.

🎯 Goal: Improve an 's response time by using @defer.

To be deferred, a needs to meet one of the following requirements:

  • It's a root of the Query type
  • It's a of any entity type
  1. Try running the below in .

    query GetRecipePage {
    recipe(id: "recOZrH0RhjSjATBp") {
    id
    name
    cookingTime
    prepTime
    readyTime
    servings
    instructions
    ingredients {
    text
    }
    }
    recentlyAddedRecipes {
    name
    cookingTime
    servings
    }
    }

    It takes a few seconds for the data to come back.

  2. Place your cursor on recentlyAddedRecipes, then right-click and select "Wrap with inline @defer "

  3. Run the query again and check out the Response Timeline.

The Response Timeline lets us visualize how long it took for the various pieces of our query to resolve and send data back to us. We can see that by adding @defer to the recentlyAddedRecipes , it no longer held up the rest of our query that was ready to return data much sooner.

Previous