Hi , I have requirement using Cosmos Db.All tenants share same dbnsme and connection string Which is better to have 1.Single Dbcontext Change the container name on dynamic based on tenant provider 2. Spreate Dbcontex for each tenant..
I'll go for the first approach, the important thing here having a single connection to cosmosdb, it is exactly like calling a third-party API, you'll create a HttpClient with a base address (here is the connecitonString) and call different endpoints (here is the containername).
@sa-es-ir Thank you for the details.. But I have one query, I have created a project with 1st approach 1., In a single AppDbcontext Onmodelcreating calling only once 2. When I send a request for another tenant Onmodelcreating is not getting called.. 3.Using AddDbContextFactory in Di container Please let me know to resolve this
@@ArjunRR-cz8hb Do you have a code like mine in this video? if yes then please provide a github repo then I can see the code and talking about the actual problem.
Very nice one; it looks very useful. Also, it would be good to explain different custom tenant strategies, as we often need them for SaaS products where need ensuring that each tenant's data is securely isolated from others...
Thanks Admir and great suggestion, an good option would be jwt token claims its more secure but we need to make sure to config indentity provider for supporting tenantId. Any other options you have in mind?
@@sa-es-ir - Well depends of many vectors... :-) I believe database structures could address multi-tenant requirements, such as distinctive schemas within a shared database or isolated databases for each customer, choosing the optimal approach depends on needs. A crucial consideration is scalability - as clients increase, the solution must flexibly support surging data volumes and tenants without hampered speeds. This may necessitate scaling out the database horizontally across extra resources, establishing proficient indexing of information for rapid access, and refining questions for swift handling. Similarly vital is maintaining solitude of each tenant's information through logical or physical isolation. The design selected will likely represent a balanced composite of performance during growth, convenience, and privacy based on a project's unique demands and comfort with complexity.
@@admirmujkic5859 well explained and I think in case of scaling out you still have the same tenant so that no matter how many instances you have, just query on tenantId. The entry point for each area is tenantId so we need to transfer it in a secure way.
Very well explained. Simplicity at at its best.
Happy you like the video
Hi , I have requirement using Cosmos Db.All tenants share same dbnsme and connection string
Which is better to have
1.Single Dbcontext Change the container name on dynamic based on tenant provider
2. Spreate Dbcontex for each tenant..
I'll go for the first approach, the important thing here having a single connection to cosmosdb, it is exactly like calling a third-party API, you'll create a HttpClient with a base address (here is the connecitonString) and call different endpoints (here is the containername).
@sa-es-ir Thank you for the details..
But I have one query, I have created a project with 1st approach
1., In a single AppDbcontext Onmodelcreating calling only once
2. When I send a request for another tenant Onmodelcreating is not getting called..
3.Using AddDbContextFactory in Di container
Please let me know to resolve this
@@ArjunRR-cz8hb Do you have a code like mine in this video? if yes then please provide a github repo then I can see the code and talking about the actual problem.
Very nice one; it looks very useful. Also, it would be good to explain different custom tenant strategies, as we often need them for SaaS products where need ensuring that each tenant's data is securely isolated from others...
Thanks Admir and great suggestion, an good option would be jwt token claims its more secure but we need to make sure to config indentity provider for supporting tenantId.
Any other options you have in mind?
@@sa-es-ir - Well depends of many vectors... :-) I believe database structures could address multi-tenant requirements, such as distinctive schemas within a shared database or isolated databases for each customer, choosing the optimal approach depends on needs. A crucial consideration is scalability - as clients increase, the solution must flexibly support surging data volumes and tenants without hampered speeds. This may necessitate scaling out the database horizontally across extra resources, establishing proficient indexing of information for rapid access, and refining questions for swift handling. Similarly vital is maintaining solitude of each tenant's information through logical or physical isolation. The design selected will likely represent a balanced composite of performance during growth, convenience, and privacy based on a project's unique demands and comfort with complexity.
@@admirmujkic5859 well explained and I think in case of scaling out you still have the same tenant so that no matter how many instances you have, just query on tenantId.
The entry point for each area is tenantId so we need to transfer it in a secure way.
Please make a series about Multi Tenant
I put it in the list, stay tuned
Nice tutorial thanks!
Thank you for yuor support🌷
hey mate, where can I learn c# from scratch?
It's very good place to go: th-cam.com/play/PLdo4fOcmZ0oULFjxrOagaERVAMbmG20Xe.html&si=liJ8VtdbILvkqjmR
Great video
Very glad you like it
Thanks
Welcome