Почему 90% корпоративного софта умирает в лифтах и на складах

Архитектура офлайн-приложений (Offline-first): как разработать мобильный софт для полевых сотрудников без потери данных при обрыве связи

Разработчики тестируют софт в офисе с гигабитным Wi-Fi, а водители и экспедиторы работают в бетонных ангарах и на минус вторых этажах. Разбираем архитектуру честного Offline-first на базе реального кейса DRIVE на 400+ сотрудников.

Иллюзия постоянного интернета: почему типовой софт ложится в полях

Большинство бизнес-приложений проектируется в тепличных условиях. Однако реальность «полевых» сотрудников — это подземные паркинги, цокольные склады, закрытые грузовые пандусы и загородные трассы, где сигнал пропадает каждые пять минут.

Когда приложение строится по классической схеме «сначала HTTP-запрос к API, потом отрисовка экрана», бизнес-процесс гарантированно убивается при первой же сетевой яме. Водитель не может отметить отгрузку, экспедитор не видит адрес следующей точки, а интерфейс «радует» бесконечным спиннером или мертвым зависанием. Итог — срыв графика доставок и прямой убыток компании.

Три фатальные ошибки при проектировании работы без связи

В попытках адаптировать софт под нестабильную сеть разработчики часто совершают архитектурные промахи:

• Ошибка 1: Кэширование на коленке через Redux / AsyncStorage. Данные стираются при первой же выгрузке приложения из памяти операционной системой. Кроме того, такие решения не позволяют делать сложные выборки и поиск по массивам данных.

• Ошибка 2: Отсутствие очереди синхронизации (Queue). Без механизма очереди приложение пытается отправить все накопленные данные скопом в момент появления первого пакета связи. Сервер захлебывается, транзакции падают, данные теряются.

• Ошибка 3: Нарушение целостности данных при конфликтах. Если водитель обновил статус заказа в офлайне, а диспетчер сделал это в CRM — возникает конфликт. Без продуманной логики разрешений возникают задвоения проводок в ERP или 1С.

Архитектура честного Offline-first: локальная база как единственный источник правды

Принцип «честного» Offline-first прост: UI вообще ничего не знает о наличии или отсутствии интернета. Экран приложения читает и пишет данные исключительно в локальную базу данных на смартфоне. Это обеспечивает отклик интерфейса в миллисекунды независимо от качества LTE.

Мы у себя в студии выбрали стек React Native + WatermelonDB (SQLite). Это решение позволяет работать с десятками тысяч записей на устройстве так же быстро, как с локальными переменными. Почему не натив на Kotlin? Все упирается в экономику (TCO).

Стоимость разработки:

Нативный Kotlin - 4.9 млн ₽

React Native + WatermelonDB - 2.39 млн ₽

Срок разработки:

Нативный Kotlin - 5 месяцев

React Native + WatermelonDB - 3.5 месяца

Экономия бюджета:

Нативный Kotlin - 0%

React Native + WatermelonDB - 45%

Снижение бюджета почти вдвое происходит без потери производительности, так как WatermelonDB обеспечивает реактивность данных на уровне нативных движков.

Как устроен фоновый Sync Engine: интеграция с DAX, 1C и CRM

Разместите
тендер бесплатно

Наша система сама подберет вам исполнителей на услуги, связанные с разработкой сайта или приложения, поисковой оптимизацией, контекстной рекламой, маркетингом, SMM и PR.

Заполнить заявку 13785 тендеров
проведено за восемь лет работы нашего сайта.

Сердце системы — фоновый движок синхронизации. Он работает по трем ключевым принципам:

1. Дельта-синхронизация: Мы не пересылаем весь путевой лист целиком при каждом изменении. Передаются только изменившиеся поля (дельты), что критично для экономии трафика и времени сессии.

2. Умный sync: Двигатель мониторит сеть. Поймали 2G или слабый LTE на 3 секунды — накопленная дельта автоматически улетает в бэкенд в фоновом режиме.

3. Офлайн-геофиксация и оплата: Система поддерживает жесткий и мягкий радиус прибытия на точку. Сдача груза, фиксация координат и сохранение чеков происходят моментально без соединения с сервером.

Результаты внедрения в цифрах (кейс DRIVE)

Эффективность архитектуры подтверждена на проекте DRIVE, где софт является критически важным инструментом логистики:

• 400+ активных водителей используют приложение ежедневно;

• Обрабатывается 20 000 строк путевых листов в сутки;

• 0 потерянных доставок и чеков из-за обрывов сети;

• Снижение нагрузки на серверную часть ERP в 3.5 раза за счет внедрения батч-синхронизации (пакетной передачи данных).

Чек-лист для CTO: 6 вопросов подрядчику перед стартом разработки мобильного софта

Чтобы не получить «офлайн для галочки», проверьте компетенции команды:

1. Какая СУБД будет использоваться на устройстве и поддерживает ли она реляционные связи?

2. Как реализована очередь синхронизации (Queue) и что произойдет при сбое транзакции?

3. Используется ли дельта-синхронизация или вы пересылаете объекты целиком?

4. Какая стратегия разрешения конфликтов (Conflict Resolution) заложена в архитектуру при одновременном изменении данных в 1С и в приложении?

5. Как UI-слой узнает об изменениях в локальной БД (используется ли реактивное связывание)?

6. Как реализована фоновая работа Sync Engine в условиях агрессивного энергосбережения современных ОС?