Flexible Sync Usage Clarifications

@Ian_Ward
Hey there - I hope you are doing well! I have some questions regarding Flexible Sync’s usage. I will ask from a Swift SDK point of view.

  1. We do not have to worry about managing lifecycles on subscriptions in Flexible Sync (as opposed to legacy QBS), correct?
    • Beyond its lifecycle management, can we please get some advice on performance regarding all active subscriptions’ load/expense?
  1. I could not find a built-in way to “watch” (aka: observe) a ‘SyncSubscriptionState’ on either a ‘SyncSubscriptionSet’ nor on an individual ‘SyncSubscription’ - Can you please advise?

  2. Also, [why] is a ‘SyncSubscriptionState’ only for a ‘SyncSubscriptionSet’? -if so, I would then assume that each set is grouped for all its subscriptions’ sync-states within that set as a whole, am I correct?

  3. For Permissions, the ‘applyWhen{}’ is the first condition that has to be met, and then proceeds with read & write conditions, correct? -I see it that way for order (beyond also being an ‘and’ conjoin) but would like confirmation.

  4. For the JSON in ‘Permissions’, what does wrapping all the conditions inside ‘rules: {}’ do versus not? -I have seen examples both ways:
    rules wrapping example link (both for same app’s tutorial)
    rules not wrapping link (both for same app’s tutorial)

  5. I’d like to confirm what I am seeing in my testing… that a related ‘Object’ or ‘List<Object>’ will be prevented in a ‘Flexible Sync’ query if it has nested relationships that do not meet the conditions in Sync Permission’s (JSON) rules, set in cloud-side. Therefore, we must ensure that nested relationships also meet conditions (just like the top-level does) for the complete result. For example, if a ‘Person’ object has a ‘List<Dogs>’, but one of the dog objects does not meet the rules’ conditions, then that one dog object is not supposed to show up in that query (while other dog objects meeting conditions will), correct? - I want to make sure that is the intended behavior in Flexible Sync.

Thank you!

For #5 - I think I have figured it out - for any future readers…

Basically, the 2nd link was pulled from ‘Permission’ JSON from the server/cloud side; which is different than our usage that we define in Flexible Sync’s “Define Permissions” area.

Therefore, we should just follow as documented, which to summarize/re-cap is… we basically use ‘rules: {}’ for individual collection ‘roles’ and use ‘defaultRoles: []’ for ‘roles’ across all collections.

For #2 - I received confirmation via github - for any future readers…

Currently (as of 2022-06-09), observing/watching is not available.