It’s a tradeoff. You have two options as far as I can see:
in your original publication for the doc, pull more fields. Then as they drill down, you already have the data in their local collection and only need to show it.
Advantage: faster drilldown.
Potential Disadvantage: slower initial load if you have a lot of detail data to load.
do what I suggested: load the details dynamically as they drill down.
Advantage: faster initial load of the list
Disadvantage: slower drill-down.
or you can combine the two approaches in various ways i.e. during the initial load, get the fields for the first two levels. Top level data and one drill down level. Then if they drill down one level it will be snappy. If they need to drill down again, you’ll have to load data again, but you could load several levels again i.e. all the fields need for level 3, 4, 5.
It really depends on how much data you have to show. If it’s just a few fields, include them in the initial sub so you’ll have the values ‘pre-cached’ for the drill-down. But it’s it’s a massive amount of data, then you’ll have to think about where you want to pay the performance cost. It’s not really a Meteor problem; you’ll have this same compromise to make with Rails or any other distributed application framework.
It’s just like loading a city/state list for an address form. If you wait until they pick country, you have to load the cities and there is a small delay. Or you can pre-fetch all the city/state data for every country, but maybe that slows page load esp. on mobile.
I’m surprised the drill down time is 500ms. We’ve seem much better performance. Our apps are near real-time in syncing data from clientA to server then down to clientB. Very minimal delays.
Where are you hosting? how much data is in the collection (document count), how much data are you pulling (a few fields? or 30kilobytes? more?, are your query fields indexed in mongo?