Застосунками для виїзних команд користуються в підвалах, ліфтах, на складах і в селі — тобто саме там, де відбувається робота. Застосунок, який вважає зв’язок нормою, а офлайн помилкою, ламається в момент, коли він найпотрібніший.
Найбільше болить саме дороблення. Офлайн-перший підхід — це не кеш, який додають пізніше; він змінює те, кому належить правда.
Клієнт стає джерелом правди — тимчасово
В офлайн-першій архітектурі пристрій тримає стійку локальну чергу записів, а інтерфейс читає з локального стану. Сервер є партнером із синхронізації, а не джерелом, на яке чекає інтерфейс.
Ця одна зміна проходить крізь усе: ідентифікатори мають генеруватись на клієнті, кожен запис має бути ідемпотентним, а серверу потрібні явні правила злиття для кожної сутності.
- Ідентифікатори з клієнта (UUIDv7 залишає їх сортованими).
- Ключі ідемпотентності на кожній вихідній операції.
- Політика злиття для кожної сутності — останній перемагає, тільки додавання або ручне вирішення.
- Видимий стан синхронізації, щоб користувач довіряв тому, що вже дійшло.
Зробіть стан синхронізації видимим
Найцінніше, що можна показати людині в полі, — що стоїть у черзі, а що вже синхронізовано. Прихована синхронізація породжує захисну поведінку — пересканування, повторні відправки, подвійне введення, — яка псує дані надійніше за будь-який баг.
Правила злиття вирішуйте з бізнесом, а не на код-рев’ю
Коли два пристрої не згодні між собою, хтось має вирішити, хто перемагає. Це бізнес-правило. Підтвердження доставки ніколи не має тихо перезаписуватись; координата GPS майже завжди має. Запишіть це до реалізації.
Ми написали це, бо мусили це вирішити. Подивіться, що ми побудували або розкажіть, над чим працюєте.