SyncQueue - what it is and what it is not

Core understanding

1.Sync function stores data in key-value format. 2.Queries are not performed on the value, it is performed on the keys alone. 3.Any module that supports offline feature, creates the offline data handler and passed it on to the Sync library for synchronisation, and the sync library loads all the data present in sync db but acts on only those data types for which handles are defined by the caller. 4.Sync library does not alter any data at rest or in runtime.

Clarification from community dev

  1. The sync queue is simply using an IndexedDB table as the data store. Sync queue items are simple objects stored in that table, but they are indexed by the following keys: [(id), (type), (userId), (userId, type)]. Those indices may also used for querying. Two examples: (1) I might want to get all sync items of type “patient-registration” (-> requires querying by “type”). (2) I might also want to view all sync items by a specific user (-> requires querying by “userId”).
  2. See #1. There isn’t really the concept of a separate key and value. Rather, there is only one object/entry per item which itself contains attributes that are used for querying. Nontheless, each sync item has a “content” field which contains the actual synchronization data (e.g. the registered patient information). This content is not used for querying (that would conflict with encrypting it).
  3. Correct. Sync handlers are registered during application setup and are responsible for running the actual synchronization logic (e.g. calling the REST API). The sync queue is responsible for providing the data to be synced to the invoked handlers.
  4. I’m not sure if I understand the point correctly. The sync queue, by itself, doesn’t do any data manipulation without being told to do so, but it is responsible for adding/updating/removing data to be synchronized, if called by other code. If I, as the author of another microfrontend, want to add/update/remove synchronization data, I will call the sync queue API which then handles the actual data manipulation.

further clarification on point#4

Regarding Point#4, my question was like this : If say we created an offline patient without an address. And, later in the same offline session, some MF updates the data, e.g., adds an address. In that case, is it the caller MF who bears the responsibility of data alteration, or is it Sync library which does that. Because it is not generic, it is more likely that the caller MF has the responsibility to get the data from Sync library, update it if needed and push it back to sync library, and then it is Sync library’s responsibility to push the data back to queue without being aware of what has actually been changed in the content.

and verification from community dev

Okay, got it, thanks for clarifying! Yes, you are understanding that correctly, the sync queue doesn’t do any data manipulation itself in that context.

For reference, the initial Slack discussion: Slack