何时使用 GraphQLID 而不是 GraphQLInt? [英] When to use GraphQLID instead of GraphQLInt?

问题描述

尚不清楚何时使用 GraphQLID 而不是 GraphQLInt.

It is not clear when to use GraphQLID instead of GraphQLInt.

考虑以下架构:

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

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

对于Query.user，使用GraphQLID还是GraphQLInt似乎没有区别.

In case of Query.user, it seem to make no difference whether to use GraphQLID or GraphQLInt.

对于 User.id，使用 GraphQLID 会将输入转换为字符串.使用 GraphQLInt 将确保输入是整数.

In case of User.id, using GraphQLID will cast the input to string. Using GraphQLInt will ensure that the input is an integer.

这使得查询和类型系统不一致.

This makes the query and type system inconsistent.

graphql-jsspec 简单地说:

表示 ID 的 GraphQLScalarType.

这是一个实现细节吗(例如，GraphQL 客户端是否应该将 GraphQLID 强制转换为整数)，或者是否期望 ID 始终是 graphql?

Is this an implementation detail (e.g. should GraphQL client cast GraphQLID to an integer when it can), or is it expected that ID is always a string in graphql?

推荐答案

我查看了 GraphQL 规范.

I had a look at the GraphQL spec.

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

The ID scalar type represents a unique identifier, often used to refetch an object or as the key for a cache. The ID type is serialized in the same way as a String; however, it is not intended to be human‐readable. While it is often numeric, it should always serialize as a String.

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

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

这回答了是留给实现还是由规范规定的问题，即 ID 应始终序列化为 String.

That answers the question whether it is left to implementation or dictated by the spec, i.e. ID should be always serialized to a String.

另外，在输入类型的上下文中，输入需要被强制转换为字符串.来自规范:

In addition, in the context of an input type, input needs to be coerced into a string. From the spec:

输入强制

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

When expected as an input type, any string (such as "4") or integer (such as 4) input value should be coerced to ID as appropriate for the ID formats a given GraphQL server expects. Any other input value, including float input values (such as 4.0), must raise a query error indicating an incorrect type.

这给我留下了最初的问题.

That leaves me with the original problem.

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

I have a mysql backend where my PK are integers.

在我看来，我有以下选择:

The way I see it, I have these options:

• 开始对 PK 使用 UUID.但是，这会性能影响.
• 忽略隐式要求(源自 relayjs 生态系统)使 ID 在整个应用程序中具有唯一性，并在可能的情况下将 ID 转换为数字以供内部使用.
• Hash 在应用程序数据层编码 ID，例如UUID base64 源自表名 & 的串联PK值.

• Start using UUIDs for PKs. However, this has performance implications.
• Ignore the implicit requirement (originating in the relayjs ecosystem) to have the ID unique across the application, and cast IDs to number when possible for internal consumption.
• Hash Encode IDs on the application data layer, e.g. UUID base64 derived from a concatenation of table name & PK value.

我会选择后一种.这也是 graphql-relay-js 的方法已通过 toGlobalId 和 采用href="https://github.com/graphql/graphql-relay-js#object-identification" rel="nofollow noreferrer">fromGlobalId.

I am going with the latter option. This is also the approach that graphql-relay-js has adopted via toGlobalId and fromGlobalId.

这篇关于何时使用 GraphQLID 而不是 GraphQLInt?的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！