Summary

This prototype is an investigation into Realm that will attempt to expose limitations, edge cases, performance issues, etc... . It will also be the basis for determining what needs to be done with helper functions or wrappers to make querying, updating, saving, and deleting resources easier when using constraints across collections of objects that are visited.

Notes

• Realm does not have any bindings for React, so there's no way to reactively trigger the render method without using a store like Redux or Mobx. Or you could subscribe to change events that then force renders or setState. Probably more work and issues that way than just using a store.
• Schema must be passed in at initialization. This means that we'll want a place to store configuration json files or Schema Class. Also as I have found in the past that the path for the Realm is necessary so that you can have separate Realms on the same device for the same app.
• To have computed properties or other methods that you would typically see on an ORM model, you need to define a Class. So probably best to always define Classes for Realm schemas since we want to have that extra functionality and flexibility.
• There's no way to have cross platform support for Realm across Mobile and Web. Not without a Web SDK. Or the ability for the browser to run the Node.js SDK using something like Web Assembly. Web as a platform will have to be left out. Desktop and Mobile should be sufficient anyways.
• Non NULL, field types, default values, indexed fields, varchar/int primary key, and upserts are all supported. Not to mention referencing an object or collection of another schema type.
• All create, update, and delete operations must be done in a write transaction.
• Deletes can be done on an object or a collection, which is great for batch operations.
• Reading is lazy in Realm. Object and List properties and any other types for that matter are only read when they are accessed. A query can also be only done on one type. Hence we need to develop our own scheme using the Visitor Pattern if we want to traverse many relationships to get to a entity or aggregate result.
• Results from objects, filtered, and sorted are all live. However subscriptions need to be utilized in order to make use of the data that has changed.
• Schema Version of a realm needs to be updated if the schema ever deviates due to alterations. You can retrieve the Realm files schema version using an api method.
• In order to prevent data from being lost due to fields being deprecated, you need to define migration schemas, functions, and versions as sets in an array for each Resource/Model/Object. Probably need to expose a resource through a Model where you define the Model and it's Schema/Migration info.
• Subscriptions at an object level are just for any changes introduced from writes. Collections however can indicated additions, deletions, and updates to the collection. This will be the mechanism for triggering Mobx or Redux actions.

Things to Investigate

1. How well does Realm work with Mobx

• How does Live objects work with Realm in the context of Mobx?
• How should we provide Object and Object Collections on a Store? toJS/Serialized? Or as is?
• Is Mobx even necessary?
• Paradigm for Linear Migrations
• Visitor Paradigm for cross relationship querying/aggregation

2. ....

Conclusion

Realm is nice for Mobile and for Desktop, like say Electron. However it cannot work in a browser client. In order to make an attempt at making cross Web/Mobile/Desktop apps in JS, we need to use something else until Realm has a Web SDK, which will probably not be for another year due to the need to implement the client using IndexedDb or utilizing Web Assembly to re-use the core engine.

Solution - Use PouchDB. May not have the best React Native support. But just like react-native-web, it's still doable with maybe a hiccup or two. The performance is also pretty terrible because AsyncStorage sucks. Need to investigate PouchDb first. May decide that Realm is okay to use for Desktop and Mobile only.