| I'm running a Meteor production app myself and found similar performance bottlenecks. However, the Meteor community has really done some great work in solving some core issues and others are on the 1.0 roadmap. Some comments on this below based on our own experience. > 1. Collection synchronization does not really work even for relatively small amounts of data (say 10k records). The issues around polling and how the server side cursors/observe works is definitely not perfect. Started using the SmartCollections package which ditches polling altogether and goes with the MongoDB OPLOG for synchonization. Has been performing well for us so far and solved many issues around performance. https://github.com/arunoda/meteor-smart-collections >2. Minimongo is interesting concept, but fails on many levels: Really depends on the usecase. I'am not sure if there is any other alternative to MiniMongo at the moment for other frameworks. The key thing is you really shouldn't expect to do many MB's of client data storage in your app. >3. Client-side is not as convenient as current MV* frameworks The key issue here is the how the DOM is re-written with the current rendering engine. The new 'Meteor UI' rendering engine and component architecture is promising to solve this issues with html element level reactive-rendering as well as an method for proper UI components delivering similar capability to what Angular offers. --- The framework is still growing up, but we are hard pressed to find something that delivers similar developer productivity. Once you understand the framework and IF it fits your needs, Meteor can work well for production. |
Yes, I'm aware about this package. However, in my case, I had to reactively count number of items in collection. SmartCollections does not have `observe` for server-side cursors and core Collection implementation is slow, so I decided to use `setTimeout` to check collection size every few seconds, which turned out to be much faster than generic collection implementation.
> The key thing is you really shouldn't expect to do many MB's of client data storage in your app.
True, it just contradicts point 003 on http://www.meteor.com/
Plus, I was also referring server-side. Application does not work with node.js MongoDB driver, it still goes through thin minimongo layer, which hides most of the driver API. And it is not fast either (due to reactivity) - see insert performance example.
Overall, I don't say it is not possible to run Meteor app in production (I have one). It is just there are alot of different quirks and gotchas in Meteor that should be worked out manually or with help of community-created packages. And all this information is mostly scattered around StackOverflow, Meteor bugtracker or in Meteor source code itself.
It is quite unpleasant to stumble upon collection synchronization performance when you have most of the application in place.