Hello, I’m new to using Realm and I’m creating an app that will be used by multiple clients. In terms of the database, I’ve seen that there are several strategies, such as:
Single database with schema: In this strategy, a field called tenant_id is added, but I would like each user to only be able to view and synchronize the information of the client they belong to.
Database per tenant: In this approach, I believe I should have a Flexible Sync for each client, and I would need a mechanism to determine which client each user belongs to.
Has anyone had any experience with these strategies? Are there any limitations in terms of service for either strategy? Is there any other strategy that would allow me to achieve this?
Hi @Fabian_Eduardo_Diaz_Lizcano!
Using Atlas MongoDB gives you a huge flexibility to design your app schema on a way it will be convenient for your goals. Before to have a decision you may take in consideration the following questions:
- How complex is the schema? Is it one or two collections or more.
- Do you have any data that you want to share between the clients? (Something like content information, nomenclature data, statistics, catalogs)
- Is it allowed one user to belong to more that one clients and to use the same account? Do you plan to have any UI that will display information from all the clients/companies that the user belongs to? Or you will design the UI for one client only. Then in case you support multi-clients per user you will rather request the user to select the client’s company name on the login screen.
- Are you going to make reports, charts based on the data of all the clients?
In case you will need some cross client data access and the schema is not so complex I would recommend you to use the same app service and configuring read/write rules per client.
But if you are going to have more than two-three collections per client configuring the rules may appear to be complex. If you don’t need any cross client data access then it is better to create app services per client/company. In this case you may need another app service which can allow anonymous access, where the user name could be associated to the company and it’s app service id. These mappings could be updated during the sign up process, where the users select the company name that they belong to. Once you get the app service id, you will be able to login to a dedicated app service for a client.
Feel free to write if I’ve missed something or please share if it helped to you finding the better approach.
1 Like
Hi @Desislava_St_Stefanova,
Thank you for all of your questions, as they help me determine which option to use. In response to some of your questions:
- I think I will have multiple collections.
- I do not want to share information between companies, as I would like to keep everything separate for security reasons, to avoid accidental information leaks between companies, as I have user personal data.
- It is possible for the same user to access several companies, so I effectively need to store this somewhere and, once the user logs in, ask them to indicate the company they want to access. If I use this path, it may soon be complex to make subscriptions since my application is running and I would need this to create the Realm instance; I add that I am using cubic as a state management pattern and I would like to be able to recover the realm instance with RepositoryProvider.
- I need to create reports, but these are seen by each company individually.
- Additionally, I would like to measure the costs that each company incurs on the flexible sync service.
Thank you very much for your help.
2 Likes