Veld/directive-gebaseerde versiebeheer

Velden en directives kunnen onafhankelijk van elkaar worden geversioneerd, en de te gebruiken versie kan in de query worden opgegeven via het veld/directive-argument versionConstraint.

Om de versie voor het veld/de directive te selecteren, gebruikt Gato GraphQL dezelfde semver-versiebeperkingen die door Composer worden gebruikt.

​

Waarom

De evolutiestrategie die door GraphQL wordt gehanteerd heeft een probleem: bij het depreceren van een veld (om het te vervangen door een nieuwere implementatie), moet het nieuwe veld een nieuwe veldnaam krijgen. Als het gedepreceerde veld niet verwijderd kan worden (bijvoorbeeld omdat sommige clients het nog steeds gebruiken, via queries die nooit zijn bijgewerkt), dan hebben al deze velden voor dezelfde functionaliteit de neiging zich in het schema op te stapelen, en de nieuwe implementatie van het veld krijgt geen optimale naam (het zal zelfs slechter zijn dan de naam van het gedepreceerde veld).

Evolutie alleen heeft er, na verloop van tijd, de neiging toe het schema te vervuilen met ongewenste definities. Versiebeheer van het schema op veld/directive-niveau kan dit probleem oplossen.

​

Gerichte versiebeheer via de query

Geef de beperking door aan het veld of de directive via het 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