🎉 Gato GraphQL v0.7 uitgebracht, met ondersteuning voor mutations en nested mutations!

Versie 0.7 van Gato GraphQL, met ondersteuning voor mutations en nested mutations, is uitgebracht! 🎉

Hier is een rondleiding die de nieuwe toevoegingen laat zien.

​

1. Mutations! 🚀

GraphQL mutations maken het mogelijk om gegevens te wijzigen (d.w.z. neveneffecten uit te voeren) via de query.

Mutations was het grote onderdeel dat nog ontbrak in Gato GraphQL. Nu het is toegevoegd, kan ik zeggen dat deze GraphQL-server zo goed als compleet is qua functies (alleen subscriptions ontbreken nog, en ik denk al na over hoe ik die kan toevoegen).

Laten we een voorbeeld bekijken van het toevoegen van een reactie. Maar eerst moeten we een andere mutation uitvoeren om je in te loggen, zodat je reacties kunt toevoegen. Druk op de knop "Run" in de GraphiQL-client hieronder om het mutation-veld loginUser uit te voeren met een vooraf aangemaakt testgebruiker:

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

Laten we nu wat reacties toevoegen. Druk op de Run-knop hieronder om een reactie aan een bericht toe te voegen door het mutation-veld addCommentToCustomPost uit te voeren (je kunt ook de reactietekst bewerken):

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

In deze eerste release wordt de plugin geleverd met de volgende mutations:

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

​

2. Nested Mutations! 🚀🚀

Nested mutations is de mogelijkheid om mutations uit te voeren op een ander type dan het root type in GraphQL.

Ze zijn aangevraagd voor de GraphQL-specificatie maar nog niet goedgekeurd (en dat zal misschien nooit gebeuren), daarom voegt Gato GraphQL er ondersteuning voor toe als een opt-in functie, via de module Nested Mutations.

De plugin ondersteunt dan ook 2 gedragingen:

1. Het standaard GraphQL-gedrag (d.w.z. mutation-velden toevoegen aan het root type), standaard ingeschakeld
2. Nested mutations, als opt-in

Zo kan de bovenstaande query ook worden uitgevoerd met de volgende query, waarbij we eerst het bericht ophalen via Root.post en er daarna pas een reactie aan toevoegen 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

Mutations kunnen ook gegevens wijzigen op het resultaat van een andere mutation. In de onderstaande query halen we eerst het bericht op via Root.post, voeren dan mutation Post.addComment erop uit en krijgen het aangemaakte reactie-object, en voeren tot slot mutation Comment.reply erop uit:

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

Dit is zeker handig! 😍 (De alternatieve methode om hetzelfde gedrag te bereiken, in één query, is via de @export-directive... Ik vergelijk ze allebei in een komend blogbericht).

In deze eerste release wordt de plugin geleverd met de volgende mutations:

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

​

Standaard of nested? Of allebei?

Je hebt misschien een GraphQL API die door je eigen applicatie wordt gebruikt en ook publiek beschikbaar is voor je klanten. Je wilt nested mutations misschien alleen inschakelen voor je eigen applicatie, niet voor je klanten, omdat dit een niet-standaard functie is.

Goed nieuws: dat kan.

Ik heb een sectie "Mutation Scheme" toegevoegd in de Schema Configuration, die wordt gebruikt om het schema aan te passen voor Custom Endpoints en Persisted Queries:

Je kunt nested mutations dus overal uitschakelen, maar ze inschakelen voor alleen een specifiek custom endpoint dat uitsluitend jouw applicatie zal gebruiken. 💪

​

Overbodige velden uit het root type verwijderen

Met nested mutations kunnen mutation-velden twee keer aan het schema worden toegevoegd:

• eenmaal onder het root type
• eenmaal onder het specifieke type

Zo kunnen deze velden als elkaars "duplicaat" worden beschouwd:

• Root.updatePost
• Post.update

Gato GraphQL maakt het mogelijk om beide te behouden, of de velden uit het root type te verwijderen, die overbodig zijn.

De volgende 3 schema's:

1. Standaardgedrag:
   het gebruikt typen QueryRoot voor queries en MutationRoot voor mutations
2. Nested mutations met behoud van dubbele mutation-velden:
   een enkel Root type verwerkt queries en mutations, en overbodige mutation-velden in dit type worden bewaard
3. Nested mutations met verwijdering van overbodige mutation-velden uit het root type:
   hetzelfde als hierboven, maar alle overbodige mutation-velden worden uit het Root type verwijderd

✱ Overigens1, deze 3 schema's gebruiken allemaal hetzelfde endpoint, maar veranderen een URL-parameter ?mutation_scheme naar de waarden standard, nested en lean_nested. Dat is mogelijk omdat de GraphQL-server de code-first aanpak volgt. 🤟

✱ Overigens2, deze opties kunnen worden geselecteerd in de sectie "Mutation Scheme" in de Schema configuration (hierboven weergegeven), zodat je ook kunt bepalen welk gedrag je wilt toepassen voor individuele custom endpoints en persisted queries. 👏

Nu is het tijd om te beginnen met de voorbereiding voor v0.8! 🙏