Subscription support
bullno1 opened this issue · comments
Is there any reason why subscription is not supported? All the codes are already there and it seems to be intentionally ignored in graphql_execute and graphql_schema_canonicalize.
Would a trivial pull request to enable it to have identical semantics to query be accepted? Or did I overlook something non-obvious with subscription?
The reason we've been hesitant to add subscriptions are that they are still being worked on for a new spec. The current specification is dated Oct 2016, and it doesn't have subscriptions. However, some of the prominent GraphQL implementations have decided upon a specific implementation path forward and this is being added into the spec.
Since this library "comes from behind", we've not added anything that people did not have consensus on yet, simply because it would be wasted effort should we have to do it all over due to a different path being looked at.
Subscriptions in their full form require persistence on the server side, something which we don't currently have in the system. So there are a couple of things we need to add into the system for this to work out fully. It is no small feat to add to a system, especially if you also start adding concurrency into the mix.
There is a (draft) specification on their working. The idea is, roughly, that you subscribe to a given query. Then, whenever that query has a change to its underlying data, you re-issue the query and feed the update to the client, more or less. So you effectively have a function server-side which is executed upon data change. I think facebook implements this based on MQTT in the backend, but I'm not sure.
That was my intention for the pull request. The way I see it, this library only provides a "query execution engine" and everything else needs to be handled by the user. Therefore, a subscription can be treated just like a query. Starting subscription and calculating result can be differentiated using the initial object or Ctx variable. Result delivery is already out of scope for this library even for query and mutation anyway so I don't think it should concern itself with something like maintaining subscriber lists.
Subscriptions are now part of the GraphQL Jun2018 spec. And we are going to track subscriptions in #163 until they are done. Hence I'm going to close this case for now.