Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Allow root operation resolvers #3917

Open
vwkd opened this issue Jun 21, 2023 · 0 comments
Open

Allow root operation resolvers #3917

vwkd opened this issue Jun 21, 2023 · 0 comments

Comments

@vwkd
Copy link

vwkd commented Jun 21, 2023

Currently, we can't set root operation resolvers. We can only set resolvers for the fields of the root operations. This is in contrast to the object fields of a non-root object type, where we can set the resolver for the field and additionally for the sub-fields. It would be useful to treat the root operation as any other object type for which a resolver can be set.

One use case for a root operation resolver is atomic transactions. For two mutations, either both should succeed or both should fail. Because resolvers are run sequentially, we can't coordinate the database calls through shared state, since one needs to return before the other even started. With root resolvers, we could handle both mutations in a single resolver and ensure an atomic transaction. One limitation would be, that both mutations can only return the same type, since the single return value from the root resolver would be used for both.

This would probably work well together with middleware #1516 too.

A workaround currently is to bundle the mutations into a single mutation such that you can create a single resolver for them. There's a nice example here https://web.archive.org/web/20220113210551/https://graphqlme.com/2018/05/13/transactions-mutations-and-graphql/

@vwkd vwkd changed the title Allow a root operation resolver Allow root operation resolvers Jun 21, 2023
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants
@vwkd and others