subscription: Allow to multiplex subsequent payloads between events

[IvanGoncharov]

In the current proposal for sending new subscriptions, events are blocked until all subsequent payloads of the last event.
That means a combination of "slow deferred fields" and fast "events" wouldn't work.

Example:
If there are 10ms intervals between events but 100ms time for resolving deferred fields.
With current proposal sequence will look like so:

event #1      <== 10ms
defer for #1  <== 100ms
event #2      <== 100ms
defer for #2  <== 120ms 

So it forces the server to buffer events and release them in bursts.

I think transport protocol should be allowed to multiplex subsequent payloads between events, like so:

event #1      <== 10ms
event #2      <== 20ms
defer for #1  <== 110ms
defer for #2  <== 120ms 

It's trivial to do by attaching the event number to initial and subsequent payloads.

In JS terms result should be: AsyncIteratable<AsyncIteratable<ExecutionResult>>
The inner iterable is for the event's initial and subsequent payloads, and the outer iterable is for subscribing events.

[robrichard]

Just want to point out that this is also a problem that exists for subscriptions without defer/stream. If the resolvers for a subscription event take longer than it takes to produce new events, the server will end up buffering. But that doesn't necessarily mean we shouldn't address this issue.

@IvanGoncharov is your recommendation that we don't specify the order and it instead becomes part of the transport layer to handle the multiplexing?

[yaacovCR]

If we accept the suggestion that multiplexing becomes possible and part of the transport layer, I think we should also seriously consider removing hasNext: true from the payload and also making it part of the transport layer. See: #5

Note that the topic there concludes with some reasoning (numbering added by me):

We chose to use a field directly on the payload instead of relying on out of band signals from the underlying transport mechanism (1) to ensure compatibility amongst clients and (2) to support defer/stream on subscriptions.

If we rely on the individual transport protocol for point number 2, then we end up having to rely on a robust transport protocol to support client compatibility, which means that point number 1 fails as well. In general, as the graphql-over-http specification matures, point 1 becomes increasingly less compelling.

What practical advantages does dropping hasNext have?

1. Saves bytes, bandwith, time, energy.
2. Provides clean separation between abstract "results" and the method by which they are delivered.
3. Paves the way for transport protocols to experiment with communicating backpressure. If separately streamed fields are multiplexed using a streamId, the client can request the additional stream payloads it needs, rather than all available streamed payloads in the order that they complete.

[robrichard]

Marking this as resolved + future-consideration since there was consensus to not include subscription support in the initial spec proposal