nodejs - ¿Cuándo usar GraphQLID en lugar de GraphQLInt?

graphql nodejs

Question

No está claro cuándo usar GraphQLID lugar de GraphQLInt .

Considere el siguiente esquema:

type User {
id: Int!
firstName: String!
lastName: String!
}
type Query {
user (id: ID!): User
}

En el caso de Query.user , parece que no hay diferencia si usar GraphQLID o GraphQLInt .

En el caso de User.id , el uso de GraphQLID emitirá la entrada a la cadena. El uso de GraphQLInt asegurará que la entrada sea un número entero.

Esto hace que la consulta y el sistema de tipos sean inconsistentes.

La graphql-js simplemente dice:

Un GraphQLScalarType que representa una ID.

¿Es este un detalle de implementación (por ejemplo, si el cliente GraphQL debería convertir GraphQLID en un entero cuando pueda) o se espera que ID sea ​​siempre una cadena en graphql ?

Answer 1

Eché un vistazo a la especificación GraphQL.

El tipo escalar de ID representa un identificador único, que a menudo se usa para recuperar un objeto o como la clave para un caché. El tipo de ID se serializa de la misma manera que una String ; sin embargo, no pretende ser legible por humanos. Si bien a menudo es numérico, siempre se debe serializar como una String .

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

Eso responde a la pregunta de si se deja a la implementación o está dictada por la especificación, es decir, la ID debe ser siempre serializada a una String .

Además, en el contexto de un tipo de entrada, la entrada se debe convertir en una cadena. De la especificación:

Entrada Coercion

Cuando se espera que sea un tipo de entrada, cualquier cadena (como "4" ) o un valor de entrada entero (como 4 ) debe ser forzado a la ID según corresponda para los formatos de ID que un servidor GraphQL determinado espera. Cualquier otro valor de entrada, incluidos los valores de entrada flotantes (como 4.0 ), debe generar un error de consulta que indique un tipo incorrecto.

Eso me deja con el problema original.

Tengo un backend mysql donde mis PK son enteros.

A mi modo de ver, tengo estas opciones:

• Comience a usar UUIDs para PKs. Sin embargo, esto tiene implicaciones de rendimiento .
• Ignore el requisito implícito (que se origina en el ecosistema de relayjs ) para tener la ID única en toda la aplicación, y convierta las ID en números cuando sea posible para el consumo interno.
• Hash Encode los ID en la capa de datos de la aplicación, por ejemplo, UUID base64 derivado de una concatenación de nombre de tabla y valor de PK.

Voy con la última opción. Este es también el enfoque que graphql-relay-js ha adoptado a través de toGlobalId y toGlobalId .