Subscriptions RFC: Should we treat "events" as an abstract "event stream"?

[robzhu]

Re-model the concept of "events" as an abstract "event stream".
@dschafer @leebyron @rmosolgo @taion @OlegIlyenko @stubailo

Continuing the conversation from: #267 (comment)

[stubailo]

I think it might be nice to make the title a bit more generic - I think it might be better to structure it as a "callback" that can be fired in response to anything, including events.

[stubailo]

In terms of a JavaScript API, it would basically be like:

(pending the resolution of #282 the arguments can be different)

function subscriptionSetup(rootFieldName, rootFieldArgs, callback) {
  // hook up to pubsub system
  const subscription = pubsub.subscribe('my_event_name');

  subscription.on('data', (data) => {
    callback({ data: formatData(data) });
  }

  subscription.on('error', (error) => {
    callback({ error });
  }
}

This could be located in the "subscriptions system", or perhaps next to the subscription field resolver.

[tcr]

Modeling subscription payloads as a form of iterator—or in the case of future ES features, an AsyncIterators—is another viable alternative to pubsub. I think this most closely fits the definition of "event stream" you describe?

Specifying that subscription, payload receipt, and (most likely) unsubscription operations are required allows a client to model data flow using either paradigm. If this meets the criteria @leebyron was exploring in #267, we should reword the specification to be generic enough to accommodate both the type of API @stubailo describes above as well as a generic push model (like SSE, asynchronous iteration, etc.).

[robzhu]

The RFC text has been updated to describe a generic "event stream" as opposed to specific events: #304