Refactor field resolution closer to schema types #573
Merged
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
pavelnikolov
requested changes
Feb 16, 2023
| return f.resolveInternal(ctx, resolver, args) | ||
| } | ||
|
|
||
| currResolver := func(ctx context.Context, args interface{}) (output interface{}, err error) { |
There was a problem hiding this comment.
(nitpick) I'd rename currResolver -> wrapResolver.
Much of the work of executing resolvers relates to the resolvable portion of fields, rather than the selection made for the request. With the introduction of directive visitors, these were being recreated for each request, instead of being built once, and re-used. By pushing the resolution of fields down into the `resolvable.Field`, directives applied to the field definition can be setup just once when the schema is created, and re-used across all requests. Small exceptions to this exist for field types that embed this to provide request specific values (resolver instance and arguments), which get passed along with the call. The chain of directive visitor functions still needs to be recreated for each resolve call, because the inner resolve function needs to accept the request specific field resolver instance, but other per-request overheads should be removed.
pavelnikolov
force-pushed
the
refactor-field-resolution-closer-to-schema-types
branch
from
fd952fa to
6f1c3fe
Compare
KNiepok
pushed a commit
to spacelift-io/graphql-go
that referenced
this pull request
Feb 28, 2023
* Refactor field resolution closer to schema types Much of the work of executing resolvers relates to the resolvable portion of fields, rather than the selection made for the request. With the introduction of directive visitors, these were being recreated for each request, instead of being built once, and re-used. By pushing the resolution of fields down into the `resolvable.Field`, directives applied to the field definition can be setup just once when the schema is created, and re-used across all requests. Small exceptions to this exist for field types that embed this to provide request specific values (resolver instance and arguments), which get passed along with the call. The chain of directive visitor functions still needs to be recreated for each resolve call, because the inner resolve function needs to accept the request specific field resolver instance, but other per-request overheads should be removed. * Fix feedback --------- Co-authored-by: Pavel Nikolov <[email protected]>
KNiepok
pushed a commit
to spacelift-io/graphql-go
that referenced
this pull request
Feb 28, 2023
* Refactor field resolution closer to schema types Much of the work of executing resolvers relates to the resolvable portion of fields, rather than the selection made for the request. With the introduction of directive visitors, these were being recreated for each request, instead of being built once, and re-used. By pushing the resolution of fields down into the `resolvable.Field`, directives applied to the field definition can be setup just once when the schema is created, and re-used across all requests. Small exceptions to this exist for field types that embed this to provide request specific values (resolver instance and arguments), which get passed along with the call. The chain of directive visitor functions still needs to be recreated for each resolve call, because the inner resolve function needs to accept the request specific field resolver instance, but other per-request overheads should be removed. * Fix feedback --------- Co-authored-by: Pavel Nikolov <[email protected]>
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
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.
Much of the work of executing resolvers relates to the resolvable portion of fields, rather than the selection made for the request. With the introduction of directive visitors, these were being recreated for each request, instead of being built once, and re-used.
By pushing the resolution of fields down into the
resolvable.Field, directives applied to the field definition can be setup just once when the schema is created, and re-used across all requests. Small exceptions to this exist for field types that embed this to provide request specific values (resolver instance and arguments), which get passed along with the call.The chain of directive visitor functions still needs to be recreated for each resolve call, because the inner resolve function needs to accept the request specific field resolver instance, but other per-request overheads should be removed.