GraphQL の N+1 問題とは何か、DataLoader はどう解決するのか?

Question

IT Interview Practice · Accepted Answer

**N+1 問題** は、フィールドリゾルバが親要素ごとに 1 回実行され、その各実行が独自のデータベースクエリを発行するときに発生します。N 件の投稿のリストを取得し、続いて各投稿の author を取得すると、**投稿のための 1 クエリ + author のための N クエリ** が発行されます。N+1 回の往復が、負荷の高い状況でパフォーマンスを壊します。

## なぜ起こるのか

リゾルバはフィールドごと、要素ごとに実行されます。`Post.author` はリスト内のすべての投稿について個別に実行され、それぞれが互いのことを知らないため、各自が独自の `findById` を行います。

```js
// BAD: one DB call per post -> N+1
const resolvers = {
  Post: {
    author: (post, _a, ctx) => ctx.db.users.findById(post.authorId),
  },
};
```

## DataLoader: バッチ + キャッシュ

**DataLoader** は同じティック内で行われた個々の `.load(id)` 呼び出しを遅延させ、収集したキーを 1 つの **バッチ関数** に渡してすべてを 1 クエリで取得します。また、リクエスト内でキーごとに **キャッシュ** するため、繰り返しの id は無料になります。

```js
import DataLoader from "dataloader";

// create ONE loader per request (put it on context so caching is request-scoped)
const userLoader = new DataLoader(async (ids) => {
  // ids arrives as [1, 2, 3, ...] -> a single batched query
  const users = await db.users.findByIds(ids);
  // MUST return values in the SAME ORDER as ids
  return ids.map((id) => users.find((u) => u.id === id));
});

const resolvers = {
  Post: {
    author: (post, _a, ctx) => ctx.userLoader.load(post.authorId), // batched
  },
};
// Now N author resolvers collapse into 1 query: total 2 queries, not N+1.
```

2 つのルール: ローダーは **リクエストごと** に作成すること (グローバルにはしない — ユーザー間で古いデータが漏れてしまう)、そしてバッチ関数は結果を **キーと正確に同じ順序で** 返さなければならないこと。

## なぜ重要なのか

N+1 は最も一般的な GraphQL のパフォーマンス上の罠であり、ほぼ確実に出る面接の質問です。DataLoader に手を伸ばすこと — そして *なぜ* それがリクエストスコープで順序を保持しなければならないかを知っていること — は、本物のプロダクション経験を示します。

なぜ起こるのか

DataLoader: バッチ + キャッシュ

なぜ重要なのか

関連する質問