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!)

Hydrobomb

Have you found any good answers to this question? Or maybe even tried them in practice? – Brana

@Brana I have been building one myself; see github.com/HarvardEconCS/turkserver-meteor for an implementation that will become more feature-complete over the next few months. – Hydrobomb

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

Hydrobomb

Hi Andrew, this looks really cool and thanks for working on this. I'm trying to fully wrap my head around this concept of partitioning collections. Do you think this is the way to go to partition say, a web application, that is similar to Slack - where you can set up your own custom domain and then have users join that specific domain? Or a web app with a network of schools (one of them being Harvard), where only people with a certain email address ([email protected]) can connect? How would you approach that type of architecture? Would love to talk to you about this if you have ideas! – Wollongong

This is definitely a lightweight partitioning system, I probably wouldn't use this to partition a huge system with mounds of data that don't really need to be running on the same servers, etc. – Hydrobomb

Ok, thanks. Would love to pick your brain on how you might approach this if and when you have time. – Wollongong