Лучший способ использовать и комбинировать еще один publi c apollo graphql apis: сшивание схемы федерации v - PullRequest
0 голосов
/ 19 июня 2020

Я разрабатываю решение backend-for-frontend (BFF) для веб-клиента с apollo graphql

Предпосылки использования , наша организация имеет общее использование graphql api, которым владеет другая команда, и моя команда создает другой сервер graphql для его использования. Это позволит нам снять с клиента тяжелые вычисления. Мы также надеемся создать комбинированную схему для доступа к общему использованию API, когда это необходимо, с той же конечной точки, что и наш BFF.

Мои вопросы:

  1. Федерация apollo рекомендуется для объединения схем, однако настоятельно рекомендуется, чтобы объединенные серверы были частными за брандмауэром из-за мощности поля _entities. Почему это так и будет ли это проблемой, если данные не являются конфиденциальными данными пользователя? Мы бы предпочли, чтобы все серверы были опубликованы c.
  2. Сшивка схемы apollo может действительно соответствовать нашему вариант использования лучше, поскольку он не отмечает, что любой api является частным. Это также может сделать DataSource logi c более оптимизированным для вычислений, которые нам необходимо произвести. Однако большая часть документации, которую я вижу, касается миграции ИЗ сшивания схемы. Будет ли сшивание схемы устаревшим в ближайшем будущем?
  3. Есть ли другой вариант , который, кажется, больше соответствует требованиям, чем я пропустил?

Ответы [ 2 ]

0 голосов
/ 07 июля 2020

Чтобы ответить на ваши вопросы:

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

Запрос _entities , как вы сказали, очень мощный. Например, если вы используете ярлыки для управления доступом, это может быть опасно. Предположим, у вас есть частные пользователи. Если у вас есть проверки аутентификации для Query.user(id: ID) в нефедеративном запросе, вам не обязательно ставить дополнительные проверки аутентификации для User.homeAddress, так как вы не можете перейти к вложенному полю, не имея доступа к верхнему -уровневое поле. Теперь давайте представим, что ваша адресная служба расширяет объект пользователя. Теперь я могу сделать этот вызов конечной точке службы адреса (не через шлюз):

query ($_representations: [_Any!]!) {
  _entities(representations:$_representations) {
    ... on User {
      homeAddress {
        street1
        street2
        city
        state
        postalCode
      }
    }
  }
}
{
  "_representations": [{
    "__typename": "User",
    "id": "user-id-whatever"
  }]
}

И если вы сделали «ленивый контроль доступа», вы теперь не защищены, потому что он никогда не звонит сначала служба пользователей для получения разрешения. В дополнение к этому, вы можете видеть, что это зависит от того, имеете ли вы дело с «нечувствительными» данными или «незащищенными данными».

Сшивание схемы уже давно устарело. Похоже, они отказались от него, поскольку я больше не вижу предупреждений об устаревании там, где раньше видел их, но, насколько мне известно, он «все еще исчезает».

Не совсем, но я бы также рекомендовал Федерацию. Честно говоря, я долгое время занимался производством и того, и другого, и я был большим поклонником Federation, и я рекомендовал бы его в большинстве случаев. Единственное реальное различие между федерацией и сшиванием состоит в том, что сшиванием вы должны открывать «дополнительные поля» из ваших сервисов поддержки (например, чтобы добавить пользователя к объекту, сервис должен будет предоставить userId, который вы затем можете использовать для Пришейте User на. Федерация обходит это, выставляя _entities, но в основном это вещь, и Федерация делает это за вас, поэтому вам не нужно создавать делегацию.

0 голосов
/ 20 июня 2020

Скрытие ваших федеративных сервисов не является обязательным, это скорее рекомендация.

Если у вас одна комбинированная схема, то зачем вам раскрывать некомбинированные отдельные схемы?

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

Когда вы используете объединение нескольких схем graphql, вы также, вероятно, обращаетесь друг к другу или служба A может добавлять поля в службу B и т. д. c. Запросы к этим полям будут неработоспособны, если вы используете отдельные службы. (но он все равно будет работать, просто отсутствуют поля)

И да, сшивание схемы устарело. Apollo рекомендует разработчикам использовать вместо этого федерацию apollo.

Следует отметить, что федерация apollo еще не поддерживает подписку, поэтому, если подписка является обязательной прямо сейчас, вам следует придерживаться сшивания схемы до тех пор, пока подписка не будет выпущена.

...