I have read in a separate thread how meteor struggles in busy environments. I cannot ascertain how true/false this is. How can we build for large consumption without needed an acre of server farms?
Meteor reads oplog - all of it. So all changes in database.
I am also thinking about splitting all data which does not need to be reactively updated on client to be avilable over external APIs - Rest or GraphQL/Falcor etc.
And if you really think about user needs - there is no reactivity needed for most of app types.
Optimistic UI have nothing to do with it.
2 Likes
The basics are: publish efficiently (only publish the fields you need, hit an index, etc.), don’t publish too much (observers are what make meteor unable to scale horizontally), don’t write too much, and move high velocity data to a separate db so the oplog doesn’t read it. Also, make use of the Mongo Aggregation pipeline.
If you do all of that then you should be fine.
1 Like
A walk in the park…