I’ve just published an article – Realm Data and Partitioning Strategy Behind the WildAid O-FISH Mobile Apps – that details the data architecture, schema, and partitioning strategy we used. If you’re developing a mobile app with Realm, this post will help you design and implement your data architecture.
MongoDB partnered with the WildAid Marine Protection Program to create these mobile apps for officers to use while out at sea patrolling Marine Protected Areas (MPAs) worldwide. We implemented apps for iOS, Android, and web, where they all share the same Realm back end, schema, and sync strategy.
That is a super article with a lot of great info! Thanks for posting it.
A couple of questions if you don’t mind:
I see the User object is an embedded object
class User: EmbeddedObject, ObservableObject {
@objc dynamic var name: Name? = Name()
@objc dynamic var email = ""
}
Which a great, re-usable class but the object does not exist on it’s own - only within a higher level managed object, and each User is a discreet set of data. But it appears it’s being used in the same way in a couple of classes; both in the Duty Change class as well as within the Report class. Was there not a need to tie those other parent objects back to a single user?
Also, how does the User embedded object tie back to the Realm User which is used in security - maybe I overlooked that in the article:
You’re correct that the same “user” does appear in multiple objects and documents with some duplication of data. The user is always uniquely identified by their username.
Another option would have been to use realm relationships so that multiple objects could refer to the same user object. The reason why we opted to duplicate the data is that each boarding report is a historical (possibly legal) record and represents the state of the world when it is created. If for example, an officer changed their name at some later time, we want the existing boarding reports to continue to show their name as it was when the report was created.
Back to the embedded User data… What inspired the design decision to create a User embedded object instead of just adding those properties to the main object?
The embedded aspect doesn’t seem to add any functionality - just a bit more typing when accessing the name and email properties
It was just to add a bit of extra structure. At one point, I thought that there might be some additional data associated with the user. I agree that flattening the enclosing classes wouldn’t have much of a down side.
As always, schema inertia plays a part. Even though schema changes are infinitely simpler with MongoDB and Realm (vs. relational databases) there’s still some coordination required when you have multiple developers working on iOS, Android, web, Atlas, Charts and the backend Realm app.