Allow passing an already created GraphQLContext to ExecutionInput #3925
Replies: 2 comments 2 replies
-
We did this on purpose - we wanted an object we can KNOW the state of better - the graphql engine then can put "objects" into the context itself at runtime eg We want this to be per request and we dont want some objects in the context to transfer over. |
Beta Was this translation helpful? Give feedback.
-
|
I understand your point, we want to protect the However, the penalty of creating a lot of GraphQLContext object might be to expensive, I need to do a heap profile to see that, but at first we have some GraphQL servers with high throughput, which GC could get a benefit by not creating a GraphQLContext from an already created GraphQLContext |
Beta Was this translation helpful? Give feedback.
-
|
You can put a shared container into the GraphQLContext for each batched operation. |
Beta Was this translation helpful? Give feedback.
-
|
that's pretty much what we are doing, in this case the shared container is a |
Beta Was this translation helpful? Give feedback.
Uh oh!
There was an error while loading. Please reload this page.
-
an http request could contain multiple graphql operations (batching), a GraphQLContext could be shared among all the ExecutionInput created from the batch, the current ExecutionInput does not allow passing a GraphQLContext, instead a map needs to be provided, which is most cases is fine, however, this will cause a lot of avoidable GraphQLContext object allocations
it would be great of the ExecutionInput Builder would allow passing a GraphQLContext
Beta Was this translation helpful? Give feedback.
All reactions