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 graphql-js 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 graphql?

回答1:

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 mysql 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 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.

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