Gestion des directives de type schéma
Gato GraphQL est un serveur code-first, c'est-à-dire qu'il utilise du code pour développer le schéma. (L'alternative est l'approche SDL-first, qui utilise le Schema Definition Language pour produire d'abord le schéma puis développer le service).
Comme il ne dispose pas de SDL, les serveurs code-first ne peuvent pas prendre en charge naturellement les directives de type schéma. Afin d'éviter cette limitation, Gato GraphQL a développé le mécanisme suivant :
- Transformer la requête de demandée à exécutable
- Appliquer les règles IFTTT à la requête exécutable
Il en résulte une prise en charge complète des directives de type schéma sur le serveur GraphQL.
Pourquoi cela fonctionne-t-il ?
@deprecated est une directive de type schéma, elle doit donc être appliquée sur le schéma. Cependant, que se passerait-il si nous prétendions un instant qu'il s'agit d'une directive de type requête, et que nous ajoutions @deprecated sur un certain champ directement dans la requête ?
Par exemple, lors de l'exécution de cette requête :
query {
posts {
id
title
content @deprecated(reason: "Use newContent instead")
}
}Eh bien, cela pourrait fonctionner aussi ! Parce qu'après tout, une directive n'est qu'une fonctionnalité à exécuter sur le champ ; déclarer cette fonctionnalité via le schéma, ou directement dans la requête, ne fait pas se comporter la fonctionnalité différemment.
Certes, même si cela fonctionne, cela n'a aucun sens. Nous ne pouvons pas forcer nos clients à ajouter @deprecated à leurs requêtes. Il s'agit d'une fonctionnalité décidée par l'application côté serveur, pas côté client.
Cependant, la fonctionnalité elle-même fonctionne toujours. Par conséquent, que la directive soit ajoutée au schéma ou à la requête n'a pas d'importance d'un point de vue fonctionnel. De plus, toute directive finira par être présente dans la requête, puisque c'est là qu'elle est exécutée.
Ainsi, si le serveur ne dispose pas de SDL, il peut tout de même intégrer la directive dans la requête, à l'exécution.