3 ms·

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

by mcrider 13y ago

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.

aioprisan 13y ago
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 13y ago
  The project was based off of the CMS I've been building in my spare time: https://github.com/mcrider/azimuth 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.
wc- 13y ago
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 13y ago
  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).