I am looking for best method to create application which are connected to different databases based on client
So basically it is a multi tenancy model for an android app (enterprise use)
Deploy the same app to different customers but connect to different database for different customer.
The things I thought about is making a key and for each customer the key varies and a correct webservice will be contacted based on the key ( individual webservices for each client)?
Has anyone done something similar? What is the best method to approach this.
Thanks
In any case you will require a server API (webservice, REST or similar) to connect your Android app to the database. Assuming your database is available through such an API, there are two options.
-
Design the database & server to serve multiple customers (multi-tenancy). With this your server API will expect the tenancy selection to happen on a per-request basis (e.g. a HTTP header or a query attribute), or at session initialization (e.g. when the user logs in).
REST example:
<code># get customers for tenant ABCGET example.com/api/customer/?tenant=ABC# create a new customer for tenant ABCPOST example.com/api/customer/?tenant=ABC</code><code># get customers for tenant ABC GET example.com/api/customer/?tenant=ABC # create a new customer for tenant ABC POST example.com/api/customer/?tenant=ABC </code># get customers for tenant ABC GET example.com/api/customer/?tenant=ABC # create a new customer for tenant ABC POST example.com/api/customer/?tenant=ABCObviously, your server will have to make sure clients can only access data that they are allowed to. Instead of passing the
tenantas a query parameter, it can also be passed as an HTTP header or set as part of the session. -
Create different API endpoints, with each endpoint connecting to a different database. In this case your Android app needs to be configurable in some manner, e.g. by requesting the API endpoint to use from (say) the central login server.
Example:
<code># Request API endpoint to use# we assume the configuration response to contain the apiUrl parameterapiUrl = GET login.example.com/configuration/?user=XYGET <apiUrl>/customer/...</code><code># Request API endpoint to use # we assume the configuration response to contain the apiUrl parameter apiUrl = GET login.example.com/configuration/?user=XY GET <apiUrl>/customer/ ... </code># Request API endpoint to use # we assume the configuration response to contain the apiUrl parameter apiUrl = GET login.example.com/configuration/?user=XY GET <apiUrl>/customer/ ...The server will run multiple endpoints, e.g.
abc.example.comorxyz.example.comfor tenants ABC and XYZ, respectively. So the actual API calls will look like this:<code># get customers for tenant ABCGET abc.example.com/customer# get customers for tenant XYZGET xyz.example.com/customer</code><code># get customers for tenant ABC GET abc.example.com/customer # get customers for tenant XYZ GET xyz.example.com/customer </code># get customers for tenant ABC GET abc.example.com/customer # get customers for tenant XYZ GET xyz.example.com/customer
As always with engineering decisions, there are a couple of trade-offs to consider:
-
Data secrecy/segregation v.s. operation efficiency. Multitenancy is relatively simple to solve in a database (add a
tenantfield or similar to at least the core tables of your data model, or every table for that matter). Operating one database is easier than operating many. However, in some industries you may need to keep data in separate databases. -
Declarative v.s. explicit client code. In the first example, your app client needs to be aware of the actual tenant it runs for to be able to send the right parameters to the server. In the second example, all that the app client needs to know is the endpoint’s URL to connect to.
Note that the first and second example could also be mixed:
-
In the second example, the same database can be used for different customers. To do so, run a front-end webserver that adds a tenant header to the HTTP request depending on the API endpoint.
-
In the first example, the server could route the request to a different database depending on the tenant selection. Some frameworks make such routing trivial, e.g. Django has a database router built-in.
4