Building a Mobile Chat App Using Realm – Data Architecture

#User Object

The User class represents an application user:

1
class User: Object {
2
   @objc dynamic var _id = UUID().uuidString
3
   @objc dynamic var partition = "" // "user=_id"
4
   @objc dynamic var userName = ""
5
   @objc dynamic var userPreferences: UserPreferences?
6
   @objc dynamic var lastSeenAt: Date?
7
   let conversations = List<Conversation>()
8
   @objc dynamic var presence = "Off-Line"
9
}

I declare that the User class top-level Realm objects, by making it inherit from Realm's Object class.

The partition key is a string. I always set the partition to "user=_id" where _id is a unique identifier for the user's User object.

User includes some simple attributes such as strings for the user name and presence state.

User preferences are embedded within the User class:

1
class UserPreferences: EmbeddedObject {
2
   @objc dynamic var displayName: String?
3
   @objc dynamic var avatarImage: Photo?
4
}

It's the inheritance from Realm's EmbeddedObject that tags this as a class that must always be embedded within a higher-level Realm object.

Note that only the top-level Realm Object class needs to include the partition field. The partition's embedded objects get included automatically.

UserPreferences only contains two attributes, so I could have chosen to include them directly in the User class. I decided to add the extra level of hierarchy as I felt it made the code easier to understand, but it has no functional impact.

Breaking the avatar image into its own embedded class was a more critical design decision as I reuse the Photo class elsewhere. This is the Photo class:

1
class Photo: EmbeddedObject, ObservableObject {
2
   @objc dynamic var _id = UUID().uuidString
3
   @objc dynamic var thumbNail: Data?
4
   @objc dynamic var picture: Data?
5
   @objc dynamic var date = Date()
6
}

The User class includes a Realm List of embedded Conversation objects:

1
class Conversation: EmbeddedObject, ObservableObject, Identifiable {
2
   @objc dynamic var id = UUID().uuidString
3
   @objc dynamic var displayName = ""
4
   @objc dynamic var unreadCount = 0
5
   let members = List<Member>()
6
}

I've intentionally duplicated some data by embedding the conversation data into the User object. Every member of a conversation (chat room) will have a copy of the conversation's data. Only the unreadCount attribute is unique to each user.

1
exports = function(changeEvent) {
2
   if (changeEvent.operationType != "insert") {
3
      console.log(`ChatMessage ${changeEvent.operationType} event – currently ignored.`);
4
      return;
5
   }
6
7
   console.log(`ChatMessage Insert event being processed`);
8
   let userCollection = context.services.get("mongodb-atlas").db("RChat").collection("User");
9
   let chatMessage = changeEvent.fullDocument;
10
   let conversation = "";
11
12
   if (chatMessage.partition) {
13
      const splitPartition = chatMessage.partition.split("=");
14
      if (splitPartition.length == 2) {
15
         conversation = splitPartition[1];
16
         console.log(`Partition/conversation = ${conversation}`);
17
      } else {
18
         console.log("Couldn't extract the conversation from partition ${chatMessage.partition}");
19
         return;
20
      }
21
   } else {
22
      console.log("partition not set");
23
      return;
24
   }
25
26
   const matchingUserQuery = {
27
      conversations: {
28
         $elemMatch: {
29
         id: conversation
30
         }
31
      }
32
   };
33
34
   const updateOperator = {
35
         $inc: {
36
         "conversations.$[element].unreadCount": 1
37
         }
38
   };
39
40
   const arrayFilter = {
41
      arrayFilters:[
42
         {
43
            "element.id": conversation
44
         }
45
         ]
46
   };
47
48
   userCollection.updateMany(matchingUserQuery, updateOperator, arrayFilter)
49
   .then ( result => {
50
      console.log(`Matched ${result.matchedCount} User docs; updated ${result.modifiedCount}`);
51
   }, error => {
52
      console.log(`Failed to match and update User docs: ${error}`);
53
   });
54
};

1
class Member: EmbeddedObject, Identifiable {
2
   @objc dynamic var userName = ""
3
   @objc dynamic var membershipStatus: String = "User added, but invite pending"
4
}

1
let realmConfig = user.configuration(partitionValue: "user=\(user.id)")
2
return Realm.asyncOpen(configuration: realmConfig)

1
case "user":
2
      console.log(`Checking if partitionValue(${partitionValue}) matches user.id(${user.id}) – ${partitionKey === user.id}`);
3
      return partitionValue === user.id;

#Chatster Object

Realm Sync doesn't currently have a way to give one user permission to sync all elements of an object/document while restricting a different user to syncing just a subset of the attributes. The User object contains some attributes that should only be accessible by the user it represents (e.g., the list of conversations that they are members of). The impact is that we can't sync User objects to other users. But, there is also data in there that we would like to share (e.g., the user's avatar image).

The way I worked within the current constraints is to duplicate some of the User data in the Chatster Object:

1
class Chatster: Object {
2
   @objc dynamic var _id = UUID().uuidString // This will match the _id of the associated User
3
   @objc dynamic var partition = "all-users=all-the-users"
4
   @objc dynamic var userName: String?
5
   @objc dynamic var displayName: String?
6
   @objc dynamic var avatarImage: Photo?
7
   @objc dynamic var lastSeenAt: Date?
8
   @objc dynamic var presence = "Off-Line"
9
}

I want all Chatster objects to be available to all users. For example, when creating a new conversation, the user can search for potential members based on their username. To make that happen, I set the partition to "all-users=all-the-users" for every instance.

A Realm Trigger handles the complexity of maintaining consistency between the User and Chatster collections/objects. The iOS app doesn't need any additional logic.

An alternate solution would have been to implement and call Realm Functions to fetch the required subset of User data and to search usernames. The functions approach would remove the data duplication, but it would add extra latency and wouldn't work when the device is offline.

This is how the iOS app opens a Chatster Realm:

1
let realmConfig = user.configuration(partitionValue: "all-users=all-the-users")
2
return Realm.asyncOpen(configuration: realmConfig)

For efficiency, I open the Chatster Realm when the user logs in and don't close it until the user logs out.

The Realm sync rules to determine whether a user can open a synced read or read/write Realm of User objects are even more straightforward.

It's always possible to open a synced Chatster Realm for reads:

1
case "all-users":
2
   console.log(`Any user can read all-users partitions`);
3
   return true;

It's never possible to open a synced Chatster Realm for writes (the trigger is the only place that needs to make changes):

1
case "all-users":
2
   console.log(`No user can write to an all-users partitions`);
3
   return false;

#ChatMessage Object

The third and final top-level Realm Object is ChatMessage:

1
class ChatMessage: Object {
2
   @objc dynamic var _id = UUID().uuidString
3
   @objc dynamic var partition = "" // "conversation=<conversation-id>"
4
   @objc dynamic var author: String?
5
   @objc dynamic var text = ""
6
   @objc dynamic var image: Photo?
7
   let location = List<Double>()
8
   @objc dynamic var timestamp = Date()
9
}

The partition is set to "conversation=<conversation-id>". This means that all messages in a single conversation are in the same partition.

An alternate approach would be to embed chat messages within the Conversation object. That approach has a severe drawback that Conversation objects/documents would indefinitely grow as users send new chat messages to the chat room. Recall that the ChatMessage includes photos, and so the size of the objects/documents could snowball, possibly exhausting MongoDB's 16MB limit. Unbounded document growth is a major MongoDB anti-pattern and should be avoided.

This is how the iOS app opens a ChatMessage Realm:

1
let realmConfig = user.configuration(partitionValue: "conversation=\(conversation.id)")
2
Realm.asyncOpen(configuration: realmConfig)

There is a different partition for each group of ChatMessages that form a conversation, and so every opened conversation requires its own synced Realm. If the app kept many ChatMessage Realms open simultaneously, it could quickly hit device resource limits. To keep things efficient, I only open ChatMessage Realms when a chat room's view is opened, and then I close them (set to nil) when the conversation view is closed.

The Realm sync rules to determine whether a user can open a synced Realm of ChatMessage objects are a little more complicated than for User and Chatster objects. A user can only open a synced ChatMessage Realm if their conversation list contains the value component of the partition key:

1
case "conversation":
2
   console.log(`Looking up User document for _id = ${user.id}`);
3
   return userCollection.findOne({ _id: user.id })
4
   .then (userDoc => {
5
   if (userDoc.conversations) {
6
      let foundMatch = false;
7
      userDoc.conversations.forEach( conversation => {
8
         console.log(`Checking if conversaion.id (${conversation.id}) === ${partitionValue}`)
9
         if (conversation.id === partitionValue) {
10
         console.log(`Found matching conversation element for id = ${partitionValue}`);
11
         foundMatch = true;
12
         }
13
      });
14
      if (foundMatch) {
15
         console.log(`Found Match`);
16
         return true;
17
      } else {
18
         console.log(`Checked all of the user's conversations but found none with id == ${partitionValue}`);
19
         return false;
20
      }
21
   } else {
22
      console.log(`No conversations attribute in User doc`);
23
      return false;
24
   }
25
   }, error => {
26
   console.log(`Unable to read User document: ${error}`);
27
   return false;
28
   });