Quand utiliser GraphQLID au lieu de GraphQLInt ?

Question

Il n'est pas clair quand utiliser GraphQLID au lieu de GraphQLInt .

Considérons le schéma suivant :

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

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

En cas de Query.user il semble qu'il n'y ait pas de différence entre l'utilisation de GraphQLID ou GraphQLInt .

En cas de User.id en utilisant GraphQLID transformera l'entrée en chaîne de caractères. Utilisation de GraphQLInt s'assurera que l'entrée est un nombre entier.

Cela rend la requête et le système de type incohérents.

El graphql-js spec dit simplement :

A GraphQLScalarType qui représente un ID.

S'agit-il d'un détail d'implémentation (par exemple, le client GraphQL doit-il lancer un programme d'enregistrement ? GraphQLID à un nombre entier quand il le peut), ou est-ce que l'on s'attend à ce que ID est toujours une chaîne de caractères dans graphql ?

Answer 1

J'ai jeté un coup d'œil à la spécification GraphQL.

Le type scalaire ID représente un identifiant unique, souvent utilisé pour récupérer un objet ou comme clé pour un cache. Le type ID est sérialisé de la même manière qu'un élément de type String Cependant, il n'est pas destiné à être lisible par l'homme. Bien qu'il soit souvent numérique, il doit toujours être sérialisé sous la forme d'un fichier de type String .

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

Cela répond à la question de savoir si cela est laissé à l'implémentation ou dicté par la spécification, c'est-à-dire que l'ID devrait toujours être sérialisé dans un fichier de type String .

En outre, dans le contexte d'un type d'entrée, l'entrée doit être convertie en une chaîne de caractères. Extrait de la spécification :

Coercition des entrées

Lorsqu'elle est attendue comme type d'entrée, toute chaîne de caractères (telle que "4" ) ou un nombre entier (tel que 4 ) doit être convertie en ID en fonction des formats d'ID attendus par un serveur GraphQL donné. Toute autre valeur d'entrée, y compris les valeurs flottantes (telles que 4.0 ), doit soulever une erreur de requête indiquant un type incorrect.

Ce qui me laisse avec le problème initial.

J'ai un mysql backend où mes PK sont des entiers.

De la façon dont je le vois, j'ai ces options :

• Commencez à utiliser les UUIDs pour les PKs. Cependant, cela a répercussions sur la performance .
• Ne pas tenir compte de l'exigence implicite (provenant des relayjs écosystème) pour que l'ID soit unique dans l'ensemble de l'application, et convertissez les ID en numéros lorsque cela est possible pour la consommation interne.
• Hash Coder les ID sur la couche de données de l'application, par ex. UUID base64 dérivé d'une concaténation du nom de la table et de la valeur PK.

J'opte pour cette dernière option. C'est également l'approche que graphql-relay-js a adopté via toGlobalId y fromGlobalId .