Are types resolved by graphql cached?

[shoooe]

I'm running into a problem where it seems that GraphQL is caching something across different requests. Is it possible that either graphql types or that results of the DI resolver passed to the schema instance are cached?

In both cases there may be a bug in this library.

[joemcbride]

Yes the types are cached using GraphTypesLookup.

[shoooe]

But what if a graphql type is injected a resource X via the standard DI which is supposed to be "transient" or "scoped" (live as long as the request lives)?

Or to put it better. Say each graphtype needs some sort of resource. What is the recommended way to inject such resource?

[joemcbride]

You can use constructor injection coupled with a DI setup, though at this time the result will be cached and live the lifetime of the Schema.

[shoooe]

For something like DbContext that seems suboptimal. Considering that DbContext is not guaranteed to be thread safe and considering that resolvers, as far as I know, are run concurrently, that may yield concurrent errors. With Npsql (Postgres binding for Entity Framework) I get exceptions due to concurrent access to the same DbContext instance which is injected into multiple GraphQL types.

Maybe I'm missing something though. Some of my GraphQL types need to perform queries therefore for something like:

query {
    user(id: ...) { 
        ...
        posts {
            comments {
                id,
                ...
            }
        }
    }
}

The PostType would perform a query for its related comments. And each PostType seems to be resolved concurrently and each PostType is injected with a DbContext which is not thread safe.

I should probably be reading more about the N + 1 problem's solution given in the docs. That may solve this issue as well as the issue of performance in this case.