🎉 ¡Lanzado Gato GraphQL v0.7, con soporte para mutations y nested mutations!

¡Se ha lanzado la versión 0.7 de Gato GraphQL, con soporte para mutations y nested mutations! 🎉

Aquí tienes un tour mostrando las nuevas incorporaciones.

​

1. ¡Mutations! 🚀

Las mutations de GraphQL permiten modificar datos (es decir, realizar side-effects) a través de la consulta.

Las mutations eran lo grande que aún faltaba en Gato GraphQL. Ahora que se han añadido, puedo afirmar que este servidor GraphQL está prácticamente feature-complete (solo faltan las subscriptions, y ya estoy pensando en cómo añadirlas).

Veamos un ejemplo añadiendo un comentario. Pero primero, necesitamos ejecutar otra mutation para iniciar sesión, para que puedas añadir comentarios. Pulsa el botón "Run" en el cliente GraphiQL de abajo, para ejecutar el campo mutation loginUser con un usuario de testing pre-creado:

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

Ahora, añadamos algunos comentarios. Pulsa el botón Run debajo, para añadir un comentario a alguna entrada ejecutando el campo mutation addCommentToCustomPost (también puedes editar el texto del comentario):

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

En esta primera release, el plugin viene con las siguientes mutations:

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

​

2. ¡Nested Mutations! 🚀🚀

Las nested mutations son la capacidad de realizar mutations sobre un tipo distinto al root type en GraphQL.

Han sido solicitadas para la spec de GraphQL pero aún no aprobadas (y puede que nunca lo sean), por tanto Gato GraphQL añade soporte para ellas como característica opt-in, vía el módulo Nested Mutations.

Así, el plugin soporta los 2 comportamientos:

1. El comportamiento estándar de GraphQL (es decir, añadir campos mutation al root type), por defecto
2. Nested mutations, como opt-in

Por ejemplo, la consulta de arriba también puede ejecutarse con la siguiente consulta, en la que primero obtenemos la entrada vía Root.post, y solo entonces le añadimos un comentario vía 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

Las mutations también pueden modificar datos sobre el resultado de otra mutation. En la consulta de abajo, primero obtenemos la entrada a través de Root.post, luego ejecutamos la mutation Post.addComment sobre ella y obtenemos el objeto comentario creado, y finalmente ejecutamos la mutation Comment.reply sobre él:

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

¡Esto sí es útil! 😍 (El método alternativo para producir este mismo comportamiento, en una sola consulta, es vía la directiva @export... Compararé ambos en una próxima entrada del blog).

En esta primera release, el plugin viene con las siguientes mutations:

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

​

¿Estándar o nested? ¿O ambos?

Puede que tengas una API GraphQL que usa tu propia aplicación, y que también está disponible públicamente para tus clientes. Puede que quieras habilitar las nested mutations pero solo para tu propia aplicación, no para tus clientes porque esta es una característica no estándar.

Buenas noticias: puedes.

He añadido una sección "Mutation Scheme" en la Schema Configuration, que se usa para personalizar el esquema para Custom Endpoints y Persisted Queries:

Por tanto, puedes deshabilitar las nested mutations en todas partes, pero habilitarlas solo para un custom endpoint específico que solo tu aplicación usará. 💪

​

Eliminar campos redundantes del root type

Con las nested mutations, los campos mutation pueden añadirse dos veces al esquema:

• una vez bajo el root type
• una vez bajo el tipo específico

Por ejemplo, estos campos pueden considerarse "duplicados" entre sí:

• Root.updatePost
• Post.update

Gato GraphQL permite mantener ambos, o eliminar los del root type, que son redundantes.

Los siguientes 3 esquemas:

1. Comportamiento estándar:
   usa los tipos QueryRoot para manejar queries y MutationRoot para manejar queries
2. Nested mutations manteniendo campos mutation duplicados:
   un único tipo Root maneja queries y mutations, y los campos mutation redundantes en este tipo se mantienen
3. Nested mutations eliminando campos mutation redundantes del root type:
   igual que el anterior, pero eliminando todos los campos mutation redundantes del tipo Root

✱ Por cierto1, estos 3 esquemas usan todos el mismo endpoint, pero cambiando un parámetro URL ?mutation_scheme a los valores standard, nested y lean_nested. Eso es posible porque el servidor GraphQL sigue el enfoque code-first. 🤟

✱ Por cierto2, estas opciones pueden seleccionarse en la sección "Mutation Scheme" en la Schema configuration (mostrada arriba), por tanto también puedes decidir qué comportamiento aplicar para custom endpoints y persisted queries individuales. 👏

¡Ahora es momento de empezar a preparar v0.8! 🙏