Welcome to OGeek Q&A Community for programmer and developer-Open, Learning and Share
Welcome To Ask or Share your Answers For Others

Categories

0 votes
818 views
in Technique[技术] by (71.8m points)

graphql - When to use GraphQLID instead of GraphQLInt?

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

Consider the following schema:

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

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

In case of Query.user, it seem to make no difference whether to use GraphQLID or 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.

The spec simply says:

A GraphQLScalarType that represents an 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 ?

question from:https://stackoverflow.com/questions/39471075/when-to-use-graphqlid-instead-of-graphqlint

与恶龙缠斗过久,自身亦成为恶龙;凝视深渊过久,深渊将回以凝视…
Welcome To Ask or Share your Answers For Others

1 Reply

0 votes
by (71.8m points)

I had a look at the GraphQL spec.

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

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:

Input Coercion

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.

I have a backend where my PK are integers.

The way I see it, I have these options:

  • Start using UUIDs for PKs. However, this has performance implications.
  • Ignore the implicit requirement (originating in the 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.

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


与恶龙缠斗过久,自身亦成为恶龙;凝视深渊过久,深渊将回以凝视…
OGeek|极客中国-欢迎来到极客的世界,一个免费开放的程序员编程交流平台!开放,进步,分享!让技术改变生活,让极客改变未来! Welcome to OGeek Q&A Community for programmer and developer-Open, Learning and Share
Click Here to Ask a Question

...