Зачем разбирать эту тему
Offline имеет смысл только там, где пользователь действительно должен продолжить работу без сети. App shell можно кэшировать агрессивно, а пользовательские данные требуют отдельной стратегии.
Как устроена задача на практике
Изменения помещаем в локальную очередь с client ID и временем. После восстановления сети запросы повторяются идемпотентно, чтобы один сбой не создавал две оплаты или две заявки.
Что важно в production
Самая сложная часть — конфликт версий. Для важных сущностей используем version number или updated_at и показываем пользователю, если данные были изменены на другом устройстве.
Типичные ошибки
Главная ошибка — выбирать технологию или паттерн раньше, чем сформулирован пользовательский сценарий и ограничения. Второй частый промах — проверять решение только на идеальном happy path и не продумывать восстановление после сбоя, повторный запрос и права доступа.
Практический вывод
UX должен честно показывать offline и статус синхронизации. Если продукту эти сценарии не нужны, лучше оставить online-first и инвестировать в скорость.
- фиксируйте допущения до реализации;
- проверяйте решение на реальных данных и устройствах;
- сохраняйте наблюдаемость и возможность безопасного отката;
- усложняйте архитектуру только когда это подтверждает задача.