How will you handle ordering and skip/take? about apollo HOT 6 CLOSED

@batjko That will depend on the exact circumstances. Firing manual invalidations will always have to be an option for performance and flexibility reasons, but in many applications where performance isn't critical, Apollo could do essentially what livequery is doing today and there would be no need to fire invalidations manually.

My guess is that we will have a version 0 where all invalidations have to be fired manually, and then we'll build more and more support for automatic invalidations for different backends.

from apollo.

In this case, it will probably need to be custom - you'll get to pick from one of three options:

1. Either always invalidate that list whenever points change on any user (probably not good)
2. Fire custom invalidations when you know for sure the points are close enough to be in the top list
3. Render the list via polling and never invalidate it

from apollo.

How is this done currently in Meteor? I believe the server publishes all the users and the client has a reactive query through minimongo, right? But this is not scalable for, let's say, 1M users.

from apollo.

@deiucanta . No, the server does not have to publish all users. The main reason why the current approach is not very scalable (although this is always mentioned very vaguely, I haven't seen any good benchmark yet), is that the server has to process all changes to a database, even if they are irrelevant to the users connected to that server + the server has to cache all the data a client is subscribed to (called the mergebox) in order to only send data once.

from apollo.

@sebakerckhof makes sense

Any ideas on how RethinkDB does it? They can handle thousands of reactive queries.

from apollo.

Would the invalidation (e.g. @stubailo's options 1 and 2) have to be triggered 'manually' or would Apollo do it reactively, according to those custom rules?

from apollo.