Versionamento basato su campi/direttive
I campi e le direttive possono essere versionati in modo indipendente, e la versione da usare può essere specificata nella query tramite l'argomento di campo/direttiva versionConstraint.
Per selezionare la versione del campo/direttiva, Gato GraphQL utilizza gli stessi vincoli di versione semver impiegati da Composer.
Perché
La strategia di evoluzione adottata da GraphQL presenta un problema: quando si deprecata un campo (per sostituirlo con una nuova implementazione), il nuovo campo dovrà avere un nuovo nome. Quindi, se il campo deprecato non può essere rimosso (ad esempio, perché alcuni client vi accedono ancora, da query che non sono mai state revisionate), tutti questi campi per una stessa funzionalità tendono ad accumularsi nello schema, e la nuova implementazione del campo non avrà un nome ottimale (anzi, sarà peggiore del nome del campo deprecato).
L'evoluzione da sola, nel tempo, tende a inquinare lo schema con definizioni indesiderate. Versionare lo schema su base campi/direttive può risolvere questo problema.
Versionamento mirato tramite la query
Passa il vincolo al campo o alla direttiva, tramite l'argomento 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")
}
}