Meteor publication limit and skip pagination with missing server-enforced max

Answer to the question

To guarantee that a publication never sends more documents than intended, the server must apply a hard cap inside the publish function. The cap is enforced by taking the client‑supplied limit argument, clamping it with a server‑defined MAX constant, and passing the result to cursor.limit(). For user permissions, the selector should always include a filter that ties the data to Meteor.userId() or a role field, ensuring only authorized documents are returned. Finally, for deep paging, replace skip with a range query on a monotonically increasing field such as _id or createdAt to avoid Mongo’s linear scan and the growing cost of reactive updates.

Likely explanation

• Meteor does not enforce any maximum per publication; it is the developer’s responsibility.
• Unbounded limit values can sync an entire collection, which is a security and performance risk.
• Using large skip values causes Mongo to scan many documents and the server to push many change notifications.
• Range‑based pagination (e.g., { _id: { $gt: lastId } }) is more efficient for deep pages.

Confirmed facts

1. When a publish function calls cursor.limit(n), Mongo enforces that limit on the server.
2. Including Meteor.userId() in the selector is a common pattern to scope data to the logged‑in user.
3. Large skip values increase the number of change events the server must track, impacting both CPU and network traffic.
4. Range queries avoid the linear scan that skip requires and keep the reactive diff small.

Steps for your use case

1. Define a hard cap. On the server, set a constant, e.g., const MAX_PER_PUB = 1000;
2. Validate client input.

   Meteor.publish('paginatedItems', function (requestedLimit, lastId) {
     check(requestedLimit, Number);
     const limit = Math.min(requestedLimit, MAX_PER_PUB);
     const selector = { ownerId: Meteor.userId() };
     if (lastId) {
       selector._id = { $gt: lastId };
     }
     return Items.find(selector, { sort: { _id: 1 }, limit });
   });
   

3. Use range‑based pagination on the client. Store the last _id received and pass it as lastId in the next subscription. This eliminates skip entirely.
4. Monitor performance. In development, enable Meteor.settings.public.debug to log the applied limit and selector. Verify that no subscription ever returns more than MAX_PER_PUB documents.
5. Guard against accidental over‑exposure. If you expose the limit parameter in the UI, add a client‑side check to warn when the user requests a value above the cap. The server check is still mandatory.

What you still need to decide

What maximum per publication is appropriate for your application? If you use role‑based access, you may want to add a role field to the selector instead of or in addition to ownerId. Let me know your target cap and any additional permission rules, and I can fine‑tune the example.