Hey, another question on `GraphQLContext`. We cur...

# graphql-kotlin

[Joe]

Hey, another question on GraphQLContext. 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]

Cookies are tight to transportation (HTTP), while GraphQL execution is transportation agnostic, so ideally no stuff like cookies should be set in the resolvers, what i would advice is to use instrumentations to build some HTTP context as child of GraphQLContext, maybe we can have some hooks to signal when we are about to send a HTTP response, or you can use webFilters and store the HTTPContext in the coroutine context or in the reactor context, that way in the webFilter you would access to it and just set the cookies that are in the context you built

[Joe]

oh thanks, I think having some sort of HTTP context be the child of the GraphQLContext is the right approach -- then I don't need to access the GraphQLContext after the fact, and can use the passed through child context object. will ask more if I run into any problems, thanks!

[Dariusz Kuc]

note that whatever you populate in the webfilter it will be available in the coroutine context thanks to the fixed coroutine context propagation in v6

[Joe]

that sounds cool, where is the logic that propagates from webfilter -> coroutine context?

[Dariusz Kuc]

https://github.com/ExpediaGroup/graphql-kotlin/blob/master/servers/graphql-kotlin-server/src/main/kotlin/com/expediagroup/graphql/server/execution/GraphQLServer.kt#L54

[Samuel Vazquez]

other option you can try,
have a custom implementation of

SpringGraphQLContextFactory

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 webfilter

[Joe]

yep that's the approach i've taken (though jax-rs equivalent instead of spring as we're in dropwizard) and it appears to work great, thanks for the hints