Когда использовать GraphQLID вместо GraphQLInt?

Неясно, когда использовать GraphQLID вместо GraphQLInt.

Рассмотрим следующую схему:

type User {
  id: Int!
  firstName: String!
  lastName: String!
}

type Query {
  user (id: ID!): User
}

В случае Query.user кажется, нет никакой разницы, использовать ли GraphQLID или GraphQLInt.

В случае User.id использование GraphQLID приведет к преобразованию ввода в строку. Использование GraphQLInt гарантирует, что ввод является целым числом.

Это делает запрос и систему типов несовместимыми.

graphql-js spec просто говорит:

GraphQLScalarType, представляющий идентификатор.

Является ли это деталью реализации (например, должен ли клиент GraphQL преобразовывать GraphQLID в целое число, когда это возможно), или ожидается, что ID всегда будет строкой в ​​graphql?


graphql graphql-js
person Gajus    schedule 13.09.2016    source источник

Ответы (1)


arrow_upward
35
arrow_downward

Я посмотрел спецификацию GraphQL.

Скалярный тип ID представляет собой уникальный идентификатор, часто используемый для повторной выборки объекта или в качестве ключа для кэша. Тип ID сериализуется так же, как String; однако он не предназначен для чтения человеком. Хотя он часто является числовым, он всегда должен сериализоваться как String.

– https://spec.graphql.org/April2016/#sec-ID

Это отвечает на вопрос, оставлено ли это на реализацию или продиктовано спецификацией, т. е. идентификатор всегда должен сериализоваться в String.

Кроме того, в контексте типа ввода ввод должен быть преобразован в строку. Из спецификации:

Принуждение ввода

Если предполагается тип ввода, любое входное значение строки (например, "4") или целого числа (например, 4) должно быть приведено к идентификатору в соответствии с форматами идентификаторов, ожидаемыми данным сервером GraphQL. Любое другое входное значение, включая входные значения с плавающей запятой (например, 4.0), должно вызывать ошибку запроса, указывающую на неправильный тип.

Это оставляет меня с исходной проблемой.

У меня есть серверная часть mysql, где мои PK являются целыми числами.

Как я это вижу, у меня есть следующие варианты:

  • Начните использовать UUID для ПК. Однако это влияет на на производительность.
  • Игнорировать неявное требование (исходящее из экосистемы relayjs) чтобы идентификатор был уникальным для всего приложения, и приводить идентификаторы к нумерации, когда это возможно, для внутреннего потребления.
  • Hash Кодировать идентификаторы на уровне данных приложения, например. UUID base64 получено из объединения имени таблицы и значения PK.

Я иду с последним вариантом. Это также подход, который graphql-relay-js принял через toGlobalId и fromGlobalId.

person Gajus    schedule 13.09.2016