Subscriptions RFC: Where to store subscription state?

[robzhu]

Where should subscription state be stored? (inside GraphQL-js or as a separate component?)
@theorygeek @taion @stubailo @rmosolgo @jamesgorman2

Continuing the conversation from: #267 (comment)

[taion]

I don't think this matters for the spec. Implementation-wise I think it'd be neater to have the state live outside GraphQL.js though.

[rmosolgo]

👍 Agreed that it should be basically excluded from the spec.

In the same way that storage and transport are "application-specific", subscription management should also be application-specific.

For example, one application may push updates over a websocket connection and consider a client unsubscribed when the connection is closed, while another application may respond to subscriptions by creating webhooks and push updates by hitting a client-supplied URL. Ideally, the spec would be flexible enough to accommodate either case without prescribing one or the other.

(Personally, if I set up GraphQL subscriptions, it would probably be based on Pusher, which is neither here nor there!)

[robzhu]

@leebyron this is relevant to the discussion we had about subscription state.

@taion, @rmosolgo Looks like we have consensus to leave this out of the spec. I'll submit a PR to clarify the message in the RFC.

EDIT: Upon re-reading the RFC, there's are no implied constraints or recommendations for packaging/module breakdown, so I won't submit a PR after all. Closing this issue.