Joe
08/04/2022, 3:49 PMGraphQLContext
. We currently allow a resolver to set a cookie on the context which we communicate back to the client. Because of the way graphql-java's `ExecutionInput` works though, the cookie gets set on input.graphQLContext
, but not on the graphQLContextMap
that we set on the created ExecutionInput
. In trying to move to using GraphQLRequestHandler
we're missing the ability to access the context after executing the request (or batch request). Some options I can think of:
• add a public method to GraphQLRequestHandler
that takes an ExecutionInput
instead of a GraphQLServerRequest
and context
• add a getter for the context to `GraphQLServerResponse`/`GraphQLRepsonse` (but @JsonIgnore
it to hide it from the serialized json)
• do some stuff in an Instrumentation
to move the cookie from context into extensions
but then do some kind of post processing to remove the cookie extension from the response before serializing it to the client (don't love this one)
• don't leverage GraphQLRequestHandler
and continue to execute queries via a GraphQL
object ourselves (would prefer to be able to leverage eg. the batch functionality without reimplementing ourselves)
Thoughts on these options? Other ways you can think of to enable this sort of functionality? I'm happy to put together another PR once we agree on direction.Samuel Vazquez
08/05/2022, 5:50 PMJoe
08/05/2022, 6:13 PMDariusz Kuc
08/05/2022, 6:21 PMJoe
08/06/2022, 8:55 PMSamuel Vazquez
08/08/2022, 4:20 PMSpringGraphQLContextFactory
and store the
ServerRequest
and
ServerResponse
object references in the graphQLContextMap,
the you would just need to access to your graphQL Context from your data fetchers through the DataFetchingEnvironment and write directly to the response object without a webfilterJoe
08/08/2022, 6:03 PM