meteor-pubsub

Meteor publications and subscriptions

Publications stream a set of documents to subscribed clients and keep them live. The publication is the only place server-side authorization can filter rows before they reach the client.

Decision flow

1. Does the client need this data reactively? If no, prefer a method (one-shot read). If yes, use a publication.
2. Is the data user-specific? Filter by this.userId inside the publish function. Without that filter, documents leak across users.
3. Can the publication be expressed as a single cursor? Return it directly.
4. Does it need one async lookup before choosing a cursor? Use an async publish handler, await the lookup, then return the cursor.
5. Does it need per-document async joins, custom aggregation output, or an external reactive source? Drop to the low-level this.added / this.changed / this.removed API.

Scaffold

import { Meteor } from "meteor/meteor";
import { Items } from "/imports/api/items";

Meteor.publish("items.mine", function () {
  if (!this.userId) {
    return this.ready();
  }
  return Items.find(
    { ownerId: this.userId },
    { fields: { title: 1, qty: 1, updatedAt: 1 }, sort: { updatedAt: -1 } },
  );
});

Project fields whenever the collection contains columns the subscriber must not receive.

Async publish handlers may also return a cursor:

Meteor.publish("items.byTeam", async function (teamId) {
  const member = await Memberships.findOneAsync({
    teamId,
    userId: this.userId,
  });
  if (!member) return this.ready();
  return Items.find({ teamId }, { fields: { title: 1, qty: 1 } });
});

Meteor awaits the handler before processing the returned cursor.

Subscribing

import { Meteor } from "meteor/meteor";

const handle = Meteor.subscribe("items.mine");
// React / Blaze / Svelte hooks observe handle.ready() and the local cursor.
handle.stop();

Publication strategies

Set per-collection with Meteor.server.setPublicationStrategy. Three options: