Scoped Context

Apologies if this is meant to go with the specification instead of this specific client, but I couldn’t find much reference to the concept of context inside the official specification, so assumed it was a client-specific implementation detail.

With that said, a .NET GraphQL client has the following feature: Scoped Context Data

I’ve seen a few issues revolving around this idea (this one in particular comes closest), but I haven’t seen any issues call out the functionality explicitly.

I think the documentation from Hot Chocolate explains it best:

Scoped state allows us to aggregate state for our child field resolvers.

Let’s say we have the following query:

{
  a {
    b {
      c
    }
  }
  d {
    e {
      f
    }
  }
}

If the a-resolver would put something on the scoped context its sub-tree could access that data. This means, b and c could access the data but d, e and f would NOT be able to access the data, their dictionary is still unchanged.

Since I’m familiar with React, I also like to think of it as React.Context, but applied to GraphQL.

Arguably, I would assume the general suggestion for this kind of problem would be something along the lines of “adjust your architecture,” but I still do believe the feature has some benefit once you get into some advanced schemas.

Another Use-Case

If you would like another use-case, the one I am running into specifically goes as follows:

• I have a list of Comment types, each containing the user that posted the comment.
• This list of Comment types lives on a Media type, which represents a general piece of media and is used in several places throughout my service.
• In another part of the codebase, we must enforce that user names are not displayed in comments on “child” media nodes. I would much rather enforce this on the server-side instead of doing it on the frontend, as they can still see the names by inspecting the request.

The solution, in this case, is to have the parent resolver set a flag in the context that causes the Comment resolver way down stream to hide the associated user.

[sammarks]

In order to decouple it from the main context object, without knowing the inner workings of the client, my initial thought was to create some sort of object where each change to the context would be additive, and then the resulting “scoped context” object inside the children resolvers would just be a merged combination of the contexts set by all of the parent resolvers (in a quick and dirty middleware approach I would use the path field in the resolver info to identify the ancestry).

It might be worth considering separating the scoped context away from the context as it is today completely in order to avoid issues you described where mutations to the context need to be shared globally across all resolvers, and so cloning wouldn’t have to be done (causing the performance overhead).

I’m planning on making a prototype middleware (which might be sufficient as your on-off switch, just include the middleware) in the next few weeks, that just injects this “scoped context manager” inside the main context object that does exactly as I described above.

Individual contributions would be tracked with their path and the resulting (additive) context would be built for each resolver requesting it by looking at the path of the current resolver and looking for entries to the scoped context with paths that indicate ancestry to the current resolver.

[Minishlink]

As a “simple” workaround you can do this by using a map in the context where each key represents a specific entity (eg TYPENAME-ID) and the value is the “scoped context”. Limitations include: you need to know the entity’s id’s key (eg. id/ref etc), and if an entity is present outside of your current branch in the tree, it will still have the scoped context.