Клиент Apollo: может ли apollo-link-rest разрешить отношения между конечными точками? - PullRequest
Новая
       71

Клиент Apollo: может ли apollo-link-rest разрешить отношения между конечными точками?

0 голосов
/ 07 мая 2019

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

Пример: Для простоты, скажем, Person может иметь несколько Books.

Теперь конечная точка api/person/{i} возвращает это: 

{ id: 1, name: "Phil", books: [1, 5, 17, 31] }

Конечная точка api/book/{i} возвращает это (обратите внимание, что автор может снова быть отношением): 

{ id: 5, title: "SPRINT", author: 123 }

Можно ли как-нибудь научить клиента apollo разрешать эти конечные точки таким образом, чтобы я мог написать следующий (или аналогичный) запрос: 

query fetchBooksOfUser($id: ID) {
  person (id: $id) {
    name,
    books {
      title
    }
  }
}

Ответы [ 2 ]

1 голос
/ 08 мая 2019

В качестве альтернативы вы можете настроить свой собственный BackQL-интерфейс как посредник между вашим интерфейсом и REST API, который вы планируете использовать.

Довольно просто реализовать REST API в качестве источников данных в GraphQL с помощью Apollo Server и пакета, такого как apollo-datasource-rest, который поддерживается авторами Apollo Server.

Это также позволит вам масштабировать, если вам когда-либо понадобятся другие источники данных (БД, сторонние API и т. Д.), И даст вам полный контроль над тем, какие именно данные возвращают ваши запросы.

1 голос
/ 07 мая 2019

Я не пробовал (пока) в одном запросе, но это возможно.

Чтение документов, начиная с это

В начале я бы попробовал что-то вроде: 

query fetchBooksOfUser($id: ID) {
  person (id: $id) @rest(type: "Person", path: "api/person/{args.id}") {
    name,
    books @rest(type: "Book", path: "api/book/{data.person.books.id}") {
      id,
      title
    }
  }
}

... но, вероятно, это не сработает - возможно, он недостаточно умен для работы с массивами.

ОБНОВЛЕНИЕ: См. примечание для похожего примера, но с использованием одного общего разрешенного родителями параметра. В вашем случае мы частично разрешили books как массивы объектов с id. Я не знаю, как использовать эти ids для разрешения пропущенных полей () на том же уровне дерева.

Другая возможность - сделать связанные подзапросы / подзапросы (как-нибудь) в Person type patcher. Должно быть возможно.

Действительно ли это должен быть один запрос? Вы можете предоставить идентификаторы дочерним контейнерам, каждый из которых запускает собственный запрос при необходимости.

ОБНОВЛЕНИЕ: Apollo позаботится о пакетировании (Не для REST, не для всех серверов graphql - читайте docs ).

«это удобно» для создания одного запроса, но apollo кеширует его, нормализуя ответ по типам - данные будут храниться отдельно. Использование одного запроса удерживает вас в пределах overfetching camp или template thinking (соберите все возможные данные до одного шага рендеринга).

Ract thinking сохраняет ваши данные и представление разложенными, используемыми при необходимости, более специализированными и т. Д.

<Person/> Контейнер будет запрашивать данные, необходимые для визуализации, и список идентификаторов, необходимых для детей. Каждый <Book/> будет запрашивать собственные данные, используя переданный id.

...