How to set context for subscriptions? about graphql-subscriptions HOT 14 CLOSED

@myyellowshoe Setting the GraphQL context for subscription is the transport's responsibility.
Just like you did with your graphqlKoa, you need to do the same with subscriptions-transport-ws, using the onConnecting callback (the return value of this callback will be the context for the subscriptions)

from graphql-subscriptions.

Perfect, using the onConnect works great. Thanks for the guidance! Thanks @dotansimha.

from graphql-subscriptions.

@RayzRazko , yeah, It called just like any other resolver, with (rootValue, args, context, info) (rootValue empty for subscribe, but if you implement resolve it will be the published payload )

from graphql-subscriptions.

@myyellowshoe What if I need to set the context for each individual subscription?

from graphql-subscriptions.

@dotansimha , does subscribe parameter of resolver accept context? In the documentation it is used without any arguments.

from graphql-subscriptions.

I just wanted to add here that if you use onConnect to set up DataLoaders for subscriptions you should probably turn off caching.

The reason is that you usually want the DataLoaders to be short lived, e.g. for the duration of the request for a query. When setting them up in onConnect they will live for the duration of the websocket connection.

This can cause some funky behaviour if you change the data in the DB as it will use cached values instead of re-calling the database.

from graphql-subscriptions.

I just wanted to add here that if you use onConnect to set up DataLoaders for subscriptions you should probably turn off caching.

@ravenscar Which cache are you referring to?

I am wanting to use new dataloader instances per subscription update (subscribe resolver) and I'm not sure if it is possible from what I have been reading.

from graphql-subscriptions.

@ravenscar In my case i want the data to live for the live of the connection through onConnect, as I'm only to store the logged in user for that request.
Any other time I end up use data loaders I'm only using queries.

@tdfairbrother I use dataloaders on my queries and it works great. Why are thinking that it's not possible?

from graphql-subscriptions.

@myyellowshoe I edited my answer above to clarify what I meant. I didn't mean queries, I meant subscriptions.

The onConnect callback is only called once per new subscription and not every time a subscription is resolved (subscribe resolver).

from graphql-subscriptions.

@myyellowshoe @ravenscar the cache property is on the Dataloader. It works now. Thanks for your help.

from graphql-subscriptions.

@myyellowshoe What I mean is if you set up a data loader per onConnect and don't disable caching it will live forever.

So say you ask it to load a value from the datastore, it will read it.

Then lets say the value is modified in the datastore (via a mutation, perhaps from this user perhaps another) and an event is created which will trigger the subscription.

The subscription re-uses the old dataloader, which doesn't query your datastore as it thinks it already knows the result from the previous query (but in reality it has the wrong result as the data has now changed). The subscription then delivers the old result to the client instead of the updated result.

You won't run into this problem if you're not modifying things in your datastore though.

from graphql-subscriptions.

@tdfairbrother I use the same dataloaders for queries and mutations so I didn't want to turn off caching as it really hurts query performance (lots more reads from the DB).

I have a factory function called getDataLoaders() which returns a bucket object filled with instances of all the dataloaders I need. I call this for every GET request and on onConnect for subscriptions, and place the bucket on the context.

I added a flush() utility method to this bucket which will refresh all the dataloader instances with new ones.

When I am in the resolve() of a subscription the first thing I do is call flush() to make sure all my dataloaders are fresh, although I don't need to do this for queries.

This lets be keep caching enabled but is slightly error prone if I forget to call flush().

I think a better way (although I haven't tried it) is to not put dataloaders themselves on the context but instead a factory function which will create or retrieve a dataloader based on a key, e.g. instead of fooDataLoader have getFooDataLoader(key) where key is derived from the request in queries, and the event in subscriptions.

from graphql-subscriptions.

@ravenscar yeah in my case i'm not modifying things in my subscription after the initial login. I'm largely only using it to store references to the user id, to verify login status. Good thought on using a flush method, i'll keep that in mind for the future.

from graphql-subscriptions.

@97amarnathk did you try using the onOperation callback (instead of the onConnect)?

from graphql-subscriptions.