Image upload mutation within a greater mutation?

[shanemcgraw]

First off, this project is amazing. Thank you so much for creating it!

This is less an issue and more of a question (request for doc?):

I'm wondering how to upload an image and then create a row in a Strapi table with the imageId just created? In other words, I have a GraphQL API for a Strapi-powered backend app, with an "items" table and an "images" table. In the items table there is a column for an optional imageId foreign key.

I want to create a mutation for a new item and want to give it an imageID, but the image file should be freshly uploaded with the rest of the item details and doesn't have an ID yet.

So I'm trying to write the mega-mutation a bit like this, using createItem() and upload()

mutation CREATE_ITEM_MUTATION(
    $name: String!
    $image: Upload
  ) {
    createItem(
      input: {
        data: {
          name: $name
          image: { 
            upload(file: $image){
              id # <======= this is what I need to pass in as the "image" value to createItem
            }
          }
        }
      }
    ) {
      item {
        id
        size
      }
    }
  }

(This syntax is invalid; the playground spits out a syntax error where I use the upload( above: Expected Name, found (.

So my question is: how do I grab the imageId from the upload method and pass it in to its parent, createItem method? (Is that even possible?)

[kevinadhiguna]

This seems to be exactly the same question with https://forum.strapi.io/t/strapi-graphql-mutations-and-nested-mutations/4201 ?
Well, I wondered once how to do it in a nested mutation since I use upload mutation as well in my project. However, I have no idea if this works or will be supported in future.

[kevinadhiguna]

According to Leonardo Losoviz on Blog Rocket

... nested mutations won’t become part of the GraphQL spec (even though they’ve been requested) because graphql-js (the reference GraphQL server implementation) will not support it. If nested mutations were to be supported, the spec would need to eliminate the ability to resolve fields in parallel, which is too valuable to remove. The trade-off is not worth it, which is unfortunate because nested mutations make the schema less bloated and easier to understand. I believe that this is a benefit worth having, making nested mutations a compelling feature.

Here are some useful resources :

• Proposal: Serial fields (nested mutations)
• Supporting opt-in nested mutations in GraphQL - Blog Rocket

[shanemcgraw]

Ah, I see. That makes perfect sense. Thanks so much!