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 resolvers to depend on other async-resolvers. #898

Open
annitya opened this issue May 28, 2021 · 2 comments
Open

Allow resolvers to depend on other async-resolvers. #898

annitya opened this issue May 28, 2021 · 2 comments
Assignees
Labels
Community 👨‍👧 Something initiated by a community Enhancement 🆕 New feature or request
Projects
Milestone

Comments

@annitya
Copy link

annitya commented May 28, 2021

Our project has a lot of async-resolvers. This makes it difficult to build an optimal graph because we are unable to use an async-fields for further resolutions. Discussion here

A gist with a code-example can be seen here

I would very much like to have a dependsOn annotation looking something like this
The annotation would make sure that the dependee-resolver would be run first and its promise resolved.

I tried using this library, but was unable to make it work.
I also tried hacking it together myself using promises, but was unable to do so.

@MichalLytek MichalLytek added Community 👨‍👧 Something initiated by a community Enhancement 🆕 New feature or request labels May 28, 2021
@MichalLytek MichalLytek added this to Backlog in Board via automation May 28, 2021
@MichalLytek MichalLytek added this to the 2.0.0 release milestone May 28, 2021
@MichalLytek MichalLytek self-assigned this May 28, 2021
@MichalLytek
Copy link
Owner

What I can think of now as a workaround is to use graphql-fields library to parse the client's query and resolve the fields manually ahead of time. Then just return the fields as properties of root object, so they are available to other field resolvers in root object.

@annitya
Copy link
Author

annitya commented May 28, 2021

A bit of extra work and complexity, but definitely a solid suggestion I will consider using. Atm we are just refetching the object manually. This of course has the drawback that none of the resolvers are run for the re-fetched object.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Community 👨‍👧 Something initiated by a community Enhancement 🆕 New feature or request
Projects
Board
  
Backlog
Development

No branches or pull requests

2 participants