Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
We are looking for the ability to cache certain execute operations, specifically the
resolveField
calls for a large and complex resolvers that can run very frequently since they currently trigger on GraphQL subscriptions.We have built out that caching logic in our own codebase but currently have no place to make use of this cache since the
resolveField
function is not currently exported.This is a first pass attempt at adding a bit more flexibility to graphql-js execution allowing us to cache the specific
resolveField
results that are important to our server while still falling back on the standardresolveField
function for any paths that we know do not need caching.It is very possible that this is already achievable with graphql-js but after looking through the logic in
execute.js
I did not see any way of achieving this without providing some kind of optional custom resolve field function.The main goal here is to help us address some performance concerns that have been previously raised here #723 by adding in some custom application specific caching where it seemed the most expensive operations were being repeatedly performed.
If there is another way of achieving this custom caching behavior I would really love to see if we could make it work with our current use case!
Here is a code snippet from our custom-resolve-field.ts file that illustrates a basic example of our caching logic: