Initial PR for allowing multi tenant strategies

[mailaneel]

#3

@icebob This is my initial PR to get feedback on if I am right path or not, Right now all tests are passing.

Big change you will see is changing from this.adapter to this.getAdapter(ctx)

Example of how I am thinking of using tenantStrategy

const getHash = (ctx) => ctx.meta.tenantId

module.exports = {
  name: 'role',
  mixins: [DBService],
  tenantStrategy: {
    getAdapterHash: getHash,
    getAdapter: (ctx) => {
      return new MongooseAdapter({
        schema: RoleSchema,
        modelName: 'Role',
        uri: `${process.env.MONGO_URI_1}/${getHash(ctx)}`,
        opts: Object.assign({}, {
          useMongoClient: true
        })
      })
    }
  }
}

Pending Tasks:

• Add Tests for tenantStrategy
• Implement adding tenantKeys to queries

[coveralls]

Coverage decreased (-0.5%) to 96.344% when pulling d74b06b on mailaneel:master into 91ad674 on ice-services:master.

[mailaneel]

Approach 2:

This can be instead of tenantStrategy we can accept adapter as a function which gets called every time and must return adapter. In this case we do not cache and allow the adapter function to take care of caching.

[icebob]

@mailaneel I am not familiar with tenants. Could you show me a simple use case why it is good and need to implement? Thank you!

[mailaneel]

for my use case I want to use separate database for each each business that subscribes to my product.

I am calling each business here as tenant and they will have a separate database. In my code I want to be able to connect to these databases dynamically based on some parameters that are available in my context.

Example JWT Token

{
"name": "ABC company",
"tenantId": "123456"
}

Now in my middleware I will set this data into context.meta key so I can access this information in all ctx.call

And based on the data available in ctx.meta I want to use different adapter which might be pointing to a different database ex: mydatabase_123456 in mongo

[icebob]

Thanks. And how does tenantKeys work?

[mailaneel]

tenantKeys work similar to shardKey in mongodb or mongoose

lets say, we have configured tenantkeys as [“tenantId”]

this is useful when all tenants data is stored in same collection where every doc will have tenantId

We will need a getter, to get all tenantKeys values from ctx.. this should be provides in tenantStrategy as a function

if tenantKeys are not present in query throw Error

If we get a query for userId:1 -> this will be converted to userId:1, tenantId:12345 before passing to adapter

[mailaneel]

the other way to think about it is just allow to get adapter based on context and let user deal with implementation details i.e whether to use tenantkeys or to use multiple databases..

[icebob]

Sorry, I need more time to consider it. Currently, I'm working on other things.

[Karnith]

I feel this is a valuable addition to the db adapters. As it stands out of the box, the db adapters are considered single app adapters (meaning that the adapters are primarily for apps that would have single or multiple dbs for the entire app to consume with user data and content mingling with other user data in the same collection relational to it). By adding multi tenant capabilities a developer is able to architect the app segregating user data by user and securing it. To give a better idea around multi tenant apps, user data is typically contained in one of 3 ways in MongoDB:

• on document level (cheap and easy to administer but only secured by app logic)

• on collection level (not recommended, due to breaking mongoDB concepts)

• on database level (very flexible and secure)

the preference would be segregation on the database level. Aside from security, this also enables the ability of no impact to other tenants of the system when a tenant requires recovery of lost data. Since the backup & disaster recovery strategy would consist of backups done per tenant database, if a tenant requires a restore of their data nothing would be altered or changed in any other tenant database.