Adds Context support. #98
Merged
Conversation
This file contains hidden or 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
This adds a net/context.Context parameter that is threaded through from
the calling API to any resolver functions. This allows an application
to provide custom, per-request handling when resolving queries.
For example, when working on App Engine, all interactions with the
datastore require a per-request context. Other examples include
authentication, logging, or auditing of graphql operations.
An alternative that was considered was to use an arbitrary, application-
provided interface{} value -- that is, the application could stick
anything in that field and it would be up to the app to handle it. This
is fairly reasonable, however using context.Context has a few other
advantages:
- It provides a clean way for the graphql execution system to handle
parallelizing and deadlining/cancelling requests. Doing so would
provide a consistent API to developers to also hook into such
operations.
- It fits with a potentially upcoming trend of using context.Context
for most HTTP handlers.
Going with an arbitrary interface{} now, but later using context.Context
for its other uses as well would result in redundant mechanisms to provide
external (application) metadata to requests.
Another potential alternative is to specifically provide just the
*http.Request pointer. Many libraries do this and use a global,
synchronized map[*http.Request]metadata lookup table. This would satisfy
the AppEngine requirements and provide a minimal mechanism to provide
additional metadata, but the global LUT is clumsy and, again, if
context.Context were later used to manage subprocessing it would provide
a redundant metadata mechanism.
|
Cool! I like it.
|
This was referenced Jan 6, 2016
Merged
1 task
|
Finally! 🍻 |
augustoroman
added a commit
to augustoroman/handler
that referenced
this pull request
Jan 16, 2016
…ext. Following graphql-go/graphql#98, it's now possible to provide a Context to the graphql resolve functions. This exposes that capability in the handler API. This follows the convention of putting the Context as the first arg, and the apparently evolving context-aware http handler func signature.
|
Nice now I can use https://github.com/labstack/echo context instead of a rootValue |
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.
Details
Adds support for
Contextavailable on each field'sResolvefunction, eg:Contextwas exposed:Resolvefunction -func(ctx context.Context, p ResolveParams)graphql.ResolveParams.Info.Contextgraphql.ResolveParams.Contextlike to example showed above, if any thoughts on this please do share 👍Thanks a lot to @tallstreet & @augustoroman who initially proposed and worked on this on Add context throughout graphql #25 and Add context parameter that passes through the API to resolvers. #82.