meteor-mongo-minimongo

Mongo and Minimongo

Meteor ships two implementations of the Mongo API in one codebase. The server talks to MongoDB through an async driver. The client runs Minimongo, an in-memory synchronous Mongo emulator that holds the documents that subscriptions have shipped.

Decision flow

1. Where does this code run?
   • Server-only: use await Collection.*Async(...).
   • Client-only: use Collection.*(...) synchronously.
   • Isomorphic (import in shared code): use await Collection.*Async(...). On the client the work is local but still Promise-based; on the server it talks to Mongo.
2. Does the query select more than a page of documents? Add { limit, skip } and an index that matches the selector.
3. Are you reading from a publication on the client? Use find().fetch() (sync) without await. The data is already local.

Server reads

const doc  = await Posts.findOneAsync(id);
const list = await Posts.find({ ownerId }, {
  fields: { title: 1 }, sort: { createdAt: -1 }, limit: 50,
}).fetchAsync();
const count = await Posts.find({ ownerId }).countAsync();

Server writes

const _id = await Posts.insertAsync({ title, ownerId });
await Posts.updateAsync({ _id }, { $set: { title } });
await Posts.removeAsync({ _id });

Client reads (Minimongo)

The async API is isomorphic. Prefer it in shared code so the same line works on the server.

const doc = await Posts.findOneAsync(id);                 // works in shared/client/server
const list = await Posts.find({ ownerId }).fetchAsync();

On the client, the operation reads in-memory Minimongo but the async API still returns a real Promise. Code after await resumes in a later microtask. The sync API also works client-side, but only there:

const doc = Posts.findOne(id);                            // client-only
const list = Posts.find({ ownerId }).fetch();             // client-only

Pick sync when the calling scope is naturally sync and forcing await would cascade async into a render path. Common cases: