I am loving what I am seeing and using when it comes to Realm, but I having a bit of hard time wrapping my head around some structure and hope the community can help provide some insight.
Lets say you are building a cash register app. To place everything in a single realm and sync everywhere sounds great, but can become very bloated (thing about a years worth of register transactions multiplied by the number of customers using your application) and every time someone logs into a new device, the entire database would have to be downloaded.
I then thought about 2 realms, 1 for all the settings which is synced everywhere and 1 with all the transactions (using query based synchronization) where I could sync only the past month of transactions and require online access to go back further. After reading the docs though (correct me if I am wrong) I believe subscriptions only live as long as the app is open. If the app closes, I would have to re-download the past months worth of data. Additionally, I was being lead to believe (again, correct me if I am wrong) that query based synchronization is very resource intensive, so if I ended up having hundreds or thousands of clients using this, am I causing myself more issues then necessary?
Is there something missing or a better way to handle this scenario?
That is a depreciated feature. MongoDB Realm is a FULL sync database. There may be a change to that in the future but plan accordingly. See the MongoDB Realm Docs and the Sync section. The old Realm docs are depreciated and no longer apply.
Realm is not well suited as a multi-tenant database within one Realm (your use case may vary). So one option is to have each customer with their own realm (or realms), significantly reducing file size.
As per above, that’s not currently an option.
The good news is that Realm is pretty space efficient and thousands of objects are easily handled. Realm does have a shouldCompactOnLaunch feature which can reduce the size footprint.
However, I would suggest another strategy; allow the user to archive old data which would remove it from the file, but still provide access. For example give the user the ability to purge data older than say 5 years but have it stored in a local file that could be accessed later if needed.
When using sync, I can define a partition id. This is how I intend to separate tenants. Its honestly one of the best solutions I have seen for a multi-tentant cloud database (unless of course I am missing something).
Client archive options are a good idea, but most people will likely not use it unless forced to do so. Meanwhile, I (as a mobile developer) would be responsible for the data transfer rates of these large databases to each device. I am just concerned about an app not properly thought out causing large database utilization fees.
When using MongoDB Realm sync, that’s not optional; you must define and use a partition.
Keep in mind this is not a multi-tenant situation. It’s multi-user. The users will all be managed in the same way, any permissions will apply to all users and they will be using the same app space.
As long as those requirements meet you’re use case, you should be good to go.
Thats could be something you build into the app. ‘Data is automatically archived after 3 years’ or whatever timeframe/size fits the best.
Keep in mind that sync’d data isn’t resynch’d - so the data transfer would be the initial one (if there is any pre-populated data), and then only future changes. So if for example, a transaction references a client and and item that already exist, the client and item don’t resync - just the transaction data.