🎉 Lancement de Gato GraphQL v0.7, avec support des mutations et nested mutations !

La version 0.7 de Gato GraphQL, avec support des mutations et des nested mutations, a été lancée ! 🎉

Voici un tour d'horizon des nouveautés.

​

1. Mutations ! 🚀

Les mutations GraphQL permettent de modifier des données (c'est-à-dire d'effectuer des effets de bord) via la requête.

Les mutations étaient le grand élément encore manquant dans Gato GraphQL. Maintenant qu'elles ont été ajoutées, je peux affirmer que ce serveur GraphQL est pratiquement complet en termes de fonctionnalités (seules les subscriptions manquent, et je réfléchis déjà à la façon de les ajouter).

Voyons un exemple en ajoutant un commentaire. Mais d'abord, nous devons exécuter une autre mutation pour vous connecter, afin que vous puissiez ajouter des commentaires. Appuyez sur le bouton "Run" dans le client GraphiQL ci-dessous, pour exécuter le champ mutation loginUser avec un utilisateur de test pré-créé :

mutation LogUserIn {
  loginUser(
    by: { credentials: { usernameOrEmail: "test", password: "pass" } }
  ) {
    id
    name
  }
}Copy

Maintenant, ajoutons quelques commentaires. Appuyez sur le bouton Run ci-dessous, pour ajouter un commentaire à une publication en exécutant le champ mutation addCommentToCustomPost (vous pouvez également modifier le texte du commentaire) :

mutation AddComment {
  addCommentToCustomPost(
    input: { customPostID: 1459, comment: "Adding a comment: bla bla bla" }
  ) {
    id
    content
    date
  }
}Copy

Dans cette première version, le plugin est livré avec les mutations suivantes :

✅ createPost
✅ updatePost
✅ setFeaturedImageforCustomPost
✅ removeFeaturedImageforCustomPost
✅ addCommentToCustomPost
✅ replyComment
✅ loginUser
✅ logoutUser

​

2. Nested Mutations ! 🚀🚀

Les nested mutations sont la capacité d'effectuer des mutations sur un type autre que le root type dans GraphQL.

Elles ont été demandées pour la spécification GraphQL mais pas encore approuvées (et ne le seront peut-être jamais), donc Gato GraphQL ajoute leur support en tant que fonctionnalité opt-in, via le module Nested Mutations.

Ainsi, le plugin supporte les 2 comportements :

1. Le comportement GraphQL standard (c'est-à-dire l'ajout de champs mutation au root type), par défaut
2. Les nested mutations, en tant qu'opt-in

Par exemple, la requête ci-dessus peut également être exécutée avec la requête suivante, dans laquelle nous récupérons d'abord la publication via Root.post, puis lui ajoutons un commentaire via Post.addComment :

mutation AddComment {
  post(by: { id: 1459 }) {
    addComment(
      input: {
        comment: "Notice how field `addCommentToCustomPost` under the `Root` type is renamed as `addComment` under the `Post` type? The schema got neater!"
      }
    ) {
      id
      content
      date
    }
  }
}Copy

Les mutations peuvent également modifier des données sur le résultat d'une autre mutation. Dans la requête ci-dessous, nous obtenons d'abord la publication via Root.post, puis exécutons la mutation Post.addComment sur elle et obtenons l'objet commentaire créé, et enfin exécutons la mutation Comment.reply sur lui :

mutation AddCommentAndResponse {
  post(by: { id: 1459 }) {
    id
    title
    addComment(input: { comment: "Isn't this awesome?" }) {
      id
      date
      content
      reply(input: { comment: "I think so!" }) {
        id
        date
        content
      }
    }
  }
}Copy

C'est vraiment utile ! 😍 (La méthode alternative pour produire ce même comportement, en une seule requête, est via la directive @export... Je comparerai les deux dans un prochain article de blog).

Dans cette première version, le plugin est livré avec les mutations suivantes :

✅ CustomPost.update
✅ CustomPost.setFeaturedImage
✅ CustomPost.removeFeaturedImage
✅ CustomPost.addComment
✅ Comment.reply

​

Standard ou nested ? Ou les deux ?

Vous pouvez avoir une API GraphQL utilisée par votre propre application, et également disponible publiquement pour vos clients. Vous pouvez vouloir activer les nested mutations uniquement pour votre propre application, pas pour vos clients car il s'agit d'une fonctionnalité non standard.

Bonne nouvelle : c'est possible.

J'ai ajouté une section "Mutation Scheme" dans la Schema Configuration, qui est utilisée pour personnaliser le schéma pour les Custom Endpoints et les Persisted Queries :

Ainsi, vous pouvez désactiver les nested mutations partout, mais les activer uniquement pour un custom endpoint spécifique que seule votre application utilisera. 💪

​

Suppression des champs redondants du root type

Avec les nested mutations, les champs mutation peuvent être ajoutés deux fois au schéma :

• une fois sous le root type
• une fois sous le type spécifique

Par exemple, ces champs peuvent être considérés comme des "doublons" l'un de l'autre :

• Root.updatePost
• Post.update

Gato GraphQL permet de conserver les deux, ou de supprimer ceux du root type, qui sont redondants.

Les 3 schémas suivants :

1. Comportement standard :
   il utilise les types QueryRoot pour gérer les requêtes et MutationRoot pour gérer les mutations
2. Nested mutations en conservant les champs mutation en double :
   un seul type Root gère les requêtes et les mutations, et les champs mutation redondants dans ce type sont conservés
3. Nested mutations en supprimant les champs mutation redondants du root type :
   identique au précédent, mais en supprimant tous les champs mutation redondants du type Root

✱ BTW1, ces 3 schémas utilisent tous le même endpoint, mais en changeant un paramètre URL ?mutation_scheme vers les valeurs standard, nested et lean_nested. C'est possible parce que le serveur GraphQL suit l'approche code-first. 🤟

✱ BTW2, ces options peuvent être sélectionnées dans la section "Mutation Scheme" dans la Schema configuration (montrée ci-dessus), donc vous pouvez également décider quel comportement appliquer pour des custom endpoints et persisted queries individuels. 👏

Il est maintenant temps de commencer à préparer la v0.8 ! 🙏