何时使用GraphQLID而不是GraphQLInt？

Question

目前尚不清楚何时使用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只是说：

  

表示ID的GraphQLScalarType。

这是一个实现细节（例如，当GraphQL客户端可以将GraphQLID转换为整数时），或者ID是否始终是graphql中的字符串？

Answer 1

我看了一下GraphQL规范。

  

ID标量类型表示唯一标识符，通常用于重新获取对象或作为缓存的键。 ID类型的序列化方式与String相同;但是，它并不是人类可读的。虽然它通常是数字，但应始终序列化为String。

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

这回答了问题是由实施还是由规范决定的问题，即ID应始终序列化为String。

此外，在输入类型的上下文中，需要将输入强制转换为字符串。来自规范：

  

输入强制

     

当预期作为输入类型时，任何字符串（例如"4"）或整数（例如4）输入值都应强制转换为ID，以适合给定的GraphQL服务器所期望的ID格式。任何其他输入值（包括浮点输入值（例如4.0））都必须引发指示错误类型的查询错误。

这让我遇到了原始问题。

我有一个mysql后端，我的PK是整数。

我看到它的方式，我有这些选择：

• 开始使用UUID进行PK。但是，这有performance implications。
• 忽略隐含的要求（源自relayjs生态系统），使整个应用程序中的ID唯一，并在可能的情况下将ID转换为数字以供内部使用。
• 哈希在应用程序数据层上编码ID，例如 UUID base64派生自表名和＆amp;的串联PK值。

我会选择后者。这也是graphql-relay-js通过toGlobalId和fromGlobalId采用的方法。