State of Invalidation Server and Reactive GraphQL about apollo HOT 8 CLOSED

Currently reactivity is not on the short-term roadmap. We're trying to make the data loading experience for static data really good before jumping into reactivity. It turns out that reactivity and data streaming is a really easy crutch to lean on to fix data consistency problems, so we want to build something that works really well without it. It turns out most data sources people want to access at first aren't reactive anyway.

Currently, there are a few ways to get reactive features:

1. pollInterval on watchQuery on Apollo Client will let you poll the server periodically: http://docs.apollostack.com/apollo-client/core.html#watchQuery
2. You can manually call refetch on the query when you need new data
3. After we add a couple new features to apollo client, you'll be able to manually stream websocket events into the store: apollographql/apollo-client#180
4. You can use Meteor subscriptions for the reactive parts of your app, and use Apollo for the static parts

from apollo.

Yeah if the realtime features of Meteor pub sub work well for you there's almost nothing out there that will give you the same feature set right now. We're slowly trying to move towards that for GraphQL but it's not going to be there for a while.

from apollo.

Great stuff! I just read https://medium.com/apollo-stack/graphql-subscriptions-in-apollo-client-9a2457f015fb#.k80opif19

Just so I know I'm on the right track, couple questions:

1. Does that article implement #3 on the list above?
2. Seems like you've almost got full reactivity working without the invalidation server. I'm confused, what was the invalidation server for, in that case? If it's still necessary, what is it necessary for?

from apollo.

@joncursi I believe Sashko you're looking for is @stubailo ;)

from apollo.

Also - I thought that GraphQL didn't play well with polling for changes? How is this checking for GraphQL changes?

from apollo.

GraphQL subscriptions are pretty different - they don't do any change detection of diffing of data. When an event arrives, you just get the whole new result.

The invalidations and live queries would be something for the future, and the focus would be to get fine-grained updates, which subscriptions don't give you at all.

GraphQL subscriptions are definitely a great replacement for (3).

I thought that GraphQL didn't play well with polling for changes?

What do you mean?

from apollo.

@sashko is any of this reactivity possible in a Meteor + Apollo server today, or is the "recommended" solution for Meteor users mentioned here to use Meteor pubsub for live data and Apollo for static?

I just tried out Apollo subscriptions and wasn't thrilled with all of the setup and extra code that needed to be written in comparison to Meteor's pub/sub magic. Meteor spoiled me! 💃 (Plus the overhead of having to manage another external service like Redis... oy!)

from apollo.

Got it, thank you!

from apollo.