Есть идея сделать потоки выгрузки с клиента и фетч с сервера независимыми, способными работать не в системе друг с дургом и паралельно. Ранее описанная схема с длинной последовательностью – сначала цепочки выгрузок, затем фетч – хрупкая и имеет подводные камни в честве обработки ошибок, состояния гонки и др.

Идея такая...

Разделим локальное состояние (Базу данных на устройстве) на 2 слоя:

1 Слой – базовый. Состояния с сервера. Те фактические данные, которые прилетают с сервера в ответ на стандартные методы GET, PUT, PATCH. Складывается в соответствующие таблицы сущностей. Сущности в этих таблицах не мутируются клиентом, только с сервера.

2 Слой с локальными изменениями. Обновления, применяемые на клиенте. В соответствующей таблице складываются измененные поля сущностей, связанные по ключу ID. В другой таблице этого слоя будут метки на удаленные сущности.

В рамках процесса синхронизации между клиентским приложением и серверной частью, описанной https://gist.github.com/constzaytsev/b9170d651ef81a0ae325fc372ed03b60, используется WebSocket сервис нотификаций для оповещения клиентов одной установки об изменениях в общих данных. Предполагается оповещение поточного типа, то есть сервис транислирует всем клиентам все события, клиент сам определяет находится ли он в контексте события и обрабатывает его при необходимости.

В большинстве случаев, клиент после любого сообщения, где в обновлениях есть initiator_id отличный от текущего, будет делать sync запрос на обновление.

Сообщения от сервиса принимаются с debounce фактором и обрабатываются асинхронной очередью.

Челночный, потому что в рамках единого запроса данные могут передаваться и получаться.

Описание на примере категорий тасков (lists) и самих тасков (tasks)

• Получение сообщения от сервиса нотификаций по ws
• Появление коннекшона после разрыва