How to design a meteor smart package to transparently separate an app into different instances?

Question

This is a question for those who are very familiar with Meteor's architecture.

I am trying to design a smart package that can transparently run several "copies" of a Meteor app. That is, given an existing Meteor app, and several predefined groups of users, the package can semi-automagically "segregate" the app - run it in a way that for each group of users, it appears that only those users are using the app.

I understand that this functionality could be custom designed for any application. However, I'm looking for the most straightforward way for a smart package to provide this functionality on top of any existing app, taking into account the use of Meteor's Collections and all. Hence, it should more or less satisfy the following:

• It should be just as efficient as a regular Meteor app.
• Converting an existing Meteor app to use this system should require minimal code modification.
• The package should not have to modify or override Meteor and be relatively future-proof.

Here are some approaches and corresponding drawbacks I've thought about for this problem:

• Use all the collections of the regular Meteor app, and tag each document with an additional id representing the group that the user is in. The publications/subscriptions for each user only pull the documents with the same group id.
• Override Meteor.Collection (or implement an identical interface) in a way that makes it aware of these different groups, and from the client perspective it behaves as if the current user's group is the entire app.

I'm looking for good ideas here from someone who really knows Meteor's system. How can I design this functionality in a way that the vast majority of Meteor apps can be easily converted to work with it (i.e. avoid crazy hacks that are very brittle) yet is straightforward and efficient to implement on top of Meteor?

(If you are a Meteor guru in the NYC area, I would be happy to take you out to dinner to discuss this!)

Answer 1

I've taken my work on this problem and pulled it out into a Meteor smart package. It satisfies all the requirements I noted in my question. For more details, see the documentation and instructions.

https://github.com/mizzao/meteor-partitioner

Because I've been using this in practice already, the code is pretty stable and has a good set of tests. Comments and contributions are welcome.

An example of a package that uses this is the following:

https://github.com/HarvardEconCS/turkserver-meteor