🎉 Rilasciato Gato GraphQL v0.7, con supporto per le mutations e le nested mutations!

La versione 0.7 di Gato GraphQL, con supporto per le mutations e le nested mutations, è stata rilasciata! 🎉

Ecco una panoramica delle novità.

​

1. Mutations! 🚀

Le mutations GraphQL permettono di modificare i dati (cioè di produrre effetti collaterali) tramite la query.

Le mutations erano il grande elemento ancora mancante in Gato GraphQL. Ora che sono state aggiunte, posso affermare che questo server GraphQL è praticamente completo in termini di funzionalità (mancano solo le subscriptions, e sto già pensando a come aggiungerle).

Vediamo un esempio aggiungendo un commento. Ma prima, dobbiamo eseguire un'altra mutation per effettuare il login, in modo che tu possa aggiungere commenti. Premi il pulsante "Run" nel client GraphiQL qui sotto, per eseguire il campo mutation loginUser con un utente di test pre-creato:

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

Ora, aggiungiamo qualche commento. Premi il pulsante Run qui sotto, per aggiungere un commento a un post eseguendo il campo mutation addCommentToCustomPost (puoi anche modificare il testo del commento):

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

In questa prima versione, il plugin è fornito con le seguenti mutations:

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

​

2. Nested Mutations! 🚀🚀

Le nested mutations sono la capacità di eseguire mutations su un tipo diverso dal root type in GraphQL.

Sono state richieste per la specifica GraphQL ma non ancora approvate (e forse non lo saranno mai), quindi Gato GraphQL ne aggiunge il supporto come funzionalità opt-in, tramite il modulo Nested Mutations.

Pertanto, il plugin supporta i 2 comportamenti:

1. Il comportamento GraphQL standard (cioè l'aggiunta di campi mutation al root type), di default
2. Le nested mutations, come opt-in

Per esempio, la query precedente può anche essere eseguita con la query seguente, in cui prima recuperiamo il post tramite Root.post, e solo dopo gli aggiungiamo un commento tramite 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

Le mutations possono anche modificare i dati sul risultato di un'altra mutation. Nella query qui sotto, otteniamo prima il post tramite Root.post, poi eseguiamo la mutation Post.addComment su di esso e otteniamo l'oggetto commento creato, e infine eseguiamo la mutation Comment.reply su di esso:

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

Questo è davvero utile! 😍 (Il metodo alternativo per produrre lo stesso comportamento, in un'unica query, è tramite la direttiva @export... Li confronterò entrambi in un prossimo articolo del blog).

In questa prima versione, il plugin è fornito con le seguenti mutations:

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

​

Standard o nested? O entrambi?

Potresti avere un'API GraphQL utilizzata dalla tua applicazione, e disponibile pubblicamente anche per i tuoi clienti. Potresti voler abilitare le nested mutations solo per la tua applicazione, non per i tuoi clienti, perché si tratta di una funzionalità non standard.

Buone notizie: è possibile.

Ho aggiunto una sezione "Mutation Scheme" nella Schema Configuration, che viene utilizzata per personalizzare lo schema per i Custom Endpoints e le Persisted Queries:

Pertanto, puoi disabilitare le nested mutations ovunque, ma abilitarle solo per uno specifico custom endpoint che userà solo la tua applicazione. 💪

​

Rimozione dei campi ridondanti dal root type

Con le nested mutations, i campi mutation possono essere aggiunti due volte allo schema:

• una volta sotto il root type
• una volta sotto il tipo specifico

Per esempio, questi campi possono essere considerati "duplicati" l'uno dell'altro:

• Root.updatePost
• Post.update

Gato GraphQL permette di mantenerli entrambi, oppure di rimuovere quelli del root type, che sono ridondanti.

I 3 schemi seguenti:

1. Comportamento standard:
   usa i tipi QueryRoot per gestire le query e MutationRoot per gestire le mutations
2. Nested mutations mantenendo i campi mutation duplicati:
   un unico tipo Root gestisce le query e le mutations, e i campi mutation ridondanti in questo tipo vengono mantenuti
3. Nested mutations rimuovendo i campi mutation ridondanti dal root type:
   come sopra, ma rimuovendo tutti i campi mutation ridondanti dal tipo Root

✱ A proposito1, questi 3 schemi usano tutti lo stesso endpoint, ma cambiando un parametro URL ?mutation_scheme con i valori standard, nested e lean_nested. Questo è possibile perché il server GraphQL segue l'approccio code-first. 🤟

✱ A proposito2, queste opzioni possono essere selezionate nella sezione "Mutation Scheme" della Schema configuration (mostrata sopra), quindi puoi anche decidere quale comportamento applicare per singoli custom endpoint e persisted queries. 👏

Ora è il momento di iniziare a prepararsi per la v0.8! 🙏