3 ms·
Congrats on the launch! As a long-time user of Meteor I'm always excited to see other approaches to similar issues. One thing that I always found a bit lacking
by sgdesign 10y ago
Congrats on the launch! As a long-time user of Meteor I'm always excited to see other approaches to similar issues.
One thing that I always found a bit lacking with Meteor was pagination. The problem in a nutshell is that the client doesn't know how much data is potentially available on the server unless it requests it, making things like showing "page 1 of 12" type result counts tricky (I talk more about it here: https://www.discovermeteor.com/blog/pagination-problems-meteor/ https://www.discovermeteor.com/blog/pagination-problems-mete... )
I'd be curious to know how Horizon deals with that problem?
- btown 10y agohttps://github.com/aldeed/meteor-tabular https://github.com/aldeed/meteor-tabular handles this with custom subscriptions, and it stays up to date by continuously polling the collection without a limit. If you want to get more real-time or more scalable, the problem is that if the total-count subscriptions can't fit in Meteor's memory, every subscription would need to re-request its count from Mongo on every incoming oplog entry, no matter whether it ends up mattering. Sadly, Horizon doesn't seem to support aggregate queries yet, reactive or not, without loading the records with findAll. Theoretically, Rethink could be even more scalable at this than Mongo, since it could use its index to only "wake up" relevant count subscribers. But this is still on the roadmap: https://github.com/rethinkdb/rethinkdb/issues/3735 https://github.com/rethinkdb/rethinkdb/issues/3735 https://github.com/rethinkdb/rethinkdb/issues/1118 https://github.com/rethinkdb/rethinkdb/issues/1118 Generally, it seems Horizon is very limited compared to Meteor, but it's a great fresh start, with a much more well-thought-out and scalable architecture, and I'm looking forward to seeing where it goes.