Какие ограничения есть у курсора в GraphQL Connections for Relay?

Я почти закончил пакет для NodeJS https://github.com/nodkz/graphql-compose-connection, который позволяет создавать типы соединений для типов graphql, построенных с помощью graphql-compose.

Этот пакет полностью соответствует Спецификации подключений релейного курсора (https://facebook.github.io/relay/graphql/connections.htm) с замечательными дополнениями: filter arg (для фильтрации записей) и sort arg (для сортировки записей по уникальным индексам).

Итак, у меня есть следующие вопросы об уникальности курсора:

1) Должен ли курсор быть уникальным среди разных типов?

2) Должен ли курсор быть уникальным среди одного соединения с разными аргументами?

Например. в UserConnection у меня есть фильтр arg. И я хочу отображать всех пользователей в первом списке и онлайн-пользователей во втором (2 списка одновременно на странице). В обоих списках может присутствовать один пользователь с таким же курсором.

3) Если Relay получит похожие курсоры в одном соединении, выдаст ли он ошибку?

4) Должен ли быть курсор в кодировке base64, или он может содержать строковый объект json?


graphql connection relay
person nodkz    schedule 14.07.2016    source источник

Ответы (1)


arrow_upward
1
arrow_downward

1) Должен ли курсор быть уникальным среди разных типов?

Если ваш вопрос здесь: «Должны ли курсоры быть глобально уникальными?», Ответ - нет. Они не похожи на идентификаторы, которые должны быть глобально уникальными в Relay, чтобы облегчить повторную выборку (для сравнения). Курсор может быть таким простым, как «100» или «101», хотя на практике часто содержит что-то более описательное и / или структурированное, чем это.

2) Должен ли курсор быть уникальным среди одного соединения с разными аргументами?

Например. в UserConnection у меня есть фильтр arg. И я хочу отображать всех пользователей в первом списке и онлайн-пользователей во втором (2 списка одновременно на странице). В обоих списках может присутствовать один пользователь с таким же курсором.

Это специфическая для реализации вещь. Курсор предназначен для включения разбивки на страницы, а его содержимое может быть произвольным. Просто он должен содержать достаточно информации в сочетании с другими аргументами в соединениях, чтобы ваша схема GraphQL на сервере могла определять, что она должна возвращать для следующей (after) или предыдущей (before) страницы.

3) Если Relay получит похожие курсоры в одном соединении, выдаст ли он ошибку?

Я не уверен, будет ли это, но вы можете попробовать и узнать. Даже если это не приведет к ошибке, это, вероятно, не имеет смысла. Назначение курсора - позволить вам указать относительную начальную точку для разбивки на страницы, поэтому, если курсор «x» появляется в двух разных местах соединения, что означает «первые 10 после x»?

4) Должен ли быть курсор в кодировке base64, или он может содержать строковый объект json?

Base64 - это то, что мы делаем по соглашению, а не потому, что это предписано, чтобы прояснить, что курсоры следует рассматривать как непрозрачные токены, на внутреннюю структуру которых нельзя полагаться. Они зависят от реализации. Итак, я считаю, что вы могли бы использовать строку JSON, если хотите, но есть некоторая выгода от ее кодирования Base64.

person wincent    schedule 15.07.2016
comment
Отказ от ответственности: я работаю над Relay, а не над GraphQL, но я ответил на них, насколько мне известно. - person wincent; 15.07.2016
comment
большое спасибо. Ваше заявление об отказе от ответственности было моим требованием;) Мне нужен был ответ от команды Relay, что у вас нет особых манипуляций с cursors в Relay. Итак, github.com/nodkz/graphql-compose-connection готовы к производству. - person nodkz; 20.07.2016
comment
Привет, @wincent, когда вы говорите, что курсор должен быть простым, например 100 или 101; как бы это было сгенерировано. Мне интересно, если, например, ваш BE обращается к базе данных (скажем, MySQL для аргументации), то как курсор, такой как 100 или 101, переводится в позицию в БД (единственный способ увидеть это возможно, используя поле идентификатора?) - person Henry Hargreaves; 21.08.2020