-
Notifications
You must be signed in to change notification settings - Fork 1.1k
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
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
|
||
 | ||
|
||
*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.