Subscriptions: Final edits #392
Conversation
This does a last pass over the subscriptions specification to clean up some ambiguities and crisp up some language. Two important things to take note of: 1. The `CreateSourceEventStream` algo was underspecified and did not articulate how fields should be collected from the selection set. This makes it clear that `CollectFields` is used, just like any other selection set. It also did not describe behavior when executing an invalid query, this adds that a query-level error should be thrown. 2. The Subscription Operation validation is similarly underspecified, and does not describe what should happen if a fragment spread is found as the first selection in a selection set. This clarifies that it is *fields* that exactly one is expected, rather than selections.
| @@ -248,6 +252,20 @@ subscription sub { | |||
| } | |||
| ``` | |||
|
|
|||
| ```graphql counter-example | |||
There was a problem hiding this comment.
Is it worth documenting the expected behavior of sending a single document with multiple subscription operations and an operation name?
There was a problem hiding this comment.
Sure - I can add that
|
Wait, sorry -- |
That's correct. Is that a limitation that will cause problems for you? |
|
Correct - this limitation solves a whole class of ambiguities regarding merging event streams. We've found in practice it's almost always preferable to have multiple open subscriptions rather than a single subscription that attempts to merge streams |
|
@robzhu & @leebyron I see. I haven't yet started implementing subscriptions. We're looking to potentially migrate to them to implement what's essentially a live query (hence my discussions on other tickets) from an existing system that uses an ad hoc Web Socket protocol. But since this is still in the early stages, I can't say for sure whether this is an issue. It's probably fine. It seems like the issue could be skirted by having a field represent a whole bunch of different events and return a union of event payloads. I was just surprised, since Sangria's pre-spec subscription implementation doesn't have this restriction, so just wanted to make sure I understood. It seems like they solve the problem by largely treating the document as independent subscriptions, and the event stream simply only contain one of the root fields per payload. |
|
Yeah - we could lift this restriction in the future should crisp semantics become more clear and the value outweigh the cost of the potential for confusion. At Facebook we faced some serious roadblocks to supporting multiple subscription root fields for this and other reasons - so felt it was best to specify a more limited functionality set out of the gates |
This does a last pass over the subscriptions specification to clean up some ambiguities and crisp up some language.
Two important things to take note of:
The
CreateSourceEventStreamalgo was underspecified and did not articulate how fields should be collected from the selection set. This makes it clear thatCollectFieldsis used, just like any other selection set. It also did not describe behavior when executing an invalid query, this adds that a query-level error should be thrown.The Subscription Operation validation is similarly underspecified, and does not describe what should happen if a fragment spread is found as the first selection in a selection set. This clarifies that it is fields that exactly one is expected, rather than selections.