Почему GraphQL получает N+1

Bea просит posts { title, author { name } } — один HTTP-запрос на 50 постов. Sven смотрит в лог базы данных: 51 запрос. Схема верна. Никаких ошибок. Это GraphQL, работающий точно по задумке — и обходящийся в 600 мс вместо 80 мс.

Как GraphQL выполняет запрос

GraphQL разрешает документ, обходя его в глубину и в ширину на каждом уровне. На каждое поле, которое выбрал клиент, сервер вызывает резолвер, зарегистрированный для пары Type.field. Резолверы получают (parent, args, context, info) и возвращают значение или Promise. Они намеренно изолированы: каждый резолвер не видит соседей, не знает, как родитель получил данные, и не может посмотреть, какие ещё резолверы запустятся.

Именно эта изоляция делает GraphQL компонуемым — можно добавить поле к типу, не трогая остальные резолверы. Но она же является прямой причиной N+1.

Почему изоляция порождает N+1

Возьмём запрос posts { title, author { name } }. Движок выполнения:

1. Вызывает Query.posts → выполняет SELECT * FROM posts LIMIT 50 → возвращает 50 объектов постов.
2. Для каждого из 50 постов вызывает Post.author(parent=post, ...) → выполняет SELECT * FROM users WHERE id = post.author_id → 50 отдельных запросов.

Итого: 51 поездка в базу данных на один HTTP-запрос.

REST-контроллер для того же эндпоинта написал бы SELECT posts JOIN users ON users.id = posts.author_id — один запрос. Разработчик видит всю форму ответа в одном месте и может оптимизировать SQL. В GraphQL резолвер Post.author видит только один пост за раз. Нет глобальной точки планирования.

Метафора официанта

Ресторан, где каждый стол заказывает блюда по одному. Стол на шестерых отправляет официанта шесть раз — по разу на блюдо. Кухня быстрая, но официант проводит смену в дороге. Скорость кухни не имеет значения, когда ходьба и есть затраты.

DataLoader — менеджер, говорящий: держи талоны, пока не хлопну, потом неси всё сразу. Хлопок — один тик event loop. Этот урок объясняет проблему; следующие два — решение.