@@ -164,20 +164,10 @@ Subscribe(subscription, schema, variableValues, initialValue):
164
164
* Let {responseStream} be the result of running {MapSourceToResponseEvent(sourceStream, subscription, schema, variableValues)}
165
165
* Return {responseStream}.
166
166
167
- Note: In large scale subscription systems, the {Subscribe} and {ExecuteSubscriptionEvent}
168
- algorithms may be run on separate services to maintain predictable scaling
169
- properties. See the section below on Supporting Subscriptions at Scale.
170
-
171
- ** Event Streams**
172
-
173
- An event stream represents a sequence of discrete events over time which can be
174
- observed. As an example, a "Pub-Sub" system may produce an event stream when
175
- "subscribing to a topic", with an event occurring on that event stream for each
176
- "publish" to that topic. Event streams may produce an infinite sequence of
177
- events or may complete at any point. Event streams may complete in response to
178
- an error or simply because no more events will occur. An observer may at any
179
- point decide to stop observing an event stream by cancelling it, after which it
180
- must receive no more events from that event stream.
167
+ Note: In large scale subscription systems, the {Subscribe()} and
168
+ {ExecuteSubscriptionEvent()} algorithms may be run on separate services to
169
+ maintain predictable scaling properties. See the section below on Supporting
170
+ Subscriptions at Scale.
181
171
182
172
As an example, consider a chat application. To subscribe to new messages posted
183
173
to the chat room, the client sends a request like so:
@@ -209,6 +199,17 @@ published to the client, for example:
209
199
The "new message posted to chat room" could use a "Pub-Sub" system where the
210
200
chat room ID is the "topic" and each "publish" contains the sender and text.
211
201
202
+ ** Event Streams**
203
+
204
+ An event stream represents a sequence of discrete events over time which can be
205
+ observed. As an example, a "Pub-Sub" system may produce an event stream when
206
+ "subscribing to a topic", with an event occurring on that event stream for each
207
+ "publish" to that topic. Event streams may produce an infinite sequence of
208
+ events or may complete at any point. Event streams may complete in response to
209
+ an error or simply because no more events will occur. An observer may at any
210
+ point decide to stop observing an event stream by cancelling it, after which it
211
+ must receive no more events from that event stream.
212
+
212
213
** Supporting Subscriptions at Scale**
213
214
214
215
Supporting subscriptions is a significant change for any GraphQL server. Query
@@ -224,7 +225,7 @@ connectivity.
224
225
225
226
#### Source Stream
226
227
227
- A Source Stream represents the sequence of events, each of which will
228
+ A Source Stream represents the sequence of events, each of which will
228
229
trigger a GraphQL execution corresponding to that event. Like field value
229
230
resolution, the logic to create a Source Stream is application-specific.
230
231
@@ -243,8 +244,8 @@ ResolveFieldEventStream(subscriptionType, rootValue, fieldName, argumentValues):
243
244
determining the resolved event stream of a subscription field named {fieldName}.
244
245
* Return the result of calling {resolver}, providing {rootValue} and {argumentValues}.
245
246
246
- Note: This {ResolveFieldEventStream} algorithm is intentionally similar
247
- to {ResolveFieldValue} to enable consistency when defining resolvers
247
+ Note: This {ResolveFieldEventStream() } algorithm is intentionally similar
248
+ to {ResolveFieldValue() } to enable consistency when defining resolvers
248
249
on any operation type.
249
250
250
251
#### Response Stream
@@ -273,12 +274,12 @@ ExecuteSubscriptionEvent(subscription, schema, variableValues, initialValue):
273
274
selection set.
274
275
* Return an unordered map containing {data} and {errors}.
275
276
276
- Note: The {ExecuteSubscriptionEvent} algorithm is intentionally similar to
277
- {ExecuteQuery} since this is how the each event result is produced.
277
+ Note: The {ExecuteSubscriptionEvent() } algorithm is intentionally similar to
278
+ {ExecuteQuery() } since this is how the each event result is produced.
278
279
279
280
#### Unsubscribe
280
281
281
- Unsubscribe cancels the Response Stream when a client no longer wishes to receive
282
+ Unsubscribe cancels the Response Stream when a client no longer wishes to receive
282
283
payloads for a subscription. This may in turn also cancel the Source Stream.
283
284
This is also a good opportunity to clean up any other resources used by
284
285
the subscription.
0 commit comments