Когда использовать 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 просто говорит:

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

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

Ответы

Ответ 1

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

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

- https://facebook.github.io/graphql/April2016/#sec-ID

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

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

Входное Принуждение

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

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

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

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

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

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