Skip to content

Subscription support #35

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

Closed
jhgg opened this issue Nov 17, 2015 · 5 comments
Closed

Subscription support #35

jhgg opened this issue Nov 17, 2015 · 5 comments

Comments

@jhgg
Copy link
Member

jhgg commented Nov 17, 2015

With graphql-core v0.4.9, schemas now support subscriptions. I added support in epoxy for them GraphQL-python-archive/graphql-epoxy@70e8b95 should be same level of difficulty in graphene.

@jhgg
Copy link
Member Author

jhgg commented Nov 19, 2015

👍

@kevin-abiera
Copy link
Contributor

How does this work? How do you trigger a push from the server? The way I understand the commit is that this is just the subscription part and I have to manually implement a pub-sub, am I right?

@ghost
Copy link

ghost commented Mar 15, 2017

@lightning18 The standard doesn't explicitly say when a trigger happens, only that the client may request a subscription. I would guess that then 'when' question would be something that would be something related to a signal on a given object in a post-save.

I'd guess that the right way to handle this is to require the use of django-channels (https://github.com/django/channels/) and then place a request to update the clients on the appropriate channel bus.

I'm less sure how to do this in an agnostic way- maybe the right thing to do isn't to explicitly say that graphene-django must support this, but instead to provide a documentation example of how to implement it, both for the general case of a simple notification, but also to show how (as per the GraphQL spec) there needs to be authentication support- ie a user should only get notified of a subscription to which they have proper permissions.

@femesq
Copy link
Contributor

femesq commented Mar 15, 2017

I'm joining the conversation 'cause I'm interested in this topic.

@KinkyVirCotto:
Most of the talks I saw, make use of examples that fires subscription when a mutation happens... But yes: that could happen on DB's post-save if data-mutation can happen other places too..

About the permission, that could be solved my checking the permission on subscription request. In case the user don't have access to receive such updates, the query could return an 'false' flag on a "success" field, or return null on fields values..

@ghost
Copy link

ghost commented Mar 16, 2017

@femesq Sure, that makes sense. Anything that would add/modify/delete data is grounds for a triggered event, but there's a key distinction to be made here, which is that if you place the trigger event on a mutation, then if I understand you, that means that only mutations that happen through GraphQL will trigger that event. That means things like the django admin, or command line scripts that may run (scheduled cron jobs or other events), unless those are all modified to use graphql, will not cause the event to happen.

If, on the other hand, the event happens post-save on the model, then as long as the django ORM was involved, it will trigger.

re: permissions, I wasn't actually suggesting this was a problem, but it's a situation where an example would be useful. The important thing here is to not tie permissions too closely to the framework. It should be up to developer how they want to check for permissions, but we want an example that's beyond "broadcast to everyone".

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

No branches or pull requests

4 participants