Best practices / Design help with multiple partitions per user

MongoDB Atlas App Services & Realm
1

Hi! I’m currently developing a system that has the following principles:

  • Every user has their own data. One user cannot see the data from another user.
  • One user can use several devices.
  • There is data that is shared between devices. And there is data that is personal to each device.

Now, for this I created all schemas with the following field:

owner_id: 'string'

In this field I always store realm.syncSession.user.id

When I instance the “Shared” data, the config looks like the following:

const config = {
  schema: [
  ... list of schemas
  ],
  schemaVersion: SCHEMA_VERSION,
  sync: {
	user: app.currentUser,
	partitionValue: app.currentUser.id,
	newRealmFileBehavior: OpenRealmBehaviorConfiguration,
  },
};
realm = await Realm.open(config);

And when I use the Device data I do the following:

const config = {
  schema: [
  ... list of schemas
  ],
  schemaVersion: SCHEMA_VERSION,
  sync: {
	user: app.currentUser,
	partitionValue: TERMINAL_PARTITION_KEY,
	newRealmFileBehavior: OpenRealmBehaviorConfiguration,
  },
};
realm = await Realm.open(config);

Where TERMINAL_PARTITION_KEY is an unique Identifier for the device.

Now, in the realm side of things, I configured the following:

  • Choose a Partition Key: _partition (index by this field)
  • Define Permissions: No template

The _partition field is added automatically. Now, my questions are the following:

  1. Is this approach correct?
  2. Is there any way to set permissions so only the owner can read their data? Because If I use the template “Users can only read and write their own data” the template looks like the following:

read/write:

{
  "%%partition": "%%user.id"
}

Partition is only the same value as user.id only in the shared data. But in the device only it isn’t. Is there any way to check for owner_id field instead of the partition?

2

Hi. I think that a lot of what you are trying to do is much better addressed using Flexible Sync. This removes the partition limitation completely, enables document-level permissions, multiple roles, and allows for a much more “flexible” data model. I would highly recommend looking into using that and I would be happy to answer any questions you have about that.

3

Hi Tyler! thanks for the response… flexible looks really cool… thinking about using that mode… some question tho:

  1. With the permission “Users can only read and write their own data” I see the following template:
{
  "defaultRoles": [
    {
      "name": "owner-read-write", 
      "applyWhen": {},
      "read": {"owner_id": "%%user.id"},
      "write": {"owner_id": "%%user.id"}
    }
  ]  
}

I still need to write owner_id manually in every insert… correct?

  1. Should I add all the subscriptions I need right after the realm instancing or I can wait when the data needs to be read? This code:
await realm.subscriptions.update((mutableSubs) => {
  mutableSubs.add(longRunningTasks, {
    name: "longRunningTasksSubscription",
  });
  mutableSubs.add(bensTasks);
  mutableSubs.add(realm.objects("Team"), {
    name: "teamsSubscription",
    throwOnUpdate: true,
  });
});

Considering that the app would be offline first.

  1. About the preview status… how far are we from a release candidate? Is preview like “alpha” or “beta”? Is there any big changes that could impact heavily in the implementation of this mode?

Thanks!

4

Hi, sorry for the long wait. Will try to answer your questions as best as I can:

  1. You are correct, you need to pass the owner_id as a part of the object you are creating, we will not inject that in for you anymore. This is because the permissions are now much more “flexible” and you can have your permissions (a) contain mutliple fields and (b) perform more than just “equality” checks, you can have a permission that has something like this: { level: “manager”, age : { $gte: 100 } } which is pretty powerful.

  2. You can do either one. We do recommend trying to limit the number of subscription changes you make but you can continue to change your subscription set and we will handle it. Just be sure to clean up stale subscriptions you no longer want to sync on.

  3. I can’t commit to anything in terms of a timeline but I do not expect any big breaking changes as we would like to encourage people to develop applications using flexible sync.

Let me know if you have any more questions,
Tyler