Subscriptions RFC: Fetching initial state when subscribing

[robzhu]

Fetching initial state when subscribing.
@stubailo @rzachariah @romandvoskin @taion

Continuing the conversation from: #267 (comment)

[taion]

From my response on #267:

I think this is an application-level thing. "State" is not a concept that is inherent to GraphQL. Subscribing to e.g. streams of newly created items also doesn't necessarily admit an easy representation of current state. Imagine subscription updates that don't reflect idempotent operations – in such cases there isn't really a coherent initial state.

[stubailo]

Agreed, there should be no concept of "initial state". If the backend implementation wants to send something back right away then it's free to do so, though.

[OlegIlyenko]

I also agree with others, an initial state may or may not be present. I can imagine that some implementations may client decide what data to emit based on root field arguments (like lastSeenEventId or something along these lines)

[rmosolgo]

Oh, now I see how I could get an atomic subscription request:

subscription {
  commentCreated(postId: 4) {
    # `null` on first request, but present in later updates:
    comment { 
      body 
    }
    # present on first request, but `null` in later updates:
    initialPost {
      title,
      comments {
        body 
      }
    }
  }
}

Does that sound like it'd be within spec? The server may respond to a subscription operation with a response?

[taion]

@rmosolgo Exactly

[stubailo]

Ooh! I really like that idea. Could be a clever way for the server to handle this kind of guarantee.

[robzhu]

The server may respond to a subscription operation with a response?

Perhaps we can merge this with the "subscription active" response. Something like: "The server may respond to a subscription operation. This response can be useful for returning initial data or indicating whether the operation was successful."

[taion]

I'm not sure there's a need to merge those. Thinking about Relay for the moment, I might want the "subscription active" thing to be entirely delegated to my transport layer (really just a Socket.IO ack on my "subscribe" request), while the initial message should be exposed to e.g. the Relay network layer.

Maybe it's a bit of an implementation detail at that point.

You can imagine with something SSE-based that the "subscription active" bit could just be implicit, anyway.

[jamesgorman2]

This response can be useful for returning initial data or indicating whether the operation was successful.

as per @taion , (assuming 'operation was successful' refers to subscription active) you want to keep these on different layers. Any ACK messages could go in the graphql bytestream (ie bytes handed to graphql from the underlying transport layer) but not be part of the message stream. Extending what Jimmy said, this should be delegated to the transport layer until a reason to bring it into the graphql layer since most sane transport layers will give us enough for core subscribe and unsubscribe semantics.[1]

[1] it may be desirable to propagate error messages differently when they are graphql errors, eg bad upstream data.

[jamesgorman2]

@rmosolgo I'd imagine you would want to use a union to make this type safe and since you're muxing state and updates but only want one of each type per message.

type Comment {
  author: Person
  body: String
}
type Post {
  author: Person
  title: String
  body: String
  comments: Comment[]
}
subscription {
  postWithComments(postId: Int): Post | Comment
}

This now says 'I will always send you either a post or a comment'.

subscription {
  commentCreated(postId: 4) {
    # later responses
    ... on Comment { 
      body 
    }
    # the on first response
    ... on Post {
      title,
      comments {
        body 
      }
    }
  }
}

[stubailo]

Yeah I definitely think the ACK should just be on the level of checking whether the connection is successful or not.

[robzhu]

Sounds like there's consensus on this. Summarizing:

• The server may respond to a subscription operation with a response.
• "Subscription Active"/ACK is separate from the initial response.

@rmosolgo I like your wording for the requirement, would you please submit a PR? For example, at the end of this paragraph:

Subscribe: the Client initializes a subscription by sending a query and its variables to the server. When the Subscription is created, the input query and variables are mapped to a set of events to which the Subscription listens.

Within https://github.com/facebook/graphql/blob/master/rfcs/Subscriptions.md

[robzhu]

Updated the RFC: 48dac3f