From 48dac3f2d26df97bc8a6ff72e62a342cd7603c30 Mon Sep 17 00:00:00 2001 From: Robert Zhu Date: Fri, 28 Apr 2017 14:21:55 -0400 Subject: [PATCH] Update RFC based on consensus from Issue #283 When the client initializes a subscription, distinct from the "Subscription Active" acknowledgement, the server may also send an initial response. Typically, subscriptions depend on a combination of input variables and event data in order to "resolve". If a subscription is capable of returning an immediate response when a client subscribes, it may do so. --- rfcs/Subscriptions.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/rfcs/Subscriptions.md b/rfcs/Subscriptions.md index 5210e4a46..e1b390e6b 100644 --- a/rfcs/Subscriptions.md +++ b/rfcs/Subscriptions.md @@ -61,7 +61,7 @@ We'll try to define the irreducible components of a GraphQL Subscriptions system The lifetime of a subscription looks like this: -* **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. +* **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. The server _may_ send an initial response from executing the subscription operation. * **Publish:** when any of the events associated with the subscription are triggered, the subscription executes the query, variables, and payload and sends the result to the client.