Graphene: Subscription support

[jhgg]

With graphql-core v0.4.9, schemas now support subscriptions. I added support in epoxy for them https://github.com/graphql-python/graphql-epoxy/commit/70e8b9592b7af04a929004d76ddcef5b8b9c6a83 should be same level of difficulty in graphene.

[jhgg]

:+1:

[lightning18]

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]

@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]

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]

@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".