web-dev-qa-db-fra.com

Quand utiliser GraphQLID au lieu de GraphQLInt?

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

Considérez le schéma suivant:

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

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

En cas de Query.user, il ne semble pas y avoir de différence d'utiliser GraphQLID ou GraphQLInt.

En cas de User.id, en utilisant GraphQLID convertira l'entrée en chaîne. L'utilisation de GraphQLInt garantira que l'entrée est un entier.

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

graphql-jsspec dit simplement:

Un GraphQLScalarType qui représente un ID.

S'agit-il d'un détail d'implémentation (par exemple, le client GraphQL doit-il convertir GraphQLID en un entier quand il le peut), ou est-il prévu que ID soit toujours une chaîne dans graphql ?

graphqlgraphql-js
31
Gajus

J'ai jeté un œ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 d'ID est sérialisé de la même manière qu'un 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é en String.

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

Cela répond à la question de savoir si elle est laissée à l'implémentation ou dictée par la spécification, c'est-à-dire que l'ID doit toujours être sérialisé en String.

De plus, dans le contexte d'un type d'entrée, l'entrée doit être contrainte dans une chaîne. De la spécification:

Contrainte d'entrée

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

Cela me laisse avec le problème d'origine.

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

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

  • Commencez à utiliser les UUID pour les PK. Cependant, cela a implications en termes de performances .
  • Ignorez l'exigence implicite (provenant de l'écosystème relayjs ) d'avoir l'ID unique dans l'application, et transtypez les ID en nombre lorsque cela est possible pour la consommation interne.
  • Hacher Coder les ID sur la couche de données d'application, par exemple UUID base64 dérivé d'une concaténation du nom de la table et de la valeur PK.

Je vais avec cette dernière option. C'est également l'approche qui graphql-relay-js a adopté via toGlobalId et fromGlobalId .

27
Gajus