Сколько стоит обрыв связи
Посчитаем на примере склада: десять кладовщиков при обрыве интернета на час накапливают 150–300 операций приёмки и отгрузки. Без офлайн-режима их либо не вносят вовсе, либо переносят вручную вечером — это 30–60 минут на человека в день и гарантированные ошибки в остатках. У курьера сценарий похож: отметки о доставке ставятся после возвращения на базу, и бухгалтерия до вечера не видит выручку и статусы заказов. У выездных бригад данные вообще живут на бумаге, а перенос в систему превращается в отдельный этап с потерями. Офлайн-режим устраняет сам источник проблемы — зависимость процесса от качества связи.
Как технически работает офлайн в браузере
Современное веб-приложение (PWA) умеет работать без сети благодаря связке из трёх технологий:
- Service Worker — скрипт-посредник, который перехватывает запросы приложения. Нет сети — он отдаёт данные из локального кэша, и интерфейс работает как ни в чём не бывало.
- IndexedDB — встроенная в браузер база данных, которая хранит на устройстве сотни мегабайт структурированных данных: справочники, заказы, фото.
- Фоновая синхронизация — накопленные изменения автоматически отправляются на сервер при появлении связи, даже если сотрудник уже закрыл приложение.
Дополнительно PWA устанавливается на телефон как обычное приложение — с иконкой на рабочем столе и запуском на весь экран. Загружать через App Store и Google Play не нужно, обновления подхватываются автоматически при первом подключении к сети.
Что храним на устройстве
Главная ошибка — пытаться синхронизировать всю базу. Локально нужно держать только то, что требуется сотруднику на смену: кладовщику — товары и ячейки своего склада, курьеру — заказы своего маршрута, бригаде — объекты и наряды на день. Справочник из 50 000 позиций с ценами и остатками спокойно помещается в IndexedDB и загружается за секунды. Отдельная категория — медиа: фото повреждённых товаров, подписи клиентов, сканы документов сначала сохраняются на устройстве и уезжают на сервер вместе с очередью операций. Такой подход ускоряет и саму работу: справочники открываются мгновенно, без ожидания ответа сервера.
Очередь операций: синхронизация без потерь
Каждое действие сотрудника — приёмка, сканирование, отметка доставки — записывается как отдельная операция с уникальным номером. Операции встают в локальную очередь и отправляются на сервер строго по порядку: сервер подтвердил обработку — операция удаляется из очереди, связи нет — она остаётся и ждёт. Ключевая деталь — идемпотентность: если операция ушла, но подтверждение потерялось и она отправится повторно, сервер распознает дубликат по номеру и не создаст вторую приёмку. Именно эта механика даёт гарантию «ни одна операция не теряется и не задваивается», на которую затем опирается вся отчётность.
Конфликты: когда одну запись меняют двое
Классическая ситуация: кладовщик офлайн оприходовал 10 единиц, а менеджер онлайн в тот же час списал 3. После восстановления связи сервер видит две версии одной карточки товара. Стратегий разрешения несколько:
- Last write wins — побеждает последняя по времени запись. Просто и дёшево, но подходит только для некритичных данных.
- Версионирование — сервер сохраняет обе версии и показывает конфликт человеку: тот сравнивает и выбирает итог. Надёжно, но требует отдельного интерфейса.
- Разделение полей — остатки и деньги считает сервер как источник истины, а клиентские поля (заметки, фото, результаты осмотра) приоритетны у того, кто был на месте.
Универсального ответа нет: модель конфликтов проектируется под конкретный процесс. Для склада обычно комбинируют третий вариант с операциями «дооприходование/досписание» вместо перезаписи остатка целиком.
Что осознанно оставляем онлайн
Часть операций офлайн включать нельзя — и это нормально. Продажа последней единицы товара, списание с точных остатков, оплата и проверка уникальности штрихкода требуют актуальных данных с сервера. Правильное решение — честный UX: в офлайне такие действия блокируются с понятным объяснением («Продажа доступна после синхронизации остатков») либо попадают в статус «на подтверждение». Важно, чтобы система не выполняла опасную операцию молча и не выдавала криптическую ошибку. Граница «что можно офлайн, а что нет» фиксируется на этапе проектирования — это одно из первых решений в проекте.
Офлайн глазами сотрудника
Сотрудник не должен гадать, сохранилось ли его действие. В приложении всегда виден индикатор режима: жёлтый — «офлайн, 14 изменений ждут отправки», зелёный — «все данные синхронизированы». Ранее внесённые операции остаются доступны для просмотра и правки, счётчик несинхронизированных изменений выводится на главный экран. При восстановлении связи синхронизация проходит сама — без кнопок «отправить ещё раз» и повторного ввода. Такой интерфейс снимает страх «всё пропало», который чаще всего и становится причиной, по которой склады саботируют переход с бумаги на цифру.
Сколько стоит и как заказывать
Добавить офлайн-режим в готовое приложение дороже, чем заложить сразу: на практике это +30–60% к бюджету разработки, потому что переписывается слой работы с данными. В новом проекте офлайн обходится в +15–25% при условии, что он зафиксирован в требованиях с первого дня. Что согласовать с подрядчиком до старта:
- список сценариев, которые обязаны работать без сети, и операций, которые остаются только онлайн;
- модель разрешения конфликтов для ключевых сущностей — остатки, заказы, документы;
- перечень устройств: терминалы сбора данных, телефоны, планшеты — от этого зависит реализация;
- приёмочный тест «авиарежим»: час работы без сети, возврат связи, сверка данных на сервере.
Последний пункт особенно важен: тест с включённым авиарежимом на реальном устройстве выявляет до 90% проблем синхронизации ещё до сдачи проекта.
Офлайн-режим — это про непрерывность бизнеса: склад не останавливается из-за упавшего роутера, курьер закрывает заказ у двери клиента, а бригада оформляет акт на объекте без связи. Технологическая база — PWA, Service Worker и IndexedDB — зрелая и работает в обычном браузере без установки из магазинов приложений. Ключевая сложность не в том, чтобы «сохранить локально», а в грамотной синхронизации: очередь операций, идемпотентность и заранее спроектированные правила конфликтов. Если ваши процессы завязаны на склад, доставку или выездные команды, офлайн-режим окупается одними лишь часами ручного переноса данных, которые вы перестаёте оплачивать.