Приложениями для выездных команд пользуются в подвалах, лифтах, на складах и в деревне — то есть именно там, где происходит работа. Приложение, которое считает связь нормой, а офлайн ошибкой, ломается в момент, когда оно нужнее всего.
Больше всего болит именно доработка. Офлайн-первый подход — это не кеш, который добавляют позже; он меняет то, кому принадлежит правда.
Клиент становится источником правды — временно
В офлайн-первой архитектуре устройство держит устойчивую локальную очередь записей, а интерфейс читает из локального состояния. Сервер является партнёром по синхронизации, а не источником, которого ждёт интерфейс.
Это одно изменение проходит сквозь всё: идентификаторы должны генерироваться на клиенте, каждая запись должна быть идемпотентной, а серверу нужны явные правила слияния для каждой сущности.
- Идентификаторы с клиента (UUIDv7 оставляет их сортируемыми).
- Ключи идемпотентности на каждой исходящей операции.
- Политика слияния для каждой сущности — последний побеждает, только добавление или ручное разрешение.
- Видимое состояние синхронизации, чтобы пользователь доверял тому, что уже дошло.
Сделайте состояние синхронизации видимым
Самое ценное, что можно показать человеку в поле, — что стоит в очереди, а что уже синхронизировано. Скрытая синхронизация порождает защитное поведение — пересканирование, повторные отправки, двойной ввод, — которое портит данные надёжнее любого бага.
Правила слияния решайте с бизнесом, а не на код-ревью
Когда два устройства не согласны между собой, кто-то должен решить, кто побеждает. Это бизнес-правило. Подтверждение доставки никогда не должно тихо перезаписываться; координата GPS почти всегда должна. Запишите это до реализации.
Мы написали это, потому что должны были это решить. Посмотрите, что мы построили или расскажите, над чем работаете.