Hello Meteor dev’s. I was hoping to begin a conversation regarding architectural approaches to Multitenancy in Meteor. This conversation has been brought up in the meteor-talk group and stackoverflow. Various packages, such as mizzao:partitioner tackle the problem, and I found a meteor multisite example project on GitHub.
As Marcel Onck pointed on the google group, “Multi-tenancy is pretty common nowadays with SAAS being promoted so strongly”. I haven’t seen any common strategies for tackling it in the Meteor framework. I’m seeing developers trying, but the approaches are pretty unique. The GitHub project uses publication overloading. Developers are tackling the multitenancy problem at all levels on the stack.
Fundamentally, all of these strategies fall in the camp of using a single database with filtered queries (a more pure multitenancy solution by definition), or running separate processes and instances for each tenant (the “less elegant” approach).
I like the
mizzao:partitioner package, but my SaaS project can’t depend on authentication for partitioning. Any site visitor should be able to be recognized as belonging to a tenant group based solely on the url they were directed to my app, so I couldn’t use that package.
I tried creating a
Hostnames collection to store each tenant’s customizations (link colors, branding, etc.) and that was going well until I considered subscriptions for my
Posts collection. There is an edge case where if you visit two tenant’s sites as the same time, subscriptions based off of the site
Hostname were incorrectly rendering since each site kept overriding the subscription parameters (a very strange behavior to observe in practice).
At this juncture, I’m leaning towards simply using the less elegant solution of having a unique Meteor process and Mongo database for each tenant. It seems like Meteor wasn’t built to handle the multitenacy problem, or I haven’t thought about it the right way for it to seem so.
If anyone else would like to chime in, I’d appreciate some fresh perspectives.