mongodb - How to optimize collection subscription in Meteor? -

i'm working on filtered live search module meteor.js.

usecase & problem:

a user wants search through users find friends. cannot afford each user ask complete users collection. user filter search using checkboxes. i'd subscribe matched users. best way ?

i guess better create query client-side, send the method desired set of users. but, wonder : when filtering criteria changes, new subscription erase of old 1 ? because, if first search return me [usr1, usr3, usr5], , after search return me [usr2, usr4], best keep first set , add new 1 on client-side suscribed collection.

and, in addition, if third research wich should return me [usr1, usr3, usr2, usr4], autorunned subscription not send me have whole result set in collection.

the goal spare processing , data transfer server.

i have ideas, haven't coded enough of yet share in comprehensive way.

how advice me more relevant possible in term of time , performance saving ?

thanks all.

david

it depends on application, you'll send non-empty string publisher uses string search users collection matching names. example:

meteor.publish('usersbyname', function(search) {   check(search, string);    // make sure user logged in , search sufficiently long   if (!(this.userid && search.length > 2))     return [];    // search case insensitive regular expression   var selector = {username: new regexp(search, 'i')};    // publish necessary fields   var options = {fields: {username: 1}};    return meteor.users.find(selector, options); }); 

also see common mistakes why limit fields.

performance

meteor clever enough keep track of current document set each client has each publisher. when publisher reruns, knows send difference between sets. situation described above taken care of you.

1. if subscribed users: 1,2,3
2. then restarted subscription users 2,3,4
3. the server send removed message 1 , added message 4.

note not happen if stopped subscription prior rerunning it.

---

to knowledge, there isn't way avoid removed messages when modifying parameters single subscription. can think of 2 possible (but tricky) alternatives:

1. accumulate intersection of prior search queries , use when subscribing. example, if user searched {height: 5} , searched {eyes: 'blue'} subscribe {height: 5, eyes: 'blue'}. may hard implement on client, should accomplish want minimum network traffic.

2. accumulate active subscriptions. rather modifying existing subscription each time user modifies search, start new subscription new set of documents, , push subscription handle array. when template destroyed, you'll need iterate through of handles , call stop() on them. should work, consume more resources (both network , server memory + cpu).

before attempting either of these solutions, i'd recommend benchmarking worst case scenario without using them. main concern without tight controls, end publishing entire users collection after successive searches.