Спросите любого мобильного разработчика про
Offline-First, и он скажет: «Сохраняем локально, отправляем при появлении сети». Эта фраза - вершина айсберга, под которой скрывается мир распределенных систем, конфликтов синхронизации и потерь данных. Настоящий
Offline-First начинается там, где заканчивается простое кэширование, и приложение должно работать как полноценная распределенная система с временно недоступным сервером.
Представьте коллаборативное приложение. Два пользователя редактируют один документ в оффлайне. Первый меняет заголовок, второй - описание. При подключении оба изменения пытаются улететь на сервер. Стратегия «побеждает последняя запись» (LWW) означает, что один из пользователей потеряет свои правки. В лучшем случае - это плохой UX, в худшем - критическая потеря данных бизнес-логики.
Три фундаментальные проблемы, которые нужно решить:
- Конфликты версий (Version Conflicts):
Каждое изменение должно нести метаданные: кто, когда и с какой версии начал редактирование. Сервер не может просто принять последний объект. Он должен понимать, на основе какой версии были сделаны изменения. Если за время оффлайна документ успел измениться на сервере, клиент должен получить конфликт и разрешить его - либо автоматически по правилам, либо с участием пользователя. Для этого нужны векторные часы (vector clocks) или аналогичные механизмы.
- Сохранение причинно-следственных связей (Causality):
Очередь запросов - это не просто список. Порядок имеет значение. Если запрос «добавить задачу А» не ушел, а запрос «удалить задачу А» уже отправился, система сломается. Запросы должны быть идемпотентными (повторное выполнение не ломает систему) и в идеале, коммутативными (порядок выполнения не важен). Это приводит нас к структуре CRDT.
- Гарантия доставки и целостность (Guaranteed Delivery & Integrity):
Сетевой запрос может упасть в любой момент. Клиент должен хранить операцию в надежном, персистентном хранилище до момента, пока не получит от сервера явное подтверждение успешного применения. При перезапуске приложения или краше операции не должны теряться. Это требует сложной системы управления состоянием локальной очереди.
CRDT - математический фундамент бесконфликтной синхронизации:
Conflict-free Replicated Data Types (CRDT) - это структуры данных, спроектированные так, что их операции можно применять в любом порядке, а результат всегда будет одинаковым. Вместо отправки итогового значения («заголовок = "Новый"») отправляется операция («в позицию 0 вставить символы "Новый"»). Если два клиента независимо добавили разные слова в один абзац, применение обоих операций (в любом порядке) даст корректный объединенный результат.
Почему не стоит писать свой движок синхронизации:
Создание надежного механизма синхронизации - это задача уровня распределенных систем (distributed systems). Требуется:
- Реализация алгоритмов консенсуса для разрешения конфликтов.
- Система очередей с гарантированной доставкой.
- Механизм компрессии и слияния операций.
- Детальное логирование и отладка расхождений.
Для большинства проектов разумнее использовать проверенные решения:
PowerSync (реалтайм-синхронизация с Postgres),
ElectricSQL (на основе CRDT),
Replicache для веба или
Couchbase Mobile. Они предоставляют готовую, оттестированную абстракцию.
Вывод:
Offline-First - это архитектурный паттерн, который поднимает клиентское приложение до уровня узла в распределенной системе. Это про проектирование API, который принимает патчи, а не объекты, про выбор между
Operational и
State-based CRDT, про реализацию отката optimistic-изменений в UI при конфликте.
Игнорирование этих сложностей приводит к приложениям, которые работают оффлайн, но теряют данные пользователей при синхронизации, создавая кошмар поддержки и подрывая доверие. Прежде чем объявить о поддержке оффлайна, спросите себя: готовы ли вы решать задачи распределенного консенсуса на мобильном телефоне? Если нет - используйте готовые инструменты или ограничьтесь простым кэшированием.
