@nilan is there a way to execute functions one by one (not in parallel)? Think of a synchronized and mutex-locked call. If not, then what is the common practice to achieve this?

could you please describe your situation in the Forum: https://www.graph.cool/forum/?

I have registered in the forum, but I'm pretty sure this isn't a new use case.

Hey @agartha... Saw that indeed. Very interesting idea, so the fact that you had to do that means there is no such feature provided by the Functions. Am I right?

Not out of the box no. There's also this discussion for more out of the box support for concurrent execution options: https://github.com/graphcool/graphcool/issues/590

Thanks for pointing that out. But I'd be more interested in the Mutations part though. For a simple example, several people are holding a device and they are marking a ticket as sold when they make a sale, and the function increments a value in the database. That obviously need to run in serial, otherwise the parallel operations may cause a data race. And that's not the only use-case that could benefit from this. I haven't been aware of the most recent changes, like that resolver thing. So, I'll dig-up a bit how that's helping.

That's a usecase that is very easily supported using the Mutex library

My use case is C++/Qt ... Is there a possibility to use your library in my case?

No the library is meant to be used inside Graphcool resolver functions

Ok, so you mean I can make use of this lib then? I mean, I call the resolver from C++, like I would normally do, right?

Yes, you would call the resolver function just like you would call any other GraphQL query or mutation

Is it bulletproof? I'm looking at the code on how you're implementing this, but really, is it certain there would be no race on creation of the "mutex"?

Yes, as far as I know it's bulletproof. Also, checkout the comments in the thread I sent you. A few people have been going over the flow with me, and it looks like everything is covered.

Wonderful! Will definitely use your library then. Thanks for sharing 😄

Feel free to go over the code very thouroughly and share your findings on the forum. It's still a new concept, and not a battle-tested solution. So make sure you understand all of the code, and do your tests.

The code looks good. The only unknown here, is the behavior of the underlying mutation/DB, like may be a double insert. In theory, this should never happen, but who knows. I believe Graph.cool is using Amazon's MySQL offering as the backend (I might be wrong), inherently, the double insert of same ID never happens. So, it should be good. The only down-side I see is that you are using more API calls count than using a out-of-the-box solution by Graph.cool, which I hope will be added in the future -- @nilan.

The field mutex name is marked as unique, so there can never be a double insert. That's guaranteed

👍

I have registered in the forum, but I'm pretty sure this isn't a new use case.

I feel broader topics like this are better discussed in the Forum than in Slack, for exactly the reason you mention. It might have discussed 10 times already in Slack, but noone can find it anymore 😂