Зачем нужны ребра в соединении Relay / GraphQL?

Поле edges предоставляет вам место для ввода данных для каждого края. Например, вы можете захотеть поместить туда поле creator или priority, описывающее, кто добавил преимущество и насколько важны отношения, соответственно.

Если вам не нужна такая гибкость (или другие функции, которые вы получаете с подключениями, например разбиение на страницы), вы можете использовать простой тип GraphQLList. См. этот ответ Подробнее о разнице между подключениями и списками.

(Обновлено с дополнительными пояснениями)

Есть 3 способа представить массив данных в GraphQL:

1. Список: используйте, когда у вас есть конечный список связанных объектов, которые вы можете получить сразу все. В GraphQL SDL это представлено как [Ship].
2. Узлы: используйте, когда вам нужно разбить список на страницы, обычно потому, что в нем могут быть тысячи элементов. Обратите внимание, что это не является частью спецификации Relay и, как таковая, не поддерживается клиентом Relay (вместо этого вы должны обернуть элемент краем, как описано в # 3), но некоторые другие клиенты, такие как Apollo, более гибкие и поддержите эту конструкцию (но вам нужно предоставить больше шаблонов). В GraphQL это будет представлено как type ShipConnection { nodes: [Ship], pageInfo: PageInfo! }.
3. Ребра: используйте, когда помимо разбивки на страницы вам также необходимо предоставить дополнительную информацию для каждого ребра в соединении (подробнее читайте ниже). В GraphQL вы бы написали это как type ShipConnection { edges: [ShipEdge], pageInfo: PageInfo! }.

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

type Query {
  ships: [Ship]       // #1
  shipsConnection: [ShipConnection]
}

type ShipConnection {
  nodes: [Ship]       // #2
  edges: [ShipEdge]   // #3
  pageInfo: PageInfo!
}

type PageInfo {
  endCursor           // page-based pagination
  hasNextPage
}

type ShipEdge {
  cursor: String!     // edge-based pagination
  node: Ship
  // ... edge attributes
}

type Ship {
  // ... ship attributes
}

Списки (№1) следует использовать только тогда, когда вы знаете, что количество элементов не будет расти (например, если у вас есть Post, вы можете захотеть вернуть tags в виде списка, но вы не должны делать этого с comments). Чтобы выбрать между №2 и №3, есть две причины использовать ребра вместо простых узлов:

• Это место для атрибутов, специфичных для края. Например, если у вас есть User, который принадлежит многим Group, в реляционной базе данных у вас будет таблица UserGroup с user_id и group_id. Эта таблица может иметь дополнительные атрибуты, такие как role, joined_at и т. Д. GroupUserEdge тогда будет местом, где вы можете получить доступ к этим атрибутам.

• Есть место для курсора. Relay, помимо разбивки на страницы (с использованием pageInfo), поддерживает разбиение на страницы на основе краев. Зачем Relay нужен курсор для каждого ребра? Поскольку Relay интеллектуально объединяет требования к данным из всего вашего приложения, у него может уже быть соединение с теми же параметрами, которые вы запрашиваете, но в нем недостаточно записей. Чтобы получить недостающие данные, он может запросить данные в соединении после курсора некоторого края.

  Я понимаю, что это может сбивать с толку, учитывая, что в базах данных тоже есть курсоры, а на запрос есть только один курсор. Ретрансляционное соединение на самом деле не является запросом, это скорее набор параметров, которые идентифицируют запрос. Курсор края соединения - это набор параметров, которые определяют позицию в соединении. Это более высокий уровень абстракции, чем чистый курсор запроса (помните, что ребра должны иметь возможность идентифицировать позицию даже через соединение, которое может не быть запросом БД или быть скрытым сторонней системой). Из-за такой необходимой гибкости одного курсора для соединения было бы недостаточно.

Мы написали в блоге статью о различиях между простой схемой GraphQL и схемой, специфичной для Relay:

https://www.prisma.io/blog/connections-edges-nodes-in-relay-758d358aa4c7