Связь между схемами сшитых графических соглашений на микроуслугах - PullRequest
Новая
       11

Связь между схемами сшитых графических соглашений на микроуслугах

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

У меня есть следующая структура, которую я считаю довольно распространенной. Я искал и не могу найти никакой информации о рекомендованном способе для сшитых схемами сервисов вызывать друг друга (пока еще используется интерфейсом). Вот моя ситуация:

Швы схемы Api Gateway:

  • Служба поддержки пользователей
  • Служба сообщений

Служба сообщений использует mongodb, а служба пользователей - PostgreSQL. Схема службы сообщений включает в себя только user_id, а не полный пользователь. Когда мне нужна страница постов (с соответствующей информацией о пользователе), я вызываю службу пользователей, используя извлечение узла из решателя getPosts в службе постов, например: 

{
  getUsers(user_id__in:[1,5,9,3]){
    username
    join_date
  }
}

Это решение кажется "грязным" по сравнению с тем, насколько элегантным был остальной apollo-graphql.

Является ли более типичным игнорирование частей graphql для разрешения данных и использование типичной структуры конечной точки покоя, предоставляемой базовым экспресс-сервером apollo-graphql? Если нет, я должен звонить другим службам напрямую или вызывать их через шлюз API? Если я должен вызывать их через шлюз api, есть ли какой-нибудь встроенный элегантный способ вызова шлюза api с использованием некоторой функциональности Apollo (поскольку службы сшиты схемой).

1 Ответ

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

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

const extensions = `
extend type User {
  posts
}

extend type Post {
  user
}
`

const mergedSchema = mergeSchemas({
  schemas: [
    usersSchema,
    postsSchema,
    extensions,
  ],
  resolvers: {
    User: {
      posts: {
        fragment: `... on User { id }`,
        resolve(user, args, context, info) {
          return info.mergeInfo.delegateToSchema({
            schema: postsSchema,
            operation: 'query',
            fieldName: 'posts',
            args: {
              userId: user.id,
            },
            context,
            info,
          });
        },
      },
    },
    Post: {
      user: {
        fragment: `... on Post { userId }`,
        resolve(post, args, context, info) {
          return info.mergeInfo.delegateToSchema({
            schema: postsSchema,
            operation: 'query',
            fieldName: 'user',
            args: {
              id: post.userId,
            },
            context,
            info,
          });
        },
      },
    },
  },
});

Здесь мы расширяем тип User из службы пользователей, чтобы включить поле posts.Мы используем delegateToSchema, чтобы указать, что это дополнительное поле на самом деле должно быть разрешено схемой службы сообщений путем запроса posts и передачи идентификатора пользователя в качестве аргумента userId (фактические имена полей и аргументов должны соответствовать вашим схемам).Аналогичным образом мы добавляем поле user к каждому Post и делегируем разрешение этого поля в схему обслуживания пользователей.

Пожалуйста, проверьте документы для получения дополнительной информации.

...