The slowest field sets the pace

When exploring in Sandbox earlier, we ran a few different operations—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 fields: recentlyAddedRecipes.

We'll find that any operations containing this field 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 fields from everything else. This mechanism is called @defer.

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

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

• It's a root field of the Query type
• It's a field of any entity type

1. Try running the operation below in Explorer.

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

   Copy

   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 fragment"

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 field, it no longer held up the rest of our query that was ready to return data much sooner.