Batch polling queries

[stubailo]

Right now, if you set pollingInterval on many queries, they will all be sending independent requests on their own schedule. We should see if we can schedule them in a smarter way.

[jbaxleyiii]

@stubailo that's sounds like a lot of fun to build haha

[stubailo]

Haha also I think it would be a really really cool thing to have - your whole UI updates on a consistent timer, so you don't have a ton of random data coming in all the time.

[stubailo]

Probably related to #25

I wonder how to make this work with precompiled queries, probably needs to be able to send a list of operations, which GraphQL-JS doesn't support right now I think?

[stubailo]

Something to think about in the future.

[swarthout]

I think using observables makes sense here. Imagine this:

• Each query has an observable that emits its network request. If the query is only meant to be executed once, use Observable.just().
  If the query is meant to be polled, you can use Observable.interval().map(), and for other situations we can use operators like
  Observable.fromEvent to create the network request observable.
• There is one root network-request observable that is kept in the store. A Redux reducer is called every time a new query is registered.
  This reducer updates the root network-request observable by merging the root with the new query observable using Observable.merge.
• A total batch interval is declared on the client. Ideally this is the minimum interval of all the poll intervals for all the queries.
• We apply Observable.bufferWithTime() to the root network-request observable to get our batching feature. Each time this buffered observable emits a new value,
  we query the GraphQl server with our set of queries that have been issued in that interval.
  Using prior work that has been done in the apollo client, we might be able to merge this set of queries into one query to further improve performance.

Let me know if this makes sense at all and if you think it would even work. I am happy to answer questions and discuss this more.

[stubailo]

By observable, do you mean RxJS here? Because most of the things you're talking about aren't part of the observable spec. If so, we need to make sure we can avoid loading all of RxJS.

[swarthout]

Yeah I meant RxJS. Hopefully we can get by with rx-lite and not the whole thing.

[stubailo]

I also feel there might be a simpler solution with a regular timer and redux keeping track of some of the state.

[Poincare]

See #277.