Versionado basado en campos/directivas
Los campos y las directivas pueden versionarse de forma independiente, y la versión a utilizar puede especificarse en la consulta mediante el argumento de campo/directiva versionConstraint.
Para seleccionar la versión del campo/directiva, Gato GraphQL utiliza las mismas restricciones de versión semver empleadas por Composer.
Por qué
La estrategia de evolución adoptada por GraphQL tiene un problema: al deprecar un campo (para reemplazarlo con una nueva implementación), el nuevo campo necesitará tener un nuevo nombre. Entonces, si el campo deprecado no puede eliminarse (por ejemplo, porque algunos clientes siguen accediendo a él desde consultas que nunca fueron revisadas), todos estos campos para una misma funcionalidad tienden a acumularse en el esquema, y la nueva implementación del campo no tendrá un nombre óptimo (de hecho, será peor que el nombre del campo deprecado).
La evolución por sí sola, con el tiempo, tiende a contaminar el esquema con definiciones no deseadas. Versionar el esquema sobre la base de campos/directivas puede resolver este problema.
Versionado dirigido a través de la consulta
Pasa la restricción al campo o directiva mediante el argumento 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")
}
}