Ignore history with no need to recover offline client activity

[Jonathan_Thorpe]

We have a use case which seems relatively simple but I’m not sure if we’re configuring the system for best performance.

• We use realm sync for iOS using partition based sync
• We want to keep a realm on local file to have a fast startup (data accessible before pulling data)
• We are not interesting in supporting offline changes, server data always wins
• We have location for users and assets which is updated often and builds up history quickly

We have noticed that performance (specifically startup time) has been very affected since we have our frequent changes. Based on the assumption that this degradation was due to the large amount of history build up and attempts to recover client state, we have:

• Enabled Maximum Client Offline Time with a value of 1 day
• Set the client reset mode to discard local

As far as I can see this still implies that the history is kept so that client and that we have backend compaction occurring once a day. Is there a way we can disable history completely, as we do not need it ? Is there a better way to configure App Services for this use case ?

Thanks!

[Ian_Ward]

@Jonathan_Thorpe the maximum client offline time is for flexible sync only. Are you able to migrate to flexible sync? That would allow you to trim down the history quite a bit and get better performance

[Tyler_Kaye]

Flexible sync has the added benefit of making bootstrapping much faster. I think you will be best off using flexible sync and setting a low max offline time.

[Jonathan_Thorpe]

Thanks for your answer. I’m guessing as a quick test we can setup flexible sync with a query which mimics the partition sync we’re using ({_partition:"Something"}). Then progressively use flexible sync in a more appropriate way…

[Jonathan_Thorpe]

I might be missing something but looking at the docs

Optimize Sync Atlas Usage — Atlas App Services

It’s not clear that it’s flexible sync only given the UI for setting Client Maximum Offline Time is available for a partition sync configuration.

[Tyler_Kaye]

@Jonathan_Thorpe exactly correct. I think you will enjoy your experience with it. We will have a product to help migrate people from Partition Sync to Flexible Sync for applications in production, but if you are just in development or want to start a new version of the backend then I would recommend doing so with Flexible Sync.

Thanks or pointing out the docs issue. Interestingly enough I pointed this out last week and it was fixed a few days ago and will be pushed out the next time the docs are released I believe.