MongoDB.live, free & fully virtual. June 9th - 10th. Register Now MongoDB.live, free & fully virtual. June 9th - 10th. Register Now

Realm for non-client data

If an app is mostly client data that is synced, and has some data that should not be synced but needs to be queried, is it reasonable to stick with one database - Realm - for the latter.

For instance, let’s say I have a product catalog I don’t want synced on my clients, but I want to be able to query. Does it make sense to use Realm for this, and is there a good way to query the Realm server directly to make an API?

Realm is live-sychronized database so there’s no way to only store Realm data in the cloud (currently). It will always be sychronized - one copy locally and the other copy in Realm Cloud.

Once MongoDB Realm becomes and actual thing, that may open up additional options but that’s a long ways off currently.

If you have data that should be available to all clients but not changable by the client, you may want to bundle it with your app as a Realm file, or if it’s a lot of data, look to another source. I would suggest looking at Firebase for online only storage

Hey @crystaln - there is no problem using multiple realm files in a single app, one for sync, and one for local, you simply open two and pass them different configurations - a SyncConfiguration for the former, a regular Configuration for the latter. Be sure to name them different variables that make sense to you - ie. localRealm and syncRealm.

I would not say MongoDB Realm is a long way off - we are pretty close actually.

1 Like

Thanks Ian. I assume by “local” you mean local to a device. I’m referring to data like a product catalog, or the entire list of user generated content, that would be on the server.

Let’s say I have:

  • User generated content of other users, which are queryable
  • Product catalogs

My app will have something similar to both of those.

For UGC, my understanding is a client can query those relationally and fetch only matching records, so Realm makes sense for that.

For the product catalog, would it be possible to do the same, and just import the data using a pseudo client or server API, then do searches using Realm client API?

I don’t think I want all users to have the full database. That seems like a privacy, size, and performance issue, tho realistically it is feasible in the short term, it seems like not a great design.

@crystaln Ah I see, yes by “local” I meant non-synced. I understand now.

You can separate different types of data into different full-sync realms and open each with a different realm URI path - for example, /productCatalog and /~/userContent - productCatalog will be a global realm that is read-only, /~/userContent is a realm that the user has read-write permissions to

https://docs.realm.io/sync/using-synced-realms/designing-an-architecture-with-multiple-realms
https://docs.realm.io/sync/using-synced-realms/setting-up-your-realms
https://docs.realm.io/sync/using-synced-realms/access-control/path-level-permissions

As long as you are not storing images in the productCatalog it should be fine to sync that down to the client - we have users that have millions of objects in a product catalog - no problem.

Of course, I can understand for privacy concerns in other use cases you may not want to sync down all that data just to query it locally. To accomplish this you’ll probably need to stand up some web endpoint that runs the query when called by the client. In the future MongoDB Realm product, you will be able to call a function from the client without having to standup a web server.

https://docs.mongodb.com/stitch/functions/

1 Like

@Ian_Ward I am really confused by what you are suggesting here. Maybe I am misinterpreting what you’re suggesting but saying this

it should be fine to sync that down to the client - we have users that have millions of objects in a product catalog - no problem.

leads one to think there is some control over how much data is ‘sync’d down to the client’ which isn’t really how it works. No? Isn’t it all or none?

As you know, Query/Partially sync’d realms are not going to be supported and are going away. Any Realm stored in the ‘cloud’ is a/will be a Fully Sync’d realm - that means ALL of the data is stored both locally on the device as well as in Realm Cloud.

If you have 100Gb of products in your product catalog, and an iPhone with 32G Capacity, what would happen?

Of course, I can understand for privacy concerns in other use cases you may not want to sync down all that data just to query it locally.

Is that possible with a fully sync’d realm? How does one ‘not sync down all that data’?

To accomplish this you’ll probably need to stand up some web endpoint that runs the query when called by the client.

Is that documented somewhere as it would be invaluable when dealing with very large datasets (as we are). Is there something in the Swift SDK that allows a query to be run against a Realm without actually being connected to that realm?

Oh and

I would not say MongoDB Realm is a long way off - we are pretty close actually.

Pretty close to you and pretty close to us are way different things. We have an app that we want to bring to market but because of the unknown timeframe and changes, we have to hold off - and have been holding off for 6 months so far. Another year is 18 months and thats a ‘long way off’.

How would you implement something like Facebook’s visibility settings, where a post can be visible only to certain people or even just to me? What if I as a user decide to unpublish an object?

I’m also confused by the apparent deprecation of query-synced realms, and this is making me wonder whether this is an appropriate platform for my application as I start planning the schema.

Let’s say as you suggest I have a realm for public chats. What if a user gets banned from one public chat? They still have all the data because the realm is fully synced, and it seems like there is no way to control different levels of permission by user, so I guess they probably have full write privileges too. So every chat needs to be in a different realm. Oh and any admin or otherwise privileged data needs to be in yet another realm, what about private chats, and anything else with different permission levels. None of the data can be linked easily, and I need to manage figuring out which realm all the data is in. That’s a bit of a silly example, however the idea that in order to separate access control to different data, I need to separate the data into essentially different database, seems really poor.

Without query based sync and object level permissions, I don’t understand how Realm can be used for any complex application, where view and edit privileges are not so simple.

Even your team example in the “App Architecture With Full Sync” article seems contrived. Isn’t there some data that everyone on the team shouldn’t see? Can’t some people on the team edit some data and others edit other data?

I’m really struggling to understand how Realm with Full Sync doesn’t make my life even harder than API based apps.

Am I missing something? Should I just use Firestore, despite its query and search limiitations?

Yes, we are aware of how valuable query-based sync is, but unfortunately, the performance was incredibly poor and after careful analysis, no amount of iterative improvement could get it to the level we wanted - so we decided to remove it in the new product and then rebuild it from the ground up to be scalable.

I would encourage you to take a look at our published roadmap, not only for a timeframe of the launch of MongoDB Realm but also for the re-launch of something akin to query-based sync

Building a chat app is complicated with our without Realm, but using full-sync requires a level of backend complexity (copying chat objects around to different realms, keeping metadata on which objects belong to which realms) that most people opt for a 3rd party provider.

The original post was on a product catalog or inventory application - which we have done multiple times with full sync. If your product catalog is 100GB, that will not work, and you will need to think of a way to partition that data into smaller realms or find another solution, such as a GET endpoint + query parameter or the command pattern.

Yes, the original post was a simplified example for my application. Realm without query sync seems too limiting to serve as the primary database for any application I am working on (or frankly any non-trivial application I can think of). There are already cases where it’s going to immensely complicate things for me, and I’m certain that I will feel my hands are tied in the future.

I’m frankly frustrated that I delved so far into exploring Realm before understanding this and wish you made the fact that the product is going through such a large transition more clear. These limitations seem critical to share up front. Simply saying “query based sync is not recommended” is an extreme understatement as to the impact of this on new developers.

I look forward to your relaunch of something like query based sync. Realm + MongoDB seems like a killer combo. Sadly I can’t develop on those promises.

Thanks for your answers here.