🎉 Wydano Gato GraphQL v0.7, z obsługą mutations i nested mutations!

Wersja 0.7 Gato GraphQL, z obsługą mutations i nested mutations, została wydana! 🎉

Oto przegląd nowości.

​

1. Mutations! 🚀

Mutations GraphQL umożliwiają modyfikowanie danych (tj. wykonywanie efektów ubocznych) poprzez query.

Mutations były głównym elementem wciąż brakującym w Gato GraphQL. Teraz, gdy zostały dodane, mogę stwierdzić, że ten serwer GraphQL jest praktycznie kompletny pod względem funkcji (brakuje tylko subscriptions, a ja już myślę o tym, jak je dodać).

Sprawdźmy przykład dodawania komentarza. Ale najpierw musimy wykonać inną mutation, aby się zalogować, żebyś mógł dodawać komentarze. Naciśnij przycisk „Run" w kliencie GraphiQL poniżej, aby wykonać pole mutation loginUser z wcześniej utworzonym użytkownikiem testowym:

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

Teraz dodajmy kilka komentarzy. Naciśnij przycisk Run poniżej, aby dodać komentarz do jakiegoś posta, wykonując pole mutation addCommentToCustomPost (możesz też edytować tekst komentarza):

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

W tej pierwszej wersji plugin jest dostarczany z następującymi mutations:

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

​

2. Nested Mutations! 🚀🚀

Nested mutations to możliwość wykonywania mutations na typie innym niż root type w GraphQL.

Zostały zgłoszone do specyfikacji GraphQL, ale jeszcze nie zatwierdzone (i być może nigdy nie będą), dlatego Gato GraphQL dodaje ich obsługę jako funkcję opt-in, za pośrednictwem modułu Nested Mutations.

Plugin obsługuje zatem 2 tryby działania:

1. Standardowe zachowanie GraphQL (tj. dodawanie pól mutation do root type), domyślnie
2. Nested mutations, jako opcja opt-in

Na przykład powyższa query może być również wykonana za pomocą następującej query, w której najpierw pobieramy post przez Root.post, a dopiero potem dodajemy do niego komentarz przez 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 mogą również modyfikować dane na wyniku innej mutation. W poniższej query najpierw pobieramy post przez Root.post, następnie wykonujemy na nim mutation Post.addComment i uzyskujemy obiekt utworzonego komentarza, a na końcu wykonujemy na nim mutation Comment.reply:

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

To jest naprawdę przydatne! 😍 (Alternatywną metodą uzyskania tego samego zachowania w jednej query jest dyrektywa @export... Porównam obie w nadchodzącym wpisie na blogu).

W tej pierwszej wersji plugin jest dostarczany z następującymi mutations:

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

​

Standardowe czy nested? A może oba?

Możesz mieć API GraphQL, które jest używane przez własną aplikację, a jednocześnie jest publicznie dostępne dla Twoich klientów. Możesz chcieć włączyć nested mutations tylko dla własnej aplikacji, a nie dla klientów, ponieważ jest to funkcja niestandardowa.

Dobra wiadomość: to możliwe.

Dodałem sekcję „Mutation Scheme" w Schema Configuration, która służy do dostosowywania schematu dla Custom Endpoints i Persisted Queries:

Możesz więc wyłączyć nested mutations wszędzie, ale włączyć je tylko dla konkretnego custom endpointu, którego będzie używać wyłącznie Twoja aplikacja. 💪

​

Usuwanie zbędnych pól z root type

Przy nested mutations pola mutation mogą być dodane do schematu dwukrotnie:

• raz pod root type
• raz pod konkretnym typem

Na przykład te pola mogą być uznane za swoje „duplikaty":

• Root.updatePost
• Post.update

Gato GraphQL pozwala zachować oba lub usunąć te z root type, które są zbędne.

Poniższe 3 schematy:

1. Standardowe zachowanie:
   używa typów QueryRoot do obsługi queries i MutationRoot do obsługi mutations
2. Nested mutations z zachowaniem zduplikowanych pól mutation:
   pojedynczy typ Root obsługuje queries i mutations, a zbędne pola mutation w tym typie są zachowywane
3. Nested mutations z usunięciem zbędnych pól mutation z root type:
   jak powyżej, ale z usunięciem wszystkich zbędnych pól mutation z typu Root

✱ Przy okazji1, te 3 schematy używają tego samego endpointu, ale zmieniając parametr URL ?mutation_scheme na wartości standard, nested i lean_nested. Jest to możliwe, ponieważ serwer GraphQL stosuje podejście code-first. 🤟

✱ Przy okazji2, te opcje można wybrać w sekcji „Mutation Scheme" w Schema configuration (pokazanej powyżej), więc możesz też decydować, jakie zachowanie zastosować dla poszczególnych custom endpoints i persisted queries. 👏

Czas zacząć przygotowania do v0.8! 🙏