CODEWITHSUNDEEP
performancemongodbmeteor
Gravity123
Gravity123

Reputation: 1130

Meteor: filter data in publish or on client

In Meteor I want to work on the document level when having a Mongo database and according to sources, what I have to watch out for is expensive publications so today my question is:

How would I go about publishing documents with relations, would I follow the relational-type of query where we would find assignment details with an assignment id like this:

enter image description here

Meteor.publish('someName', function () {
  var empId = "dj4nfhd56k7bhb3b732fd73fb";

  var assignmentData = Assignment.find({ employee_id: empId });
  return AssignmentDetails.find({ assignment_id: $in [ assignment ] });
});

or should we rather take an approach like this where we skip the filtering step in the publish and instead publish every assignment_detail and handle that filter on the client:

enter image description here

Meteor.publish('someName', function () {
  var empId = "dj4nfhd56k7bhb3b732fd73fb";

  var assignmentData = Assignment.find({ employee_id: empId });
  var detailData = AssignmentDetails.find({ employee_id: empId });

  return [ assignmentData, detailData];
});

I guess this is a question of whether the amount of data being searched trough on the server should be more then or if the amount of data being transferred to the client should be bigger.

Which of these would be most cost effective for the server?

Upvotes: 0

Views: 350

Answers (1)

richsilv
richsilv

Reputation: 8013

It's a matter of opinion, but if possible I would strongly recommend attaching employee_id to docs in AssignmentDetails, as you have in the second example. You're correct in suggesting that publications are expensive, but much more so if the publication function is more complex than necessary, and you can reduce your pub function to one line if you have employee_id in AssignmentDetails (even where there are many employee_ids for each assignment) by just searching on that. You don't even need to return that field to the client (you can specify the fields to return in your find), so the only incurred overhead would be in database storage (which is v. cheap) and adding it to inserted/updated AssignmentDetails docs (which would be imperceptible). The actual amount of data transferred would be the same as in the first case.

The alternative of just publishing everything might be fine for a small collection, but it really depends on the number of assignments, and it's not going to be at all scalable this way. You need to send the entire collection to the client every time a client connects, which is expensive and time-consuming at both ends if it's more than a MB or so, and there isn't really any way round that overhead when you're talking about a dynamic (i.e. frequently-changing) collection, which I think you are (whereas for largely static collections you can do things with localStorage and poll-and-diff).

Upvotes: 1

Related Questions