CODEWITHSUNDEEP
javascriptnode.jsmongodbmongoosemulti-tenant
phoebus
phoebus

Reputation: 1329

NodeJS/Mongoose - Logical separation of same schema + multi-tenancy

I have 2 requirements in my application:

As for the first requirement, I'm thinking of using a multi-tenancy architecture. That is, there will be one API instance, one frontend instance per customer and one database per customer. Each request from the frontend will include a tenant ID by which the API decides which database it needs to connect to / use. I would use mongoose's useDb method for this.

Question 1: is this method a good approach and/or are there any known drawbacks performance wise? I'm using this article as a reference.

As for the second requirement, I would need to somehow logically separate certain schemas. E.g., I have my mongoose vendorSchema. But I would need to somehow separate the entries per subsidiary. I could only imagine to add a field to each of these "shared schemas" e.g.

const vendorSchema = new mongoose.Schema({
   /* other fields... */
   subsidiary {
      type: mongoose.Schema.Types.ObjectId,
      ref: "Subsidiary",
      required: true
   }
})

and then having to use this a subsidiary in every request to the API to use in the mongoose query to find the right data. That seems like a bad architectural decision and an overhead though, and seems little scalable.

Question 2: Is there a better approach to achieve this logical separation as per subsidiary for every "shared" schema?

Thanks in advance for any help!

Upvotes: 1

Views: 490

Answers (1)

proxim0
proxim0

Reputation: 1538

To maybe answer part of your question..

A multi tenant application is, well normal.. I honestly don't know of any web-app that would be single tenant, unless it's just a personal app.

With that said the architecture you have will work but as noted in my comments there is no need to have a separate DB for each users, this would be a bit overkill and is the reason why SQL or Mongo queries exist.

Performance wise, in general database servers are very performant, that's what they are designed for, but this will rely on many factors

  • Number of requests
  • size of requests
  • DB optimization
  • Query optimization
  • Resources of DB server

I'm sure there are many more I didn't list but you get the idea..

To your second question, yes you could add a 'Subsidiary' field, this would say be the subsidiary ID, so then when you query Mongo you use where subsidiar = 'id' this would then return only the items for said user...

From the standpoint of multiple request to mongo for each API call, yah you want to try and limit the number of calls each time but thats where caching comes in, using something like redis to store the responses for x minutes etc. Then the response is mainly handled by redis, but again this is going to depend a lot on the size of the responses and frequency etc.

But this actually leads into why I was asking about DB choices, Mongo works really well for frequently changing schemas with little to no relation to each other. We use Mongo for an a chat application and it works really well for that because it's more or less just a JSON store for us with simply querying for chats but the second you need to have data relate to each other it can start to get tricky and end up costing you more time and resources trying to hack around mongo to do the same task.

I would say it could be worth doing an exercise where you look at your current data structure, where it is today and where it might go in the future. If you can foresee having your data related in anyway in the future or maybe even crypto ( yes mongo does have this but its only in the enterprise version) then it may be something to look at.

Upvotes: 2

Related Questions