We have started to develop a multi-tenant application. Each tenant will have a different database and the main database for users and roles. I have tried the multi-tenancy strategy and can bind different schema at run time.
Now the problem is each tenant will have common models like people, interactions, etc but the columns in each can differ. Also, we can add new tables. Is it possible to create model columns dynamically based on the requesting tenant and also controllers for new tables dynamically?
Is there an example application on this? Any help is greatly appreciated.
Related
I am working on an admin dashboard for 5 services using Laravel. It is really complicated to do so in admin. We, for example, want to show a list of transactions with user name for each row. Both of the users and transactions tables are in different databases. We had to make another request to fetch the user name form the other service.
I am wondering about when it comes to statistics and writing complex queries to get data from all of theses services in a report. How can I handle such a case?
Can I make multiple connections to the databases with the admin dashboard project?
Is there any available pattern that facilitate the work for me?
Thanks
Let's assume below scenario.
There can be multiple tenants. Each tenant offers different services based on their business to clients. Depending on the size of the client, they may have their own database as well (ex:- Large clients prefer their data to be isolated).
Arranging tenants to fulfill above scenario is possible with the AspNetBoilerplate out of the box.
Then comes the customers who consumes various services provided by multiple businesses (tenants). There is a single mobile app for these customers. Once they login, they should be able to get services from any tenant unless a tenant has blocked a user.
Note that the point here is these customers are NOT registering for each tenant separately.
What are my options to get this setup done properly using AspNetBoilerplate? My initial thoughts are;
1) Have a separate table - MyCustomers - All mobile users will get authenticated against this table. For this should i create a separate auth pipeline ?
2) Current AspNetBoilerplate demo; you choose the tenant and login. But in my case; they log in and they will choose a service provider (tenant). At this point;
Should I create a new user automatically IF the selected tenant is in a different database (For large businesses having their own database)?
If the selected service provider is a small customer, who are in the same database differentiated with a TenantId I will have to additionally have a --> (many) relationship maintained so when a new service is selected a new record goes to this table?
At the end of the day, MyCustomers will only be using a single mobile app to get any service from any business after they login. Once they login, they should have access to all tenants (unless they are blocked).
Is there a better way to do this using AspNetBoilerplate existing architecture?
I have just developped a Human Ressource WebApp in Laravel.
So in this app, I have my user database.
Now, I have 2 old apps, that I'm about to rewrite / Migrate to Laravel.
The first one is to manage employee payments.
The second app is for monitoring my salesforce in field.
So, Basically, I will basically rewrite them.
My Question is about architecture. I will develop those 2 apps separating APIs in Lumen / Laravel for each app, individually, and then writing clients in Angular2.
I will use OAuth2.0 to set authorization and scopes between apps.
Now, My indecision resides on Database part.
Should I keep database separated, include database in the same schema, or how should I deal with my databases.
Today, I have 1 DB per app, but also, I have redundancy in users: Each App works with the same users, and so duplicate this info.
Right now, When User is created in App1, it calls APIs to create it in app2 and app3. This is not so nice, IMHO.
So, I think I would like to have a single User Database, but I don't really have experience of that:
should I extract User's info in a central database for all users, should
should I keep User's info duplicated between my DB?
if I keep it in 3 differents DB, how should I make JOINs, transactions, Foreign Keys, etc.
I know there is not 1 answer, it depends of what I want, but this is also my problem, I don't know which question should I be asking to make my decision???
It is important to mention that I don't have so much traffic, max 1000 users, and they all belongs to my enterprise, it will not increase to much. So, really, make a scallable app should not be my priority right now.
Any Advice will be appreciated!!!
Since you have shared databases between your apps, the common practice is to have it in the same Laravel/Lumen app.
The way you can achieve this is separating the apps inside route groups, namespacing the controllers hierarchies of each app and declaring inside each model the connection you will be using for this model.
This way you can use the same DB connections for all of your apps, and share the same data without the need of duplicating it.
I am working on a multi-tenant app in MEAN stack, in which user will signup and using their business names I will create an account(sub-domain) for them : abc.example.com.
So what approach should I use for this multi-tenant app?
A single database in which each client have their specific collection.
Or, should I maintain separate db for each user signup ?
In my application, I will be having 3-4 fixed collections for each user.
So out of these two which will be more beneficial and If you can also provide any example to support your answer ?
There are a lot of criteria that you need to look into before switching to the separate database per tenant model
Tenant volume, the number of tenants in the system
Volume of data per tenant
Compliance requirements like HIPAA that you have to adhere to the tenant
Geographical diversity, one tenant in USA and other tenant in Asia etc...
Both the options are fine, but once you are not able to predict beforehand the values for the points 1 through 3, you can just use the same database with a tenantid column and later scale out to per tenant database with ease.
If you have some values for the above mentioned points, the community here will be able to guide you better.
We are upgrading a single-tenant application to a multi-tenant (separate DB for each client) SaaS application. My responsibility is to design the tenant provisioning part. I am thinking of the following steps.
While our admin will install our software, one DB should always be get created.Argument for this step is that Admin will install the software only when at least a tenant comes up. So, creation of a single db as part of installation of our software should make sense.
The common meta data will be stored in a common place. We are thinking of using ZooKeepar to store the common meta data.
Each tenant will be given a subdomain. For example www..samplaTenent.com . This tenant_id will be extracted from the URL in each request and will be used to identify the particular tenant and respective DB.
If more tenants need to be provisioned, the admin will create a new DB instance through user interface.
Technology used:
Java 6
Struts Framework
MS SQL
Now, I would like to get expert opinion about the proposed solutions. Is there any other way by which we can build a robust, secure and scale-able SaaS application?
Thanks.
IMHO, I would suggest that you should have a sibgle code base that can handle the multi-tenancy aspects be it configuration of db, settings per tenant etc.. I am not aware of the code base that you have now. Hence, you can make the provisioning part as follows,
You provision a new tenant by getting all the prerequisite info. You can generate the URL for this tenant automatically or allow the tenant to choose one in the latter a validation has to be made for the URL and the tenant combination.
On this step completion, you can have some scripts at the server that clones a master code base and rolls out a new tenant specific db. So things are automated.
The next step will be to store the tenant db and the app details in your common or shared db so that when a tenant logs in, you can redirect him to his URL. The db details will be required if you want to handle all of the tenant and his user authentication from the main app.
The main perceived advantage of having a single code base is that the customization and configuration can be in one place with ease of code maintenance and bug fixing or enhancing. Though this may not work for all scenarios, this is what I feel more suitable option on the long run.
Please share your thoughts or post additional queries that you may have on multi-tenancy.