Feld/Direktiven-basiertes Versioning

Felder und Direktiven können unabhängig voneinander versioniert werden, und die zu verwendende Version kann in der Query über das Feld/Direktiven-Argument versionConstraint angegeben werden.

Um die Version des Feldes/der Direktive auszuwählen, verwendet Gato GraphQL dieselben Semver-Versionsconstraints wie Composer.

​

Warum

Die von GraphQL übernommene Evolutionsstrategie hat ein Problem: Wenn ein Feld als veraltet markiert wird (um es durch eine neuere Implementierung zu ersetzen), muss das neue Feld einen neuen Namen erhalten. Wenn das veraltete Feld dann nicht entfernt werden kann (beispielsweise weil einige Clients noch darauf zugreifen, aus Queries, die nie überarbeitet wurden), neigen all diese Felder für eine gleiche Funktionalität dazu, sich im Schema anzuhäufen, und die neue Implementierung des Feldes wird keinen optimalen Namen haben (tatsächlich wird er schlechter sein als der Name des veralteten Feldes).

Evolution allein neigt dazu, das Schema im Laufe der Zeit mit unerwünschten Definitionen zu überladen. Das Versionieren des Schemas auf Feld/Direktiven-Basis kann dieses Problem lösen.

​

Gezieltes Versioning über die Query

Übergib die Constraint an das Feld oder die Direktive, über das 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