You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
I'm currently implementing a GraphQL subscription server and I'm interested in adding subscription logic to each subscription definition to use with my PubSub manager. Is it possible to add a custom field to a subscription definition that I can use to pass data/functions around? If not, would the core team consider this as a possible enhancement to the way subscriptions work?
The idea is to have a field similar to Resolve (possiblly called Subscribe) that will be accesible by any PubSub system that contains a function. This function would be responsible for the logic that defines how a subscription listens for events based on the client's query and publishes updates to the client. It's implementation and requirements, similar to the Resolve function, would be pretty relaxed and would rely on the developer to fill the function with the logic that they need to work with their data layer. So when a developer is definining subscriptions and needs a place to create query-specific logic for listening for events and publishing changes, they will be able to define that along side the rest of the subscription definition.
Lastly, the PubSub manager will be able to use this function when creating a new instance of a subscription.
Below is an example of what I'm trying to accomplish. This particular implementation of the proposed Subscribe field listens for changes to a RethinkDB database based on the contactID provided from the client's subscription query. After the change listener is set up, When a change to the database is received, the changes are published to the PubSub manager.
My goal is to mimic the functionality of Apollo GraphQL's graphql-subscriptions NPM package that relies on a subscribe function associated with each subscription definition to set up the subscription:
If anyone has any insight on custom fields in the subscription definition, or about this possible enhancement, I would love some feedback. Thanks for listening, and thanks for creating this library!
The text was updated successfully, but these errors were encountered:
I'm currently implementing a GraphQL subscription server and I'm interested in adding subscription logic to each subscription definition to use with my PubSub manager. Is it possible to add a custom field to a subscription definition that I can use to pass data/functions around? If not, would the core team consider this as a possible enhancement to the way subscriptions work?
The idea is to have a field similar to
Resolve
(possiblly calledSubscribe
) that will be accesible by any PubSub system that contains a function. This function would be responsible for the logic that defines how a subscription listens for events based on the client's query and publishes updates to the client. It's implementation and requirements, similar to theResolve
function, would be pretty relaxed and would rely on the developer to fill the function with the logic that they need to work with their data layer. So when a developer is definining subscriptions and needs a place to create query-specific logic for listening for events and publishing changes, they will be able to define that along side the rest of the subscription definition.Lastly, the PubSub manager will be able to use this function when creating a new instance of a subscription.
Below is an example of what I'm trying to accomplish. This particular implementation of the proposed
Subscribe
field listens for changes to a RethinkDB database based on thecontactID
provided from the client's subscription query. After the change listener is set up, When a change to the database is received, the changes are published to the PubSub manager.My goal is to mimic the functionality of Apollo GraphQL's
graphql-subscriptions
NPM package that relies on asubscribe
function associated with each subscription definition to set up the subscription:If anyone has any insight on custom fields in the subscription definition, or about this possible enhancement, I would love some feedback. Thanks for listening, and thanks for creating this library!
The text was updated successfully, but these errors were encountered: