Type-graphql: Passing information from middlewares to other middlewares and resolvers

[reilem]

Is your feature request related to a problem? Please describe.

Not sure if really a feature request, but I tried looking around in the docs and source code and couldn't get this to work.

Is it possible to pass information from a middleware / custom decorator to the next middleware / resolver?

Describe the solution you'd like

It would be nice if the next() function could be given information which is then passed to the next middleware/resolver.

Describe alternatives you've considered

I tried mutating the context object, but changes were not persisted across middlewares.

Additional context

Basically sometimes I have a middleware which fetches an entity from a database, throws an Error if it does not exist, and continues if it does. Currently if I need that same entity in the resolver then I am forced to fetch it AGAIN, which causes yet another database query to be executed. It would be nice if I could just fetch the entity once in the middleware, and pass it to the resolver.

Maybe I'm going about this all wrong, so any other suggestions are definitely welcome.

[MichalLytek]

Is it possible to pass information from a middleware / custom decorator to the next middleware / resolver?

In GraphQL, common way to pass some request scoped data is by putting (mutating) the context data. It can be user loaded from database based on the JWT or something like that.

In TypeGraphQL, middlewares can't return any data because there's nowhere the data could flow - other middlewares doesn't have optional maybeData parameter. You can only mutate the context object if you need.

However, sometimes it's handy to inject something into resolver based on the resolve data (context or info), so you can use custom param decorators for that - they can return some data and resolver will get it injected as a param.

I tried mutating the context object, but changes were not persisted across middlewares.

Show me how to setup your context object (ApolloServer or other) and how you were mutating the object.
It has to work, plenty of GraphQL stuff is designed around that like dataloaders so it something wrong with your code - maybe the order of middlewares is different than you expected?

Basically sometimes I have a middleware which fetches an entity from a database, throws an Error if it does not exist, and continues if it does. Currently if I need that same entity in the resolver then I am forced to fetch it AGAIN, which causes yet another database query to be executed. It would be nice if I could just fetch the entity once in the middleware, and pass it to the resolver.

Just implement the caching mechanism on the repository level. So if you request the same entity again, it will just read the previously cached value, no mater if it's in middleware, resolver or a service 😉

[reilem]

Ok I tried changing the context again to reproduce my issue. However it seems now that I CAN modify the context and observe the change in resolvers and other middlewares 😅

So I guess this issue was my fault after all! Just out of curiosity though, which of the four resolver data arguments (root, args, context, info) are actually modifiable / which do you recommend not to touch? And would this by any chance by written in the docs anywhere? Perhaps it would be a good idea to include this somewhere as a note.

In any case, thanks for confirming that it should be possible! I must have been trying too many things simultaneously last time which must have broken something and made the changes not persist.

[MichalLytek]

That four resolver data arguments are a standard resolver params in all GraphQL implementation. There's no TypeGraphQL-related rules.

You can modify everything but on your own risk, if you know what you're doing (library, framework, plugin).
For standard usage, only context is controller by user and can be quite safely mutated/modified.