[aioprisan]

did you make sure that you don't have the insecure package installed, that pushes the entire database to each client, and instead are subscribing to the data? this is reminiscent of how one one of proof of concept apps was acting a few months back and that was the cause.

[mcrider]

Sure, thats Meteor 101 ;) Still, as a developer you need to decide what collections you want to publish (and which parts of each collection) so as to make the application run blazing-fast but also make sure you're only publishing stuff when its needed. This, IMO takes some finessing to get right.

[wc-]

This was definitely my biggest scaling painpoint. I used meteor for an app that throws a lot of data points at the client (interactive realtime timeseries data) and it required trying a few different approaches until I was happy with the amount of data I was sending over the wire on first load vs making the client's first experience as interesting as possible.

My current gripe is with the spiderable package and phantomjs for seo bots, but that is a different beast...

[mcrider]

I've gotten spiderable to work okay but yeah it does kindof suck. According to the Meteor roadmap, MDG is looking for a better solution but its slated for a 1.1 release (i.e. server-side rendering).

[aioprisan]

ah ok :) interesting, could you share some of the code in question, or is this a closed source app? I'd be happy to take a quick look

[mcrider]

The project was based off of the CMS I've been building in my spare time: https://github.com/mcrider/azimuth. There are probably a lot of things I could do to optimize collections with lots of data but i've been focusing more on functionality for now.