Skip to content

Commit 47404cb

Browse files
authored
Minor editing updates
1 parent 36359fd commit 47404cb

1 file changed

Lines changed: 33 additions & 30 deletions

File tree

spec/Section 6 -- Execution.md

Lines changed: 33 additions & 30 deletions
Original file line numberDiff line numberDiff line change
@@ -155,14 +155,27 @@ If the operation is a subscription, the result is an event stream called the
155155
"Response Stream" where each event in the event stream is the result of
156156
executing the operation for each new event on an underlying "Source Stream".
157157

158+
Executing a subscription creates a persistent function on the server that
159+
maps an underlying Source Stream to a returned Response Stream.
160+
161+
Subscribe(subscription, schema, variableValues, initialValue):
162+
163+
* Let {sourceStream} be the result of running {CreateSourceEventStream(subscription, schema, variableValues, initialValue)}.
164+
* Let {responseStream} be the result of running {MapSourceToResponseEvent(sourceStream, subscription, schema, variableValues)}
165+
* Return {responseStream}.
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+
158171
An event stream represents a sequence of discrete events over time which can be
159172
observed. As an example, a "Pub-Sub" system may produce an event stream when
160173
"subscribing to a topic", with an event occurring on that event stream for each
161174
"publish" to that topic. Event streams may produce an infinite sequence of
162175
events or may complete at any point. Event streams may complete in response to
163176
an error or simply because no more events will occur. An observer may at any
164-
point decide to stop observing an event stream, after which it must receive no
165-
more events from that event stream.
177+
point decide to stop observing an event stream by cancelling it, after which it
178+
must receive no more events from that event stream.
166179

167180
As an example, consider a chat application. To subscribe to new messages posted
168181
to the chat room, the client sends a request like so:
@@ -207,18 +220,11 @@ single machine in a service. Durability and availability may be improved by
207220
having separate dedicated services for managing subscription state and client
208221
connectivity.
209222

210-
#### Subscribe
223+
#### Source Stream
211224

212-
Executing a subscription creates a persistent function on the server that
213-
maps an underlying Source stream to the Response Stream. The logic to create the
214-
Source stream is application-specific and takes the root field and query
215-
variables as inputs.
216-
217-
Subscribe(subscription, schema, variableValues, initialValue):
218-
219-
* Let {sourceStream} be the result of running {CreateSourceEventStream(subscription, schema, variableValues, initialValue)}.
220-
* Let {responseStream} be the result of running {MapSourceToResponseEvent(sourceStream, subscription, schema, variableValues)}
221-
* Return {responseStream}.
225+
A Source Stream represents the sequence of events, each of which will
226+
trigger a GraphQL execution corresponding to that event. Like field value
227+
resolution, the logic to create a Source Stream is application-specific.
222228

223229
CreateSourceEventStream(subscription, schema, variableValues, initialValue):
224230

@@ -232,16 +238,17 @@ CreateSourceEventStream(subscription, schema, variableValues, initialValue):
232238

233239
ResolveFieldEventStream(subscriptionType, rootValue, fieldName, argumentValues):
234240
* Let {resolver} be the internal function provided by {subscriptionType} for
235-
determining the resolved value of a field named {fieldName}.
241+
determining the resolved event stream of a subscription field named {fieldName}.
236242
* Return the result of calling {resolver}, providing {rootValue} and {argumentValues}.
237243

238-
Note: this algorithm is intentionally similar to {ResolveFieldValue} to enable
239-
consistency when defining resolvers on any operation type.
244+
Note: This {ResolveFieldEventStream} algorithm is intentionally similar
245+
to {ResolveFieldValue} to enable consistency when defining resolvers
246+
on any operation type.
240247

241248
#### Response Stream
242249

243-
Each event in the underlying event stream triggers execution of the subscription
244-
selection set.
250+
Each event in the underlying Source Stream triggers execution of the subscription
251+
selection set using that event as a root value.
245252

246253
MapSourceToResponseEvent(sourceStream, subscription, schema, variableValues):
247254

@@ -250,6 +257,7 @@ MapSourceToResponseEvent(sourceStream, subscription, schema, variableValues):
250257
* Let {response} be the result of running
251258
{ExecuteSubscriptionEvent(subscription, schema, variableValues, event)}.
252259
* Yield an event containing {response}.
260+
* When {responseStream} completes: complete this event stream.
253261

254262
ExecuteSubscriptionEvent(subscription, schema, variableValues, initialValue):
255263

@@ -263,22 +271,17 @@ ExecuteSubscriptionEvent(subscription, schema, variableValues, initialValue):
263271
selection set.
264272
* Return an unordered map containing {data} and {errors}.
265273

266-
Note: in large scale subscription systems, the {ExecuteSubscriptionEvent} and
267-
{Subscribe} algorithms may be run on separate services to maintain predictable
268-
scaling properties. See the section above on Supporting Subscriptions at Scale.
269-
This algorithm is intentionally similar to {ExecuteQuery} since this is where
270-
the subscription's selection set is executed.
274+
Note: The {ExecuteSubscriptionEvent} algorithm is intentionally similar to
275+
{ExecuteQuery} since this is how the each event result is produced.
271276

272277
#### Unsubscribe
273278

274-
Unsubscribe cancels the Response Stream. This is also a good opportunity for the
275-
server to clean up the underlying event stream and any other resources used by
276-
the subscription. Here are some example cases in which to Unsubscribe: client
277-
no longer wishes to receive payloads for a subscription; the source event stream
278-
produced an error or naturally ended; the server encountered an error during
279-
{ExecuteSubscriptionEvent}.
279+
Unsubscribe cancels the Response Stream when a client no longer wishes to receive
280+
payloads for a subscription. This may in turn also cancel the Source Stream.
281+
This is also a good opportunity to clean up any other resources used by
282+
the subscription.
280283

281-
Unsubscribe()
284+
Unsubscribe(responseStream)
282285

283286
* Cancel {responseStream}
284287

0 commit comments

Comments
 (0)