Thanks for the additional information. I will match your big question with a big answer
This meanders a little but really comes down to whether there is a need to decouple the data, a and if so, at what cost.
(skip to TL;DR to avoid this wall of text)
After coding for 45+ years now, I ‘get’ the concept and purpose of decoupling your project code from your datasource, and have done it many times.
Back in the day, when we had different flavors of SQL, it made sense. However, in many cases today that concept is very difficult to put into practice unless you make everything as ‘generic’ as possible when then bypasses the features of the database you’ve selected.
In many cases a database is not just a dumb datastore - databases are selected because of how it works with that data and the additional features that database provides - like Realms “live” objects.
I am intimately familiar with Firebase as well as Realm so allow me to provide an example.
Firebase and Realm are radically different. Right up front, Realm is an offline first database which provides syncing. Firebase on the other hand is a very much online-first database with some offline persistence (to handle brief interruptions in connection status)
Firebase has no concept of ‘live’ objects - the data is static unless there’s an update from the server (or an event). Whereas Realm objects are live and dynamic, always reflecting the status of the underlying data regardless of where that change came from.
So, what does that mean?
If you’ve selected Realm as your database and craft an app around the capability of “live” (i.e. dynamic) objects, you’re going to be hard pressed to adapt that to Firebase as just doesn’t do that. It would require total re-think of the app logic as well as a re-write of pretty much everything dealing with that data.
More importantly, when designing an app (with Realm), that design will leverage features like forward and inverse relationships, embedded objects, and the queries, objects and schema will reflect that functionality. Firebase doesn’t have relationships, schema (it’s schema-less!) or even objects! It’s a totally different NoSQL approach to working with data. Again, it would require a massive do-over.
My messaging is this - if separation of code from the underlying database is a requirement, it can be done. Look at Apple’s CoreData - it can be backed by a number of underlying sources. But… look at CoreData, it’s a massive effort! I don’t think I would want to build entire persistance framework into my project ‘just in case’ we switch data sources - even at that, which datasources? There are a lot.
For clarity. IMO Firebase is an awesome product, so is Realm. They serve different purposes and have radically different implementations.
I have transitioned many projects from and to a variety of databases and in general, if the datasource is changed, no matter how much effort was put into decoupling it, it’s a massive re-write and an many cases starting over; re-thinking everything about that data, relationships etc. Even though Realm is backed by NoSQL, the Realm front end is a very different approach to NoSQL than say Firebase Firestore is.
My suggestion is to think about the features you want and select a database based on that. Then, create a basic To-Do app - keep it simple, implement Adding and persisting ToDo’s, edit them and delete. Create a ‘relationship’ from one to do to another. Then, port it to a different database.
That process is often very revealing with a minimal amount of effort and time. It will help you gauge the complexity of the layer needed to decouple your code from the datasource or if you want to leverage the features (Realm) offers.
Yes. That’s one of the features Realm offers. If you can do without that feature or implement it in some other fashion, that would make it a bit easier to move to another platform if necessary.