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
}

dans le cas de Query.user , il ne semble pas faire de différence si d'utiliser GraphQLID ou GraphQLInt .

dans le cas de User.id , en utilisant GraphQLID va lancer l'entrée à la chaîne. Utiliser GraphQLInt l'entrée est un nombre entier.

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

Le spec dit simplement:

Un GraphQLScalarType qui représente un ID.

est-ce un détail de mise en œuvre (par exemple, le client GraphQL devrait-il lancer GraphQLID vers un entier quand il le peut), ou est-il prévu que ID est toujours une chaîne dans ?

20
demandé sur Gajus 2016-09-13 16:15:13

1 réponses

j'ai regardé la spécification GraphQL.

le type ID scalar représente un identifiant unique, souvent utilisé pour reconfigurer un objet ou comme clé pour un cache. Le type D'identification est sérialisé de la même manière qu'un String ; toutefois, il n'est pas destiné à être lisible par les humains. Bien qu'il soit souvent numérique, il devrait toujours sérialiser comme un String .

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

qui répond à la question de savoir si elle est laissée à la mise en œuvre ou dictée par le spec, i.e. ID doit toujours être sérialisé en 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. Du spec:

"1519260920 D'Entrée" Coercition

Lorsqu'on s'attend à ce qu'il s'agisse d'un type d'entrée, toute chaîne (telle que "4" ) ou la valeur d'entrée (telle que 4 ) doit être forcée à ID comme approprié pour les formats D'ID qu'un serveur GraphQL donné attend. Toute autre valeur d'entrée, y compris les valeurs d'entrée float (comme 4.0 ), doit soulever une erreur de requête indiquant un type incorrect.

ça me laisse avec le problème original.

j'ai un backend où mon PK sont entiers.

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

  • Commencer à utiliser des Uuid pour PKs. Toutefois, ceci a performance implications .
  • Ignore l'exigence implicite (provenant du écosystème) d'avoir L'ID unique à travers l'application, et de cast IDs à numéroter lorsque possible pour la consommation interne.
  • Hash Encode IDs 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.

j'utilise cette dernière option. C'est aussi l'approche que graphql-relay-js a adopté via toGlobalId et fromGlobalId .

19
répondu Gajus 2016-09-13 14:58:03