🎉 Lançado Gato GraphQL v0.7, com suporte a mutations e nested mutations!

A versão 0.7 do Gato GraphQL, com suporte a mutations e nested mutations, foi lançada! 🎉

Aqui está um tour mostrando as novidades.

​

1. Mutations! 🚀

As mutations GraphQL permitem modificar dados (ou seja, realizar efeitos colaterais) por meio da query.

As mutations eram o grande item que ainda faltava no Gato GraphQL. Agora que foram adicionadas, posso afirmar que este servidor GraphQL está praticamente completo em termos de funcionalidades (apenas as subscriptions estão faltando, e já estou pensando em como adicioná-las).

Vamos ver um exemplo adicionando um comentário. Mas primeiro, precisamos executar outra mutation para fazer o login, para que você possa adicionar comentários. Pressione o botão "Run" no cliente GraphiQL abaixo, para executar o campo mutation loginUser com um usuário de teste pré-criado:

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

Agora, vamos adicionar alguns comentários. Pressione o botão Run abaixo, para adicionar um comentário a algum post executando o campo mutation addCommentToCustomPost (você também pode editar o texto do comentário):

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

Nesta primeira versão, o plugin é fornecido com as seguintes mutations:

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

​

2. Nested Mutations! 🚀🚀

As nested mutations são a capacidade de realizar mutations em um tipo diferente do root type no GraphQL.

Elas foram solicitadas para a especificação GraphQL, mas ainda não foram aprovadas (e talvez nunca sejam), portanto o Gato GraphQL adiciona suporte a elas como uma funcionalidade opt-in, por meio do módulo Nested Mutations.

Assim, o plugin suporta os 2 comportamentos:

1. O comportamento GraphQL padrão (ou seja, adicionar campos mutation ao root type), por padrão
2. Nested mutations, como opt-in

Por exemplo, a query acima também pode ser executada com a seguinte query, na qual primeiro recuperamos o post via Root.post, e somente então adicionamos um comentário a ele 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

As mutations também podem modificar dados no resultado de outra mutation. Na query abaixo, primeiro obtemos o post via Root.post, em seguida executamos a mutation Post.addComment sobre ele e obtemos o objeto de comentário criado, e por fim executamos a mutation Comment.reply sobre ele:

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

Isso é certamente útil! 😍 (O método alternativo para produzir esse mesmo comportamento, em uma única query, é por meio da diretiva @export... Vou comparar ambos em um próximo post do blog).

Nesta primeira versão, o plugin é fornecido com as seguintes mutations:

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

​

Padrão ou nested? Ou ambos?

Você pode ter uma API GraphQL que é usada pela sua própria aplicação, e também está disponível publicamente para seus clientes. Você pode querer habilitar as nested mutations apenas para sua própria aplicação, não para seus clientes, pois essa é uma funcionalidade não padrão.

Boa notícia: é possível.

Adicionei uma seção "Mutation Scheme" na Schema Configuration, que é usada para personalizar o schema para Custom Endpoints e Persisted Queries:

Portanto, você pode desabilitar as nested mutations em todo lugar, mas habilitá-las apenas para um custom endpoint específico que somente sua aplicação usará. 💪

​

Removendo campos redundantes do root type

Com as nested mutations, os campos mutation podem ser adicionados duas vezes ao schema:

• uma vez sob o root type
• uma vez sob o tipo específico

Por exemplo, esses campos podem ser considerados "duplicados" um do outro:

• Root.updatePost
• Post.update

O Gato GraphQL permite manter ambos, ou remover os do root type, que são redundantes.

Os 3 schemas a seguir:

1. Comportamento padrão:
   usa os tipos QueryRoot para lidar com queries e MutationRoot para lidar com mutations
2. Nested mutations mantendo os campos mutation duplicados:
   um único tipo Root lida com queries e mutations, e os campos mutation redundantes nesse tipo são mantidos
3. Nested mutations removendo os campos mutation redundantes do root type:
   igual ao anterior, mas removendo todos os campos mutation redundantes do tipo Root

✱ Aliás1, esses 3 schemas usam o mesmo endpoint, mas alterando um parâmetro de URL ?mutation_scheme com os valores standard, nested e lean_nested. Isso é possível porque o servidor GraphQL segue a abordagem code-first. 🤟

✱ Aliás2, essas opções podem ser selecionadas na seção "Mutation Scheme" da Schema configuration (mostrada acima), portanto você também pode decidir qual comportamento aplicar para custom endpoints e persisted queries individuais. 👏

Agora é hora de começar a preparar a v0.8! 🙏