GraphQL: как вкладывать в схему схемы? - PullRequest
0 голосов
/ 28 декабря 2018

В прошлом году я конвертировал приложение для использования Graphql.До сих пор это было здорово, во время конвертации я по существу перенес все свои сервисы, которые поддерживали мои конечные точки REST, для поддержки запросов и мутаций grapqhl.Приложение работает хорошо, но хотел бы продолжать развивать мой граф объектов.

Давайте рассмотрим, есть ли у меня следующие отношения:

Пользователь -> Команда -> Доски -> Списки -> Карты -> Комментарии

В настоящее время у меня есть две разные вложенные схемы:Пользователь -> команда:

    type User {
  id: ID!
  email: String!
  role: String!
  name: String!
  resetPasswordToken: String
  team: Team!
  lastActiveAt: Date
}

type Team {
  id: ID!
  inviteToken: String!
  owner: String!
  name: String!
  archived: Boolean!
  members: [String]
}

Тогда у меня есть Доски -> Списки -> Карты -> Комментарии

type Board {
  id: ID!
  name: String!
  teamId: String!
  lists: [List]
  createdAt: Date
  updatedAt: Date
}

type List {
  id: ID!
  name: String!
  order: Int!
  description: String
  backgroundColor: String
  cardColor: String
  archived: Boolean
  boardId: String!
  ownerId: String!
  teamId: String!
  cards: [Card]
}

type Card {
  id: ID!
  text: String!
  order: Int
  groupCards: [Card]
  type: String
  backgroundColor: String
  votes: [String]
  boardId: String
  listId: String
  ownerId: String
  teamId: String!
  comments: [Comment]
  createdAt: Date
  updatedAt: Date
}

type Comment {
  id: ID!
  text: String!
  archived: Boolean
  boardId: String!
  ownerId: String
  teamId: String!
  cardId: String!
  createdAt: Date
  updatedAt: Date
}

Что прекрасно работает.Но мне любопытно, насколько вложенным я могу по-настоящему составить свою схему.Если бы я добавил остальное, чтобы завершить график:

type Team {
      id: ID!
      inviteToken: String!
      owner: String!
      name: String!
      archived: Boolean!
      members: [String]
      **boards: [Board]**
    }

Это позволило бы получить гораздо более глубокий график.Однако меня беспокоило, насколько сложными будут мутации.Специально для схемы платы вниз мне нужно публиковать обновления подписки для всех действий.Который, если я добавлю комментарий, опубликовать всю доску обновления невероятно неэффективно.Хотя встроенная логика подписки для каждого создания / обновления каждой вложенной схемы кажется тонной кода для достижения чего-то простого.

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

Спасибо

1 Ответ

0 голосов
/ 31 декабря 2018

Цель GraphQL - избежать пары запросов, поэтому я уверен, что создание вложенной структуры - правильный путь.С учетом безопасности добавьте несколько библиотек ограничения глубины GraphQL.

GraphQL Руководства по стилю предполагают, что у вас есть все сложные структуры в отдельных типах объектов (как у вас, Comment, Team, Board ...).Тогда вам нужно сделать сложный запрос / мутацию.

Я бы хотел, чтобы вы расширили это предложение

Что, если я добавлю комментарий, опубликовать обновление всей доски будет невероятнонеэффективно

Я не уверен в этом, так как у вас есть ваш идентификатор карты.Таким образом, добавление нового комментария вызовет мутацию, которая создаст новую запись «Комментарий» и обновит карту с новым комментарием.

Таким образом, ваша структура данных на бэкэнде будет определять способ его получения, но не так, как вы его мутируете.Это.

Взгляните на GitHub GraphQL API , например:

  • каждая из мутаций представляет собой небольшую функцию для обновления / создания части сложного дерева дажеесли у них есть вложенная структура типов на бэкэнде.

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

...