API
GraphQL N+1: тест с выбором ответа
Суть Синтез юнита GraphQL N+1 в формате с выбором ответа — изоляция резолверов, scope DataLoader, контракты batch, federation и защиты по форме запроса.
Высота — путь к senior
НольJuniorMiddleSenior
Ты на senior-высоте — в орбитеШесть вопросов через весь юнит. Каждый — решение, которое ты принимаешь на реальном ревью или в инциденте: не определение для пересказа, а компромисс, который надо взвесить, когда один HTTP-запрос тихо выстреливает тысячу SQL-запросов.
Цель
Убедись, что связываешь изоляцию резолверов, batching и scope DataLoader, контракты batch-функции, federation и защиты по форме запроса — синтез, к которому вели шесть уроков.
Викторина
Completed
REST-контроллер для той же страницы «посты с авторами» делает один JOIN; GraphQL-сервер делает 51 запрос. Бага в схеме нет. В чём структурная причина?
Heads-up Оба работают поверх HTTP; транспорт ни при чём. Цена — изоляция резолверов, делающая один fetch на родителя, без места для JOIN.
Heads-up Большинство GraphQL-серверов асинхронны и могут батчить — DataLoader это доказывает. N+1 про изоляцию резолверов, а не про потоки.
Heads-up Спека не определяет кеширование, но это не связано. 51 запрос идёт от пер-полевого исполнения резолверов, а не от отсутствия кеша.
Викторина
Completed
Почему DataLoader батчит на границе тика event loop, а не по фиксированному таймеру 5 мс, и что это даёт?
Heads-up Node поддерживает setTimeout и setImmediate; DataLoader мог бы их использовать. Он выбирает границу микрозадач именно ради отсутствия задержки.
Heads-up Память задаётся размером batch, а не таймингом dispatch. Причина — задержка: граница тика срабатывает в момент, когда все load уровня поставлены в очередь.
Heads-up Тайминг dispatch не меняет порядок резолверов. Выгода — срабатывание в самый ранний полный момент без ожидания.
Викторина
Completed
Рефактор перенёс один DataLoader из context factory Apollo в module scope. Частота вызовов БД в 6× выше при неизменной частоте HTTP, и один tenant временами видит строки другого tenant. Почему?
Heads-up Размер памяти тут ни при чём. Общий инстанс протекает закешированными строками между tenant'ами и отдаёт устаревшие данные — баг корректности данных и есть симптом.
Heads-up Module scope не отключает batching внутри тика; он делит кеш между запросами. Дефекты — утечка и устаревание, а не потеря batching.
Heads-up Отключение кеша прячет устаревание, но инстанс всё равно общий между tenant'ами. Настоящий фикс — пер-запросная инстанциация в context factory.
Викторина
Completed
batchLoadFn выполняет SELECT ... WHERE id = ANY($1) и возвращает строки в порядке, который дал Postgres. Время от времени у постов отображается неверный автор. Какое правило нарушено?
Heads-up SQL валиден; порядок в SQL — не контракт. DataLoader мапит i-е возвращённое значение на i-й ключ, поэтому ты переупорядочиваешь в batch-функции через Map.
Heads-up DataLoader доверяет позициям массива и не валидирует порядок. Порча тихая — именно поэтому паттерн Map-по-ключу обязателен.
Heads-up Это баг порядка, а не кеша. Отключение кеша ничего не меняет; нужно выровнять возвращаемые значения по позициям входных ключей.
Викторина
Completed
Supergraph на Apollo Federation маршрутизирует запрос, ссылающийся на 50 пользователей через два subgraph'а. Что берёт на себя router, а что всё ещё должен subgraph пользователей?
Heads-up Subgraph'ы не делят БД; router говорит по HTTP, а не по SQL. Он батчит representations, но каждый subgraph владеет своим batching к БД.
Heads-up Federation батчит только на сетевом уровне. Внутрисубграфовый N+1 в __resolveReference — всё ещё твоя ответственность, добавь DataLoader.
Heads-up Он шлёт один вызов _entities со всеми 50 representations. Оставшаяся проблема — 50 пер-representation обращений к БД внутри subgraph'а.
Викторина
Completed
DataLoader работает, страница быстрая. Атакующий шлёт один документ с 1000 корневых алиасов (q1: user(id:1)…q1000: user(id:1000)). Обращения к БД схлопываются в один batch, но сервер всё равно страдает. Почему и что это останавливает?
Heads-up DataLoader умеет дробить через maxBatchSize; обращение к БД — не узкое место. Цена — 1000 исполнений резолверов, которые алиас-капы останавливают на валидации.
Heads-up Introspection лишь помогает разведке; схему можно восстановить из ошибок. Alias bomb — атака по форме запроса, останавливается алиас- и batch-капами.
Heads-up Alias bomb усиливается внутри одного запроса, поэтому пер-запросные rate limit'ы — именно то, что он обходит. Нужен алиас-кап и complexity scoring.
Итог
Сквозная линия юнита — один конвейер: изоляция резолверов порождает N+1, DataLoader схлопывает обращения к БД на границе тика, но только при пер-запросном scope и корректном контракте batch с тем же порядком; federation отдаёт сетевой batch, но DB-batch в __resolveReference всё ещё за тобой, а защиты по форме запроса (depth, мультипликативный complexity, persisted/trusted documents, алиас- и batch-капы) останавливают атаки, которых DataLoader не касается. DataLoader чинит, сколько обращений к БД делает запрос; слои защиты управляют тем, какие формы запроса вообще допущены к исполнению.