6

On my meteor project users can post events and they have to choose (via an autocomplete) in which city it will take place. I have a full list of french cities and it will never be updated.

I want to use a collection and publish-subscribes based on the input of the autocomplete because I don't want the client to download the full database (5MB). Is there a way, for performance, to tell meteor that this collection is "static"? Or does it make no difference?

Could anyone suggest a different approach?

grc
  • 22,885
  • 5
  • 42
  • 63
jadus
  • 241
  • 2
  • 12

3 Answers3

7

When you "want to tell the server that a collection is static", I am aware of two potential optimizations:

  1. Don't observe the database using a live query because the data will never change
  2. Don't store the results of this query in the merge box because it doesn't need to be tracked and compared with other data (saving memory and CPU)

(1) is something you can do rather easily by constructing your own publish cursor. However, if any client is observing the same query, I believe Meteor will (at least in the future) optimize for that so it's still just one live query for any number of clients. As for (2), I am not aware of any straightforward way to do this because it could potentially mess up the data merging over multiple publications and subscriptions.

To avoid using a live query, you can manually add data to the publish function instead of returning a cursor, which causes the .observe() function to be called to hook up data to the subscription. Here's a simple example:

Meteor.publish(function() {
    var sub = this;
    var args = {}; // what you're find()ing

    Foo.find(args).forEach(function(document) {
        sub.added("client_collection_name", document._id, document);
    });

    sub.ready();
});

This will cause the data to be added to client_collection_name on the client side, which could have the same name as the collection referenced by Foo, or something different. Be aware that you can do many other things with publications (also, see the link above.)

UPDATE: To resolve issues from (2), which can be potentially very problematic depending on the size of the collection, it's necessary to bypass Meteor altogether. See https://stackoverflow.com/a/21835534/586086 for one way to do it. Another way is to just return the collection fetch()ed as a method call, although this doesn't have the benefits of compression.

Community
  • 1
  • 1
Andrew Mao
  • 35,740
  • 23
  • 143
  • 224
3

From Meteor doc : "Any change to the collection that changes the documents in a cursor will trigger a recomputation. To disable this behavior, pass {reactive: false} as an option to find."

I think this simple option is the best answer

jadus
  • 241
  • 2
  • 12
0

You don't need to publish your whole collection.
1.Show autocomplete options only after user has inputted first 3 letters - this will narrow your search significantly.
2.Provide no more than 5-10 cities as options - this will keep your recordset really small - thus no need to push 5mb of data to each user.
Your publication should look like this: 

Meteor.publish('pub-name', function(userInput){
   var firstLetters = new RegExp('^' + userInput);
   return Cities.find({name:firstLetters},{limit:10,sort:{name:1}});
});
avalanche1
  • 3,154
  • 1
  • 31
  • 38