GraphQL Subscriptions in Vulcan?

[sasneutrino]

Hello,

I am new to Vulcan and while studying the examples, I noticed that the grapql data are pulled every 20 seconds or so. I was wondering if it was possible to use real-time Subscriptions instead as presented on https://www.discovermeteor.com/blog/apollo-subscriptions-meteor-users/ ?

[SachaG]

Vulcan doesn't have any specific subscriptions-related features right now but that doesn't mean it's not possible. You can just do it like in any other Apollo app.

[fknipp]

Has anyone experience with subscriptions in Vulcan? The reactivity is one of the key features of Meteor, and I would like to see the same in the samples provided for Vulcan.

[MHerszak]

Vulcan and Apollo subscriptions might not really be a good fit. Meteor is polling (Vulcan every 20sec but you can increase or decrease this) and not in sync with Apollo. If Meteor stays, Vulcan could introduce optimistic updates on components, or improve on dataIdFromObject. Apollo only updates its cache when it sees a change (in Vulcan's case) in _id. When you update a document, however, Apollo won't send the data because it technically doesn't recognize the change when the _id is the same. In my opinion, subscriptions have been introduced to apps that don't do polling. I know this is not a good answer but an interesting topic :).

[SachaG]

Yeah this is a tricky question… on one hand it'd be cool to have full Apollo Subscriptions support out of the box, but it's not trivial to implement as far as I know. There's also the option of just using Meteor pub/sub, since Vulcan apps are Meteor apps after all. And that would work with basically no extra work (although of course, it's not GraphQL anymore).

So since this is a fairly complicated topic, I'll probably wait to see how important it is to people before spending too much time on it.

Of course I'd welcome a PR to add subscription support to Vulcan if it can be done relatively painlessly, but that would also mean whoever submits the PR has to keep maintaining it and contribute the appropriate documentation as well, which would involve quite a bit of work.

[fknipp]

Thanks for the comments!

So, according to @SachaG there are two ways to achieve this kind of reactivity:

1. Bypassing Apollo and falling back to Meteor pub/sub.
2. Implementing the Apollo Subscription support

After reading a little bit in the Apollo documentation, there might be future extension for live queries. Waiting for this feature could be the third option.

Which of the three options would be the most preferred one?

[justinr1234]

You would replace polling with subscriptions. You wouldn’t both poll and do subscriptions on the same query. That said, you can still mix and match. What gets sent by the subscription is completely controlled by the server. Therefore, we wouldn’t just modify the default mutations for Vulcan to also publish the changes.

As far as when Apollo updates, if you publish for a particular _id it will update. Here is a perfect example of using subscriptions:

Client side:

[justinr1234]

Client side: https://github.com/sysgears/apollo-universal-starter-kit/blob/master/packages/client/src/modules/post/containers/Post.jsx

Server: https://github.com/sysgears/apollo-universal-starter-kit/blob/master/packages/server/src/modules/post/resolvers.js

[stale[bot]]

This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. Thank you for your contributions.

[vale981]

Any news on this?

[eric-burel]

We just recently updated to Apollo v2, so technically Subscriptions are not very difficult to add. However I am not sure yet how this would integrate with the existing Vulcan API

[SachaG]

Since this is not an area that I've looked into before (and also not something I need myself at the moment) I'll probably leave it for somebody else to take on. But I agree it'd be a cool feature to add.

[justinr1234]

Likely can use this for inspiration to leverage meteor’s DDP connection: https://github.com/Swydo/ddp-apollo

I see a few approaches:

1) Implement a Redis-backed GraphQL subscription mechanism into Vulcan. This stays away from Meteor in general. 2) Utilize observeChanges to publish reactive data changes to the client via DDP. On the client, write a withSubscription wrapper that bypasses GraphQL subscriptions. Merge data into the Apollo cache manually using the Apollo client cache functions as it is received on the client via Meteor.

[SachaG]

Let's not use anything Meteor if we can avoid it.

[143mailliw]

I'll give it a try.

[143mailliw]

I can't see any way to accomplish this in a way that scales properly with out relying on some external PubSub broker or Meteor.

We could use some kind of Node MQTT broker like https://github.com/mcollina/mosca or use Redis.