Add capability to send multiple mutations in one request

[jardakotesovec]

GraphQL make possible to post multiple mutation tasks in one request - is possible to do that with Relay?

[clentfort]

Looking at sendMutation in the default network layer I would say no, not possible. It only ever sends one mutation at a time.
Maybe if you explain why you want to send multiple mutations at once either a suggestion on how to improve your design can be made, or it can serve as an example for when multiple mutations are useful.

[jardakotesovec]

Lets say that I have context menu where I can change many things about the image: its metadata, tags and groups. I like the idea of having several simple mutations with clear purpose rather than having one `updateImage' mutation which does everything based on args.

I understand that I could trigger several mutations via separate requests, but its not optimal - it causes more data to send/receive and possibly more re-renders.

GraphQL support that.. I would think that there was some flexibility reason for it.

But also I can imagine that things can get complicated to handle that.. and they are pretty complicated already.. so also depends on complexity that it would bring...

[yungsters]

Relay does not currently support sending multiple mutations for a single request, but there isn't any reason we can't add support for it.

[josephsavona]

This is definitely a nice to have, but we haven't seen strong demand for this feature. I'm going to close it due to inactivity, but feel free to comment here and we can reopen.

[jwaldrip]

We would love to see this too.

[kareemaly]

so I cant do a mutation like this ?

mutation {
  setViewer
  createProduct
}

That really hurts :(

[wincent]

@Kareem3d: What would setViewer do? (And specifically, what would it do that couldn't be achieved by adding another argument to the input to createProduct?) Independently of that, overriding the viewer is a delicate issue in Relay/GraphQL due to the pervasive use of caching (where switching viewers may involve large parts or all of the cache to be invalidated).

[kareemaly]

@wincent setViewer will take a token as an input and save the viewer in the context(request). this is my first try tho with graphql and relay so I'm not sure what's the best approach to handle authentication but I have been working for the last 5 days only on the graphql side and I decided to wrap all my queries with a root type that will take the token as an argument and all other queries are nested. for mutations I had in mind that they execute sequentially so I created a setViewer mutation with a token input that a user must run before any other mutation. it was quite sad after I started working on relay that it doesnt support something like that.

Now I have moved to Authorization header and removed the root query and things actually becoming much easier to manage but it just doesnt feel like a graphql way of authentication I think...

[wincent]

@Kareem3d: It's conventional to pass auth tokens along at the network layer level, but outside the query itself (see this guide for an example). You can then pass information about the authorized user through to the field resolvers on the server via context.

[gautam123456]

@yungsters @jardakotesovec Can you please add this capability, we need it for good reasons. In our project we create custom fields and then we need a way to batch update those fields, our backend already supports it but due to relay's incapability we are not able to do through ui.

[josephsavona]

I don't think we have anything in Relay Modern that limits the number of root fields in a mutation. Have you tried this with Relay Modern (it will not work in classic/compat)?

[gautam123456]

Thanks @josephsavona for replying, we are still on 0.8.2, will try to upgrade and let you know if find any issue.

[carlosneves0]

I thought I needed this, ended up implementing it with Relay Modern, and it worked.