Subscriptions

[danstarns]

Is your feature request related to a problem? Please describe.
Looking for the ability to subscribe to events via the Neo4j GraphQL API.

Additional context
Came from here #179

[darrellwarde]

I concur, subscriptions would be a great feature to be supported and certainly mandatory in some projects.

Originally posted by @manonthemat in #179 (comment)

[darrellwarde]

Following this issue so I can know when to migrate from neo4j-graphql-js to this lib (we're already using subscriptions).

Originally posted by @AdrienLemaire in #179 (comment)

[inc16sec]

Hey guys. Is there any work on this issue? still waiting for subscriptions. I hope this feature will be next.
Anyway, good luck guys and thank you for all the work y'all are doing.

[danstarns]

Hey guys. Is there any work on this issue? still waiting for subscriptions. I hope this feature will be next.
Anyway, good luck guys and thank you for all the work y'all are doing.

Hey, we are not actively working on this. We have had some internal discussions though, we realise that to get a scalable solution would be a lot of work - something to look into after we are finished working on 2.0.0(relationship properties and cursor based pagination).

[inc16sec]

Hey guys. Is there any work on this issue? still waiting for subscriptions. I hope this feature will be next.
Anyway, good luck guys and thank you for all the work y'all are doing.

Hey, we are not actively working on this. We have had some internal discussions though, we realise that to get a scalable solution would be a lot of work - something to look into after we are finished working on 2.0.0(relationship properties and cursor based pagination).

I see. Thank you Daniel for the response and good luck with your work.

[kozak-codes]

+1! Love this repo and the people working on it, I think that this project has so much potential. I see you've had some internal discussions on this feature, and now that both relationship properties and cursor based pagination is implemented I just had a couple of quick notes on scalability & functionality for this feature:

1. I'm assuming you'll be hooking into the result of mutations and emitting some kind of event in order to push subscriptions out to the client as neo4j does not have any kind of watch functionality. If this is the case, how will you handle horizontal scaling (eg, deployments in graphql with multiple replicas). Will we be able to pass in a pub sub provider (redis, kafka, or something custom) so that any websocket connections which may be on a different instance would still receive the result of that subscription?

2. It would also be nice if we could subscribe to events on the OGM side.

Example use cases for OGM subscription functionality:

• if a blog post is created or updated to the published state, send a notification to all subscribers of that blog.
• If a blog post is deleted by a moderator, send a notification to the publisher of that blog post. If the blog post is hard deleted (as is default functionality in this repo), that subscription should include the details of that blog post because at that point it won't be able to be queried.
• After a blog post is created with a published on date in the future, schedule a job in bull queue to publish that post.
• After a comment is "connected" to a blog post, alert the moderators of that blog post
• If a comment is "disconnected" from a blog post by a moderator, alert the commentor of that blog post

Of course, this has other implications, such as if the application is scaled to more than one instance, how do we prevent these events from happening more than once if each instance is performing the same functionality? That might be something that we can just leave to the user to figure out (bull queue comes to mind as a solution) as it seems outside of the scope of this application. However, for ease of use, it might be nice to also send an "event id" for each event to make it easier to schedule jobs in bull queue.

Other ways this functionality could be implemented:

• A pre/post hook system that would allow hooks to be able to be passed into the Neo4jGraphql instance. It would be two objects: preHooks and postHooks. Each object would be composed of the nodes that could be mutated, and each node would be composed of resolver-like functions for create, update, delete, connect, or disconnect. I am currently using a forked branch with such a system for my purposes temporarily, but if my two requirements match your intended functionality of this feature I am willing to use my janky hook system for now until subscriptions come online!

I am really looking forward to this feature! Let me know if any help is needed with this. Thanks!

[AdrienLemaire]

Hi,
What is the current progress on supporting subscriptions with the new library ?
I understand that #515 will not be merged, and that #1076, #1090 and #1101 got merged instead.
Does that mean that the next release will close this issue ? Is there a timeline for it ? 🎉

[angrykoala]

HI @AdrienLemaire I apologise for not answering earlier.
You are correct, and subscriptions are already supported as a beta since the release 3.1 last week 🥳

I will close this issue now, further development in this area will be covered by separate issue