"Lazy loading" records from collection

I’m building my first meteor/angular app as a learning process and followed along with the Angular-meteor tutorials. My app is an adaptation of the “socially” tutorial on the angular-meteor.com tutorial site (http://www.angular-meteor.com/tutorials/socially)

I’ve got a thread going over at the angular-meteor group on gitter.im asking about “lazy loading” (I’m not even sure that’s the right lingo for this) a relatively large data set (47,000 employees) for a typeahead field in the UI, but not getting much traction.

My app is built around the concept of buildings and contacts at/for those buildings. The buildings collection is about 600 records and the contacts can be anyone from the entire employees collection, which is about 47,000 records.

I’ve got my app “working”, meaning I’m displaying my list of buildings, I can click into a single building record to display it’s detail and can add contacts for a building. Right now I’m just inserting all the contact info in an array (building.contacts) but I’m going to eventually just reference the employee _id along with a little bit of meta data about the contact. The building model looks like this:

        "_id" : ObjectId("568b032673586c94c7f78cab"),
        "bldg_num" : 896,
        "bldg_name" : "650 Crystal Way",
        "abbreviation" : "650 KO",
        "campus" : "ResPk",
        "street_address" : "650 Crystal",
        "street_coordinate" : "",
        "city" : "Some City",
        "state" : "State",
        "zip" : 88888,
        "status" : "A",
        "leased" : "Y",
        "built" : 1983,
        "demolished" : "",
        "location_code" : "0896000000",
        "bldg_total_sf" : 64626,
        "bldg_sppt_sf" : 0,
        "bldg_num_rooms" : "",
        "bldg_num_depts" : "",
        "bldg_usable_sf" : 64626,
        "contacts" : [
                        "contact_id" : "jblow",
                        "contact_name" : "Joe Blow",
                        "contact_email" : "jblow@some.com",
                        "contact_type" : "Business",
                        "updated" : ISODate("2016-01-13T19:11:06.249Z")
                        "contact_id" : "jjones",
                        "contact_name" : "Jim Jones",
                        "contact_email" : "jjones@some.com",
                        "contact_phone" : "888-555-1212",
                        "contact_type" : "IT",
                        "updated" : ISODate("2016-01-13T19:58:53.445Z")
        "owner" : ObjectId("568b037473586c94c7f88ca9")

My question is what are the best practices for handling this kind of thing with meteor, regardless of front-end? And by that I mean, if you have 47,000 records that you want to use for something like typeahead, what is the best way to “lazy load” the employees collection, so you’re not killing app performance?

My question is based on the assumption that when I’m setting up the typeahead I’m doing an unqualified find({}) on the employees collection, so all the records are available to me. I know this is wrong. I want to be able to eventually get to all the employees, but I don’t really want to blindly grab them all when the typeahead initializes.

Obviously I’m a complete newb at all of this so please be gentle. Thanks for any guidance.

I should also mention that I’m using the angular pagination for my list of buildings, but not sure if that can be applied to a typeahead scenario. If so that would be great, to reuse that package for this purpose. Just not sure how I’d go about that.

Take a look at the meteor-autocomplete package. Then play around with their example app. Their example app is autocompleting against 160,000 server records.

Take a look at the meteor-autocomplete1 package. Then play around with their example app. Their example app is autocompleting against 160,000 server records.

Thanks for the pointer @hwillson, I’ll do that. Initial look seems like that package is for Blaze templates. Is that correct? I’m trying to build out this app with Angular (and I’m a newb) so not sure if this can be adapted for Angular.

It is blaze specific out of the box, but you can take a look at the source to get an idea how they’ve set things up (and replicate that functionality as needed).