#graphql #relay #apollo-federation
Вопрос:
Мы пытаемся реализовать запрос узла ретрансляции с помощью федерации Apollo. Поскольку Apollo не знает о ретрансляции, мы должны реализовать запрос узла в какой-либо службе (Службе разрешения узлов).
interface Node {
id: ID!
}
type Query {
node(id: ID!): Node!
}
Проблема в том, что служба разрешения узлов не знает ни об одном из типов реализации, как они определены в других подграфах службы.
Шлюз Apollo отправляет следующий запрос в службу разрешения узлов
{node(id:"dHlwZUZyb21BU2VydmljZTox"){__typename ...on TypeFromAnotherService{id __typename}}}
Проверка запроса завершается неудачно, так как служба ничего не знает об TypeFromAnotherService
этом . Мы можем реализовать запрос узла, так как у нас есть тип, закодированный в идентификаторе, но мы не знаем, как исправить проверку.
- Мы можем динамически генерировать схему на основе федеративной схемы. Это, кажется, используется здесь, но кажется громоздким
- Отключите проверку и доверьтесь проверке Apollo GW. Нам это не нравится, и кажется, что это невозможно в DGS Netflix, которые мы используем на бэкэнде.
Есть идеи, как заставить запрос узла ретрансляции работать с федерацией?
Комментарии:
1. С этим связана новая проблема
Ответ №1:
Мы решили эту проблему, внедрив автономный распознаватель узлов. Он выполняет следующие действия:
- Проверяет запрос и генерирует схему «на лету» в случае, если Apollo использует тип во фрагменте. Распознаватель узлов в основном добавляется
TypeFromAnotherService
в схему. - Распознаватель узлов извлекает тип из идентификатора и генерирует ответ.
Мы думаем об открытом поиске сервиса, кто-нибудь заинтересуется?
Комментарии:
1. Конечно, у клиента Apollo есть свой собственный способ кэширования данных, но глобальный шаблон идентификатора ретрансляции также полезен только с точки зрения API. Жаль, что это не рассматривается официально в реализации федерации. Мне было бы интересно, если бы вы разработали реализацию распознавателя узлов plug-and-play для шлюза.