GraphQL: один большой запрос против множества маленьких запросов

Question

Я знаю, что этот вопрос так же стара, как время - и это не серебряная пуля. Но я думаю, что там может быть сплошная модель, и я бы не хотел изобретать колесо.

Рассмотрим следующие два варианта схемы:

Подход 1) Моя оригинальная реализация

type Query {
  note(id: ID!): Note
  notes(input: NotesQueryInput): [Note!]!
}

Подход 2) Мой текущий экспериментальный подход

type DatedId {
  date: DateTime!
  id: ID!
}

type Query {
  note(id: ID!): Note
  notes(input: NotesQueryInput): [DatedId!]!
}

Различия:

при подходе 1) запрос notes либо выдаст список потенциально больших объектов Note

с подходом 2) запрос примечаний вернет гораздо более легкую полезную нагрузку, НО тогда потребуется выполнить n дополнительные запросы

Итак, мой вопрос о стеке Apollo Client / Server с кэшем в памяти, который является наилучшим подходом. для создания отзывчивого клиента с масштабируемым сервером.

---

Заметки

• При подходе 1 - мой 500 МБ dyno (сервер heroku) исчерпал память.

• Я ожидаю, что при любом подходе я буду осуществлять разбиение на страницы с соединением / шаблоном края

• сервер graphql в основном обслуживает мой собственный интерфейс.

Answer 1

Если у вас заканчивается память на сервере, возможно, пора обновить. Если у вас сейчас недостаточно памяти, представьте, что произойдет, если несколько пользователей поразят вашу конечную точку.

Единственный другой способ обойти эту конкретную проблему - разбить ваш запрос на несколько небольших запросов. Тем не менее, ваш предложенный подход страдает от пары проблем:

• В итоге ваш сервер и база данных получат значительно больше запросов
• Ваш пользовательский интерфейс может загружаться дольше, в зависимости от того, требуется ли немедленная обработка запрошенных данных
• Обработка сценария в случае сбоя одного из ваших запросов или попытки повторить неудачный запрос может быть сложной задачей

Вы уже предложили добавить нумерацию страниц, и я думаю, что это был бы гораздо лучший способ разбить ваш большой запрос на более мелкие. Пагинация не только обеспечивает лучший пользовательский опыт, но и устанавливает ограничение на размер страницы, что позволяет эффективно ограничивать размер данного запроса.

Еще одна опция, которую вы можете рассмотреть, - это использование отложенных запросов . Эта экспериментальная функция была добавлена ​​специально для дорогих запросов. Сделав одно или несколько полей для типа Note отложенным, вы фактически вернете для них значение null вначале, а их значения будут отправлены во втором ответе «patch» после того, как они окончательно разрешатся. Это прекрасно работает с полями, которые требуют больших затрат, но также может помочь с полями, которые возвращают большой объем данных.