Versionnage basé sur les champs/directives

Les champs et les directives peuvent être versionnés indépendamment, et la version à utiliser peut être spécifiée dans la requête via l'argument de champ/directive versionConstraint.

Pour sélectionner la version du champ/directive, Gato GraphQL utilise les mêmes contraintes de version semver employées par Composer.

​

Pourquoi

La stratégie d'évolution adoptée par GraphQL pose un problème : lors de la dépréciation d'un champ (pour le remplacer par une nouvelle implémentation), le nouveau champ devra avoir un nouveau nom. Alors, si le champ déprécié ne peut pas être supprimé (par exemple, parce que certains clients y accèdent encore, depuis des requêtes qui n'ont jamais été révisées), tous ces champs pour une même fonctionnalité ont tendance à s'accumuler dans le schéma, et la nouvelle implémentation du champ n'aura pas un nom optimal (en effet, il sera moins bon que le nom du champ déprécié).

L'évolution seule, avec le temps, tend à polluer le schéma avec des définitions indésirables. Versionner le schéma sur la base des champs/directives peut résoudre ce problème.

​

Versionnage ciblé via la requête

Passez la contrainte au champ ou à la directive, via l'argument versionConstraint :

# Selecting version for fields
query {
  #This will produce version 0.1.0
  firstVersion: userServiceURLs(versionConstraint: "^0.1")
  # This will produce version 0.2.0
  secondVersion: userServiceURLs(versionConstraint: ">0.1")
  # This will produce version 0.2.0
  thirdVersion: userServiceURLs(versionConstraint: "^0.2")
}
 
# Selecting version for directives
query {
  post(by: { id:1 }) {
    titleCase: title @makeTitle(versionConstraint: "^0.1")
    upperCase: title @makeTitle(versionConstraint: "^0.2")
  }
}Copy