Hello, I would like to ask about the possibility to apply Field-Projection while synching from the client side using the Swift using the SDK.
Is there a recommended or standard way to do this using Flexible-Sync? For example. when adding a Subscription, we did not find a way to additionally project on the fields we would like to load in the client side. We would like to prevent downloading all languages.
For our use case, each document has a field title that is a document with multiple languages. For example: title.en, title.es.
However, since our content is not yet localized, we are somehow flexible in the architecture we choose to take in the future.
Some things we considered:
Filtering the fields in SyncRules: This could work, however we prefer not to mix responsibilities here, if someone has access to the document, they should have access to all languages.
Splitting each language to a separate document: This is the most efficient way, however will add a ton of complexity when linking objects together, as they are done by ObjectId.
Having a Translation Collection where it only contains text translated. And in the parent, having a One-to-One link, simply ObjectID. Then title.en would be the ObjectID of the object holding the English translation. Then in the front-end, we would subscribe to the documents (for example: Products, and to the collection Product_Localizations with a query of course to match them, depending on the device’s localization.
Any ideas, suggestions or considerations from the Realm team?
Thank You!
Hi, this is not possible at the moment with device sync but something we have in our long-term roadmap.
I would suggest you go with the simpler approach and just send down all of the data and use what you need. Is your only concern there the size of the realm / data transfer? If so I would make sure that is a problem before you design a complex system to avoid it. We generally find that having a bit of extra data in the realm file is not an issue and generally one of the benefits of local-first development (you have whatever you need whenever you need it) .
We want to be flexible for the future but not over engineer it for now. So if it will be possible to project in the future, then it makes sense to keep everything in one Document.
However, from an Architecture perspective, it seems lighter to have the Translations in a separate collection (even if projecting is possible.). However, even though this will decrease Unnecessary Transfers and File Size, it will increase the amount of Sync.Subscriptions from the Front-end.
Because we would need to Subscribe to the Translations of Collections.
Does having a large (20-50) amount of Sync.Subscriptions affect Performance? or is it ok to do so?
How much data are you intending on storing locally? I am curious if we are speaking about GB / MB / KB in terms of storage as I do think it affects how I would suggest approaching this.
After rough calculations, I would say not in the GBs:
a single record with one language is on average 5 Kilobytes.
with a total of 5 languages, would be about 25 Kilobytes per translated record.
Looking at the records we have, and how many we could reach by end of this year, I would say 4 to 15 Megabytes in total. And looking at the near future, I would say it is unlikely that we would go over 35 Megabytes .
We consider those records in our Schema as Public, as in, they should be available in the front-end for everyone, so Sync.Subscriptions are added and never removed as users may interact with them and have relationships with their private records.
In other words, those would be Synced to all Users and all of their Devices.
Got it, thank you. So I would still say the approach of syncing all fields might be the best bet in terms of simplicity and cost to implement and cost to you. Our pricing model is pretty generous and I largely suspect you wont see this grow to be a very large cost to you. As for the size of the data on the device, that is a very reasonable amount of data to sync down (we have many customers syncing and storing GB’s).
That being said, if you wanted to avoid it, one other approach I could see would be to set things up like this.
Your documents could largely look like
// Top-Level Collection
struct ProductData {
language string
title string
description string
}
// Top-Level Collection
struct Product {
_id ObjectId
data []ProductData // Can also make this a map[string]ProductData
}
Then you you could subscribe to all Products and it would just pull down a list to all of the links to the data for all languages (but none of the actual data) and then subscribe to the ProductData for the particular languages and Realm will treat these as links and show you them if the ProductData is on the device and hide them if not.
Seems reasonable, and this is what I was first thinking, separating the record from the actual translations, that way we can pull whichever translation we want by subscribing, I think we will go for that, thank you.
Additionally I would presume an increase in total amount of Sync.Subscriptions will not affect performance that much. Since now we would need to subscribe to the specific translation Collection with query=language. I am not sure how Realm Server treats this. Nevertheless, it is a discussion for another topic.