何时使用GraphQLID代替GraphQLInt? [英] When to use GraphQLID instead of GraphQLInt?

查看:342
本文介绍了何时使用GraphQLID代替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.

规范只是说:

代表ID的GraphQLScalarType.

这是实现细节吗(例如GraphQL客户端应将GraphQLID强制转换为整数),还是期望ID始终是?

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://facebook.github.io/graphql/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.

我有一个后端的问题,我的PK是整数.

I have a mysql backend where my PK are integers.

我看到的方式有以下几种选择:

The way I see it, I have these options:

  • 开始将UUID用于PK.但是,这具有对性能的影响.
  • 忽略隐式要求(起源于生态系统),以在整个应用程序中拥有唯一的ID,并在可能的情况下将ID转换为数字.
  • 哈希在应用程序数据层上编码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 通过

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屋!

查看全文
登录 关闭
扫码关注1秒登录
发送“验证码”获取 | 15天全站免登陆