https://kotlinlang.org logo
#graphql-kotlin
Title
# graphql-kotlin
j

Joe

08/04/2022, 3:49 PM
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.
s

Samuel Vazquez

08/05/2022, 5:50 PM
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
j

Joe

08/05/2022, 6:13 PM
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!
d

Dariusz Kuc

08/05/2022, 6:21 PM
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
j

Joe

08/06/2022, 8:55 PM
that sounds cool, where is the logic that propagates from webfilter -> coroutine context?
s

Samuel Vazquez

08/08/2022, 4:20 PM
other option you can try, have a custom implementation of
Copy code
SpringGraphQLContextFactory
and store the
Copy code
ServerRequest
and
Copy code
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
j

Joe

08/08/2022, 6:03 PM
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
83 Views