Federation и lookahead: батчинг за пределами DataLoader

Федеративный граф маршрутизирует запрос через subgraph users и subgraph posts. Supergraph-роутер автоматически собирает 50 user-ссылок в один _entities-вызов. Внутри users-subgraph реализация __resolveReference проходит цикл по 50 representations и 50 раз ходит в базу. Federation отдал тебе сетевой батч бесплатно; батч на базу — всё ещё твоя ответственность.

Как Apollo Federation батчит между subgraph’ами

В федеративной схеме каждый subgraph, владеющий entity-типом, экспонирует резолвер __resolveReference(representation). Когда запрос пересекает границы subgraph — скажем, posts-subgraph возвращает Post.author: User, а users-subgraph владеет User — supergraph-роутер:

1. Собирает все User-ссылки, возникшие при разрешении запроса (например, 50 постов, каждый ссылается на автора).
2. Отправляет один _entities(representations: [_Any!]!) в users-subgraph со всеми 50 representations.
3. __resolveReference в users-subgraph вызывается для каждого representation.

Кросс-subgraph батч автоматический и бесплатный. Роутер делает всё сам.

Что ты всё ещё обязан сделать внутри __resolveReference

Наивная реализация:

// users subgraph — наивно, N+1 внутри _entities
User: {
  __resolveReference: async (rep) => {
    return db.users.findById(rep.id); // Один запрос на representation
  }
}

С 50 representations это делает 50 SQL-запросов внутри единственного _entities-вызова. Нужен DataLoader:

// users subgraph — правильно
User: {
  __resolveReference: (rep, ctx) => ctx.loaders.user.load(rep.id),
}

Загрузчик батчит все 50 .load(rep.id) вызовов из 50 __resolveReference-вызовов в один WHERE id IN (...).

Supergraph-роутер:
  posts subgraph → 50 постов, у каждого authorId
  → один _entities([{__typename:"User", id:7}, ...×50]) в users subgraph

users subgraph (наивно):
  __resolveReference({id:7})  → SELECT * FROM users WHERE id=7   (1 SQL)
  __resolveReference({id:9})  → SELECT * FROM users WHERE id=9   (1 SQL)
  ... × 50                                                       (50 SQL)

users subgraph (с DataLoader):
  __resolveReference({id:7})  → loader.load(7)   (в очереди)
  __resolveReference({id:9})  → loader.load(9)   (в очереди)
  ... × 50                    → batchFn([7,9,...]) → 1 SQL

Lookahead: сворачивание многоуровневой вложенности

DataLoader чинит форму «N запросов за одной колонкой». Если клиент просит posts { author { profile { bio } } }, у тебя по-прежнему три уровня разрешения — DataLoader накапливает каждый уровень отдельно, три поездки вместо одной.

Resolver lookahead читает AST из аргумента info внутри top-level резолвера, видит, какие дочерние поля запросил клиент, и джойнит их одним SQL на верхнем уровне.

Query: {
  posts: (_, __, ctx, info) => {
    const wantsAuthor = selectionSetContains(info, 'author');
    const query = wantsAuthor
      ? 'SELECT posts.*, users.name AS author_name FROM posts JOIN users...'
      : 'SELECT * FROM posts';
    return db.query(query);
  }
}

Библиотеки Pothos, TypeGraphQL с SelectQueryBuilder и Hasura реализуют это, маппя AST в SQL-планировщик.