I am developing a multi tenant app. I want each tenant to have a subdomain
tenant1.mydomain.com
tenant2.mydomain.com
etc.
Currently, the app is hosted on a digitalocean ubuntu server with nginx as a proxy using a wildcard *.mydomain.com
I was thinking about using only one instance of the app and one collection for all tenants/subdomains, determining the content to serve based on the subdomain name.
As I am quite new to Meteor and to web development in general, I would appreciate your insight about this architecture. Here are some concerns that I have:
- Use one instance for all tenants/subdomains or one instance per tenant (app doesn’t do much server side, so don’t need much ressources)
- Use only one database and collection for all tenants or one collection per tenant (database content will be quite small for each tenant)
- How does the chosen architecture scale? What if I have 100 subdomains? 10000?
- Any problem you can see with the subdomain approach?
1 Like
Hi There, I’m also looking into information on this topic, In general I would say that we both have a similar scenario, although I still haven’t decided on using a subdomain approach just yet. some of the ideas I have are:
- Have a Tenants collections that’ll hold the registered tenants.
- I’m interested on having users that can work with different tenants, yet have different roles on each tenant, for that I think alanning:roles Groups suits my needs. Each tenant would be mapped as a roles group.
- Tenant scoped collections would be indexed by tenant and publications would use the tenant as part of the query.
- On the client side, would get the active tenant based on a client variable, session variable(?) or in your case, from parsing the subdomain name in the url?
All pretty straight forward as you may see, but so far, I think that should be about it.
I’ve been looking into meteor docs, particularly Connections, I know you can access the client connection from Publications or Methods using this.connection. So I wonder if I could come up with a sort of ConnectionManager that tracks client connections on a tenant, so I don’t need to pass around the tenant on all my subscriptions and/or method calls or in my case, modify most of my current publications and subscriptions so they handle an extra param. This is still and idea though, I’ll give it a try sometime this week and post my findings if its somehow successful 
If anyone else has more experience on this topic, I’d really like to hear your thoughts/ideas as much as @dtamburr surely does.
Most of the big players such as Salesforce store all of the tenant data together. There are quite a few videos available where they detail their backends. This works well only if the queries are identical across tenants. (indexing)
However one collection per tenant will not work
It is very tempting to isolate customer data by prefixing collection names with a customer identifier and cramming them all in a single database. Please do not do this, it will end up hurting your application if you have any kind of success. MongoDB is not meant to scale at the collection level and you will quickly run into namespace limits. Even worse, data management tools have a very difficult time handling more than 100 collections or so. This is a very sharp edge case that it’s best to avoid.
https://docs.compose.io/use-cases/multi-tenant.html
2 Likes