Join us from October 8-10 in New York City to learn the latest tips, trends, and news about GraphQL Federation and API platform engineering.Join us for GraphQL Summit 2024 in NYC
Docs
Start for Free

How Federation Handles the N+1 Query Problem

Learn how to handle the N+1 problem for operations that return a list in a federated graph

federationsubgraphs

developers quickly encounter the infamous "N+1 problem" with that return a list:

query TopReviews {
topReviews(first: 10) {
id
rating
product {
name
imageUrl
}
}
}

In a monolithic , the execution engine takes these steps:

  1. Resolve the Query.topReviews , which returns a list of Reviews.
  2. For each Review in the list, resolve the Review.product field.

If the Query.topReviews field returns 10 reviews, then the executor resolves Review.product field 10 times. If the Reviews.product field makes a database or REST query for a single Product, then we'll see 10 unique calls to the . This is suboptimal for the following reasons:

  • It's more efficient to fetch the 10 products in a single query (for example SELECT * FROM products WHERE id IN (<product ids>)).
  • If any reviews refer to the same product, then we're wasting resources fetching something we already have.

The solution for monolithic GraphQL APIs is the dataloader pattern. All GraphQL server implementations support this pattern. The Apollo Server documentation explains how to use the JavaScript implementation in Node.js servers.

The N+1 problem in a federated graph

Consider the same TopReviews , but we've implemented the Review and Product types in separate :

Fortunately, ning handles N+1 queries for entities like the Product type by default! The query plan for this operation works like this:

  1. First, we Fetch the list of Reviews from the Reviews using the root field Query.topReviews. We also ask for the id of each associated product.
  2. Next, we extract the Product references and Fetch them in a batch to the Products subgraph's Query._entities root field.
  3. After we get back the Product entities, we merge them into the list of Reviews, indicated by the Flatten step.

Fetch (reviews)
Fetch (products)
Flatten (topReviews,[],products)

Writing efficient entity resolvers

In most subgraph implementations (including @apollo/subgraph), we don't write the Query._entities directly. Instead, we use the reference resolver API for resolving an individual entity reference:

const resolvers = {
Product: {
__resolveReference(productRepresentation) {
return fetchProductByID(productRepresentation.id);
},
},
};

The motivation for this API relates to a subtle, critical aspect of the subgraph specification: the order of resolved entities must match the order of the given entity references. If we return entities in the wrong order, those are merged with the wrong entities and we'll have incorrect results. To avoid this issue, most subgraph libraries handle entity order for you.

This does reintroduce the N+1 query problem: in the example above, we'll call fetchProductByID once for each entity reference.

Fortunately, the solution is exactly the same in a : dataloaders. In nearly every situation, reference should use a dataloader.

const resolvers = {
Product: {
__resolveReference(product, context) {
return context.dataloaders.products(product.id);
},
},
};

Now, when the calls the Products subgraph with a batch of Product entities, we'll make a single batched request to the Products data source.

Next
Home
Rate articleRateEdit on GitHubEditForumsDiscord

© 2024 Apollo Graph Inc., d/b/a Apollo GraphQL.

Privacy Policy

Company