Meteor DDP Publications Generating Excessive Client Updates

Meteor DDP Publications Generating Excessive Client Updates

The goal is to configure Meteor’s publish/subscribe system so that clients receive only the necessary DDP messages, avoiding noise that triggers unnecessary UI re-renders or bandwidth usage. The current setup uses broad cursors without field limits, and templates or hooks are autorunning with overlapping subscriptions, causing redundant updates. Constraints include maintaining real‑time responsiveness while minimizing the number of added/changed messages over the websocket. There is uncertainty about the optimal balance between server‑side field trimming, cursor limits, and client‑side reactive scoping.

Key questions:

1. What is the impact on update frequency when adding explicit field projections to a publication cursor versus relying on client‑side minimongo filtering?
2. How does the number of autoruns in a template affect the volume of DDP messages when multiple subscriptions reference the same collection?
3. What best‑practice patterns exist for scoping reactive computations to avoid re‑running when unrelated data changes?