GraphQL слияние данных из нескольких вызовов REST - PullRequest
Новая
       63

GraphQL слияние данных из нескольких вызовов REST

0 голосов
/ 20 октября 2018

Я смотрел на некоторые реализации GraphQL , и я понимаю, что GraphQL позволяет вам просматривать данные в виде графика.

Что означает, что вы получаете списоккниги, которая является вызовом ОТДЫХА.Книги могут иметь имя автора.

Когда пользователю требуется дополнительная информация об авторе, он говорит об этом, и делается еще один вызов REST для получения более подробной информации об этом авторе.

Аналогично, в списке книг может быть поле с именем Publisher и т. Д.на.Итак, здесь вы извлекаете данные, как будто вы подключаете узел Book к узлу Author или Publisher.

Но я видел несколько реализаций, в которых данные двух вызовов rest объединяются с использованием циклов for и представляются в пользовательском интерфейсе.например, вызовите REST API книг, а затем вызовите REST API авторов, написавших эти книги.Запустите вложенный цикл for for (сложность n ^ 2), чтобы объединить результат и показать информацию о книгах и авторах в одном сводном представлении.

Является ли это приемлемой практикой или нарушает некоторые основные понятия о том, что GraphQL не должен делать?

1 Ответ

0 голосов
/ 21 октября 2018

Я не уверен, что сказал бы, что это "нарушает некоторые основные концепции", но есть потенциальный недостаток для "фронтальной загрузки" всех ваших вызовов к конечной точке REST таким образом.GraphQL позволяет вам определить распознаватель для каждого поля, который определяет, какое значение возвращает поле.Поле «parent» разрешается до его «дочерних» полей, а значение «parent» передается распознавателям для каждого «дочернего».

Допустим, у вас есть такая схема: 

type Query {
  book(id: ID): Book
}

type Book {
  title: String
  author: Author
  publisher: Publisher
}

Здесь поле book будет преобразовано в объект, представляющий книгу, и этот объект будет передан резольверам.для title, author и publisher.

Если для определенного поля не определен определитель, по умолчанию выполняется поиск свойства в родительском объекте с тем же именем, что и у поля.и верни это.Таким образом, ваш распознаватель для book может получить как книгу, так и автора и издателя с некоторой конечной точки REST (всего 3 вызова) и вернуть объединенный результат.В качестве альтернативы, вы можете просто получить книгу и позволить распознавателю полей author выбрать автора, а распознаватель полей publisher выбрать издателя.

Они указывают, что распознаватель вызывается только в том случае, еслиэто поле запрашивается. Разница между этими двумя подходами заключается в том, что вы потенциально можете запросить book и запросить только заголовок. 

query SomeQuery {
  book(id: 1) {
    title
  }
}

В этом сценарии, если вы фронтально загружаете все свои APIвызовы, затем вы делаете два дополнительных вызова к конечной точке REST (для автора и издателя) без необходимости.

Конечно, если у вас есть поле, которое возвращает массив книг, вы можете не захотетьУдарьте свою конечную точку REST, выбирая автора для каждой запрошенной книги, поэтому в этих ситуациях может иметь смысл выбрать как книги, так и авторов в корневом запросе.

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

...