-
Notifications
You must be signed in to change notification settings - Fork 1.1k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Subscriptions RFC: Update wording on event stream model #304
Conversation
There was a problem hiding this 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.
rfcs/Subscriptions.md
Outdated
|
||
![](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.* |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
nit: "contains are"
rfcs/Subscriptions.md
Outdated
|
||
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. |
There was a problem hiding this comment.
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. |
There was a problem hiding this comment.
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
Updates wording to use abstract event streams instead of pubsub events. Clarifies relationship between event stream and root field/query variables.