🎉 Gato GraphQL v0.7 veröffentlicht, mit Unterstützung für Mutations und Nested Mutations!

Version 0.7 von Gato GraphQL, mit Unterstützung für Mutations und Nested Mutations, wurde veröffentlicht! 🎉

Hier ist ein Überblick über die Neuerungen.

​

1. Mutations! 🚀

GraphQL Mutations ermöglichen es, Daten zu verändern (d.h. Seiteneffekte auszuführen) über die query.

Mutations waren das große fehlende Element in Gato GraphQL. Jetzt, wo sie hinzugefügt wurden, kann ich behaupten, dass dieser GraphQL-Server funktional nahezu vollständig ist (nur Subscriptions fehlen noch, und ich denke bereits darüber nach, wie ich sie hinzufügen kann).

Schauen wir uns ein Beispiel zum Hinzufügen eines Kommentars an. Aber zuerst müssen wir eine weitere Mutation ausführen, um dich einzuloggen, damit du Kommentare hinzufügen kannst. Drücke den „Run"-Button im GraphiQL-Client unten, um das Mutations-Feld loginUser mit einem vorab erstellten Testbenutzer auszuführen:

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

Jetzt fügen wir einige Kommentare hinzu. Drücke den Run-Button unten, um einem Beitrag einen Kommentar hinzuzufügen, indem du das Mutations-Feld addCommentToCustomPost ausführst (du kannst auch den Kommentartext bearbeiten):

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

In dieser ersten Version wird das Plugin mit den folgenden Mutations ausgeliefert:

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

​

2. Nested Mutations! 🚀🚀

Nested Mutations sind die Fähigkeit, Mutations auf einem anderen Typ als dem Root-Typ in GraphQL auszuführen.

Sie wurden für die GraphQL-Spezifikation beantragt, aber noch nicht genehmigt (und werden es vielleicht auch nie), daher fügt Gato GraphQL die Unterstützung dafür als Opt-in-Funktion hinzu, über das Modul Nested Mutations.

Daher unterstützt das Plugin 2 Verhaltensweisen:

1. Das standardmäßige GraphQL-Verhalten (d.h. das Hinzufügen von Mutations-Feldern zum Root-Typ), standardmäßig aktiviert
2. Nested Mutations als Opt-in

Zum Beispiel kann die obige query auch mit der folgenden query ausgeführt werden, bei der wir zuerst den Beitrag über Root.post abrufen und erst danach über Post.addComment einen Kommentar hinzufügen:

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

Mutations können auch Daten aus dem Ergebnis einer anderen Mutation verändern. In der folgenden query erhalten wir zuerst den Beitrag über Root.post, dann führen wir die Mutation Post.addComment darauf aus und erhalten das erstellte Kommentar-Objekt, und schließlich führen wir die Mutation Comment.reply darauf aus:

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

Das ist wirklich nützlich! 😍 (Die alternative Methode, um dasselbe Verhalten in einer einzigen query zu erzeugen, ist die @export-Direktive... Ich werde beide in einem kommenden Blogbeitrag vergleichen).

In dieser ersten Version wird das Plugin mit den folgenden Mutations ausgeliefert:

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

​

Standard oder nested? Oder beides?

Du hast vielleicht eine GraphQL-API, die von deiner eigenen Anwendung genutzt wird und auch öffentlich für deine Kunden verfügbar ist. Möglicherweise möchtest du Nested Mutations nur für deine eigene Anwendung aktivieren, nicht für deine Kunden, da es sich um eine nicht-standardmäßige Funktion handelt.

Gute Nachrichten: Das ist möglich.

Ich habe einen Abschnitt „Mutation Scheme" in der Schema Configuration hinzugefügt, der verwendet wird, um das Schema für Custom Endpoints und Persisted Queries anzupassen:

Du kannst also Nested Mutations überall deaktivieren, sie aber nur für einen bestimmten Custom Endpoint aktivieren, den nur deine Anwendung verwenden wird. 💪

​

Redundante Felder aus dem Root-Typ entfernen

Mit Nested Mutations können Mutations-Felder dem Schema zweimal hinzugefügt werden:

• einmal unter dem Root-Typ
• einmal unter dem spezifischen Typ

Zum Beispiel können diese Felder als „Duplikate" voneinander betrachtet werden:

• Root.updatePost
• Post.update

Gato GraphQL ermöglicht es, beide beizubehalten oder die redundanten aus dem Root-Typ zu entfernen.

Die folgenden 3 Schemas:

1. Standardverhalten:
   verwendet die Typen QueryRoot für queries und MutationRoot für Mutations
2. Nested Mutations mit beibehaltenen doppelten Mutations-Feldern:
   ein einziger Typ Root verwaltet queries und Mutations, und redundante Mutations-Felder in diesem Typ werden beibehalten
3. Nested Mutations mit Entfernung redundanter Mutations-Felder aus dem Root-Typ:
   wie oben, aber alle redundanten Mutations-Felder werden aus dem Typ Root entfernt

✱ Übrigens1: Diese 3 Schemas verwenden alle denselben Endpoint, ändern aber einen URL-Parameter ?mutation_scheme auf die Werte standard, nested und lean_nested. Das ist möglich, weil der GraphQL-Server dem Code-First-Ansatz folgt. 🤟

✱ Übrigens2: Diese Optionen können im Abschnitt „Mutation Scheme" der Schema Configuration (oben gezeigt) ausgewählt werden, sodass du auch entscheiden kannst, welches Verhalten für einzelne Custom Endpoints und Persisted Queries gilt. 👏

Jetzt ist es Zeit, mit der Vorbereitung für v0.8 zu beginnen! 🙏