Multi-client Web API Structure

Asked

Viewed 767 times

9

I’m in the following situation:

I have a web application that accesses the data through a C#Webapi. I need to apply the concept of multitenancy in order to allow my application to be accessed by multiple customers and for each customer to access their database individually.

Faced with this need, I researched in Sopt and found the following questions:

Web application for multiple people

Databases for different customers

As for the concept I understood, but my doubt is about deploy my Webapi and what would be the best practice:

Deploy and host a single instance of the API on IIS (and redirect access to the database via code)?

Or I should perform the Deploy individualized, ie host numerous instances of the API in IIS, each accessing its database?

In case the second option is the most viable, is there any way to make this multiple deploy more automated? Is there any cloud feature that enables this deployment scheduling (Azure, Amazon, etc...)?

  • Clarification - when you say 'each one accessing your database', you mean that each customer will have their data stored in unique database instances, or was just an expression (data from multiple clients in the same database)?

  • @Meiaesquerda, is exactly that, each client with a unique database instance. To get an idea, currently our need is for around 100 customers.

  • Its cost of maintaining the structure will be considerably higher. Also imagine that whenever you change the template the patch should be applied in 100+ instances - this is if you don’t allow banks to be in different versions of patching.

  • @Meiaesquerda, really, the intention of this question is to raise what would be the best practice and what is most used or how the community acts in this type of situation.

  • A question. Whenever there is an update all customers should be updated?

  • @Randrade, here comes the famous one... Today yes all will have the same update, more can occur situations where there is something specific, the way we work today this is solved programmatically with Patterns and object orientation.

  • This system uses the model Saas (Software as a Service)?

  • @Randrade, yes, our initial idea is this.

Show 3 more comments

1 answer

5


The question is a little wide. I will try to provide some parameters that will help you choose your ideal scenario.

  • Individual databases ensure data isolation (one user of one client will not see another’s data). On the other hand, your structure maintenance cost will be considerably higher - imagine that whenever you change the model the patch should be applied in 100+ instances. This scenario becomes even more complicated if you allow banks to be in different versions of patching.
    Additionally you will need a repository exclusively to provide tenancy Scope - a bank where customers and their users are registered.

  • A shared databases simplifies its patching process, but needs a greater effort to ensure isolation - search interfaces must at all times take into consideration the customer to which the user is associated.

  • To API can have its scope parameterized without the need for hundreds of deploys. Some usage policies that may be useful are definition of scope by credentials, where the scope of data to be used is set after the user’s Sign-in, or by domain, where so much cliente1.api.empresa.br when cliente2.api.empresa.br are mapped to api.empresa.br, and internally your API chooses the data scope according to the accessed subdomain (example).

  • In the cited example of scope definition by domain, do I have to do this check in the API Startup? and use subdomain data to validate which client is accessing?

  • @Julioborges This evaluation should happen for every call to the API. I don’t know your model, but if a user has privileges in two or more domains then you will need to store your details in the database tenancy Scope.

Browser other questions tagged

You are not signed in. Login or sign up in order to post.