<@U0RQY0KK5> is there a way to execute functions o...
# prisma-whats-new
e
@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?
n
could you please describe your situation in the Forum: https://www.graph.cool/forum/?
e
I have registered in the forum, but I'm pretty sure this isn't a new use case.
e
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?
a
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
And also, resolver functions are a very powerful concept. So although support for some use cases is limited out of the box, there is a lot of community effort going on to provide standard solutions for common problems (like authentication for example). As long as the building blocks are easily reusable, they are a great way to quickly build a solution.
e
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.
a
That's a usecase that is very easily supported using the Mutex library
You would create a resolver function
buyTicket
or something, that grabs the mutex lock, updates the ticket info, increments the counter, and releases it
Any other calls to that function from other clients on other devices would have to wait for the mutex to be released
e
My use case is C++/Qt ... Is there a possibility to use your library in my case?
a
No the library is meant to be used inside Graphcool resolver functions
So on the server-side
Your client doesn't even have to be aware of this (well, for error handling), this is all taken care of server-side
e
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?
a
Yes, you would call the resolver function just like you would call any other GraphQL query or mutation
e
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"?
a
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.
e
Wonderful! Will definitely use your library then. Thanks for sharing 😄
a
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.
Just as a disclaimer 🙂
e
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.
a
The field mutex name is marked as unique, so there can never be a double insert. That's guaranteed
e
👍
n
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 😂
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
indeed! there are different feature requests and proposals documented in the graphcool repo 🙂 you're input is highly welcome there, too!