Skip to content
New issue

Have a question about this project? # for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “#”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? # to your account

Subscriptions RFC: Update wording on event stream model #304

Merged
merged 3 commits into from
May 2, 2017

Conversation

robzhu
Copy link
Contributor

@robzhu robzhu commented May 1, 2017

Updates wording to use abstract event streams instead of pubsub events. Clarifies relationship between event stream and root field/query variables.

@robzhu robzhu changed the title Event stream model Subscriptions RFC: Update wording on event stream model May 1, 2017
Copy link

@tcr tcr left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Added a few nits.


![](subscriptions_01.png)

*Above, the light blue box on the left contains the components for a traditional request/response GraphQL system. The light green box on the right contains the new components needed to support GraphQL Subscriptions.*
*Above, the blue boxes on the left are components needed to support traditional request/response GraphQL system. The green box on the right contains are new components needed to support GraphQL Subscriptions.*
Copy link

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

nit: "contains are"


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. The server _may_ send an initial response from executing the subscription operation.
* **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 stream of events to which the Subscription listens. The server _may_ send an initial response from executing the subscription operation.
Copy link

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

"initial response" -> "initial publish" for consistency?

@@ -35,7 +35,7 @@ In the case of subscriptions and live queries, the addition of server-side state

**Proposed Solution: GraphQL Subscriptions**

In "GraphQL Subscriptions", clients send the server a GraphQL query and query variables. The server maps these inputs to a set events, and executes the query when the events trigger. This model avoids overpushing/underpushing but requires a GraphQL backend. GraphQL Subscriptions provides an abstraction over individual events and exposes an API where the client subscribes to a query. Compared with existing data-transform pipeline techniques, GraphQL Subscriptions produces privacy-aware, right-sized payloads without pushing business logic to the event/messaging layer.
With "GraphQL Subscriptions", clients send the server a GraphQL query and query variables. The server maps these inputs to an event stream and executes the query when the events trigger. This model avoids overpushing/underpushing but requires a GraphQL backend. GraphQL Subscriptions provides an abstraction over business-domain events and exposes an API where the client subscribes to a query. Compared with existing data-transform pipeline techniques, GraphQL Subscriptions produces privacy-aware, right-sized payloads without pushing business logic to the event/messaging layer.
Copy link

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

"Compared with existing data-transform pipeline techniques" might not be true reading this RFC in a few years, but I'll allow it

# for free to join this conversation on GitHub. Already have an account? # to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

3 participants