Офлайн-приложение: бизнес-программы, которые работают без интернета

Офлайн-приложение позволяет продолжать работу, когда пропадает интернет, и автоматически синхронизирует данные с сервером после восстановления связи. Такой подход называют offline-first: приложение сначала сохраняет данные на устройстве, держит изменения в очереди и отправляет их, когда это возможно, поэтому пользователь не видит сообщения «не удалось сохранить», а работа не прерывается. Наша программа электронного табло Multi Score Screen работает по этому принципу: если в спортзале слабеет Wi-Fi, судья продолжает вводить очки, данные синхронизируются автоматически после восстановления связи, и матч идёт без остановки. В статье рассказываем, как устроен offline-first, кому он особенно нужен и на что смотреть при выборе или разработке такой программы.

Почему это важно: интернет не везде стабилен

Соединение, которое кажется безупречным за офисным столом, часто оказывается совсем другим там, где идёт работа. Мастерские в маринах, склады в подвалах, спортзалы из бетона и металла, стройплощадки и выездные мастера постоянно сталкиваются со слабой связью или её отсутствием. Приложение, работающее только в облаке, в такие моменты просто останавливается: форма не сохраняется, остаток не списывается, счёт не обновляется. Пользователь либо ждёт, либо записывает всё на бумагу, чтобы внести позже, — это и потеря времени, и источник ошибок. К тому же бумажные записи легко потерять.

Подход offline-first переворачивает задачу: приложение проектируется так, будто связи нет, а подключение рассматривается как приятный бонус. Для пользователя разница очевидна: приложение быстро открывается и мгновенно реагирует на любые действия, потому что сначала работает с локальными данными.

Как устроен offline-first

1. Локальное хранилище: приложение хранит данные на устройстве — в веб-приложениях обычно в IndexedDB браузера, в десктопных и мобильных — в локальной базе вроде SQLite.
2. Очередь изменений: каждое изменение записывается локально и добавляется в очередь на отправку.
3. Синхронизация: когда связь появляется, очередь по порядку отправляется на сервер, а новые данные с сервера загружаются на устройство.
4. Уникальные идентификаторы: записи создаются на устройстве, поэтому идентификаторы должны генерироваться без запроса к серверу и без коллизий, например в виде UUID.
5. Разрешение конфликтов: правило определяет, какая версия победит, если одну запись по-разному изменили на двух устройствах.

Простой пример ниже показывает суть: записать локально, поставить изменение в очередь, отправить при наличии связи.

// Offline-first in a nutshell: write locally, queue the change, sync when online
async function savePoint(matchId: string, team: "A" | "B") {
  const change = { id: crypto.randomUUID(), matchId, team, at: Date.now() };
  await localDb.put("points", change);      // 1. the UI updates from local data at once
  await localDb.put("outbox", change);      // 2. remember what still has to reach the server
  if (navigator.onLine) void flushOutbox(); // 3. try to sync now, otherwise later
}

async function flushOutbox() {
  for (const change of await localDb.getAll("outbox")) {
    const res = await fetch("/api/points", { method: "POST", body: JSON.stringify(change) });
    if (!res.ok) return;                    // keep it queued and retry on the next "online" event
    await localDb.delete("outbox", change.id);
  }
}
window.addEventListener("online", () => void flushOutbox());

Конфликты: самая сложная часть

Главный вопрос проектирования — что делать, если два человека изменили одни и те же данные без связи. Распространены три стратегии. «Побеждает последняя запись» — просто, но может незаметно терять изменения. Слияние по полям объединяет изменения в разных полях одной записи: если один сменил телефон, а другой адрес, сохранятся оба. Иногда лучше спросить пользователя: если два мастера по-разному отметили один и тот же заказ-наряд, система показывает конфликт и просит решить. Для числовых данных, например складских остатков, синхронизация движений вместо значений («списано 3 шт.») убирает большинство конфликтов.

Веб, PWA или десктоп

Работа без сети — не привилегия десктопных программ. Прогрессивные веб-приложения (PWA) кэшируют файлы приложения через service worker и хранят данные в браузере, поэтому могут работать офлайн. Десктопные приложения по своей природе работают локально, а со слоем синхронизации — и на нескольких устройствах. Выбор зависит от устройств пользователей, требований к печати и оборудованию и способа распространения программы; подробнее — в статье десктопное или веб-приложение. Общая логика облачных программ по подписке описана в статье что такое SaaS.

Интерфейс: честно показывайте состояние связи

• Показывайте статус синхронизации: понятная подсказка вроде «Все изменения сохранены» или «3 изменения ждут отправки» вызывает доверие.
• Никогда не теряйте данные молча: если изменение не удалось отправить, сообщите об этом и повторите попытку.
• Объясняйте, что доступно офлайн: например, создавать записи можно, а принимать оплату — нет; такие ограничения должны быть видны.
• Дайте возможность отмены: ошибки, сделанные без связи, должно быть так же легко исправить.

Безопасность и резервные копии

Когда данные хранятся на устройстве, его потеря или кража становится риском. Базовые меры — шифрование чувствительных данных, ограничение длительности сессий и возможность удалённо завершить сеанс на устройстве. Синхронизация создаёт центральную копию, которая регулярно резервируется на сервере, но несинхронизированные изменения существуют только на устройстве, поэтому полезно напоминать пользователю о синхронизации после долгой работы без связи. Отдельно продумайте, что делать при смене или ремонте устройства: перед этим все изменения должны быть отправлены на сервер. Для этого в интерфейсе стоит предусмотреть кнопку принудительной синхронизации и понятное подтверждение её успешного завершения.

Как тестировать работу без сети

Тестировать offline-first приложение только при хорошей связи недостаточно. С помощью ограничения сети и офлайн-режима в инструментах разработчика браузера и авиарежима на телефоне проверьте сценарии: создание записей без связи, обрыв посреди операции, изменение одной записи на двух устройствах и синхронизацию после долгого отсутствия связи. Почему это важно для склада и заказ-нарядов, мы рассказали в статье о складском учёте со штрихкодом.

Где offline-first встречается чаще всего

На практике мы чаще всего видим потребность в офлайн-режиме в четырёх областях: сервисные отчёты и заказ-наряды у выездных мастеров, приёмка и инвентаризация на складе, продажи и заказы на мероприятиях и ведение счёта в спортзалах. Во всех этих случаях сбой не просто раздражает, а напрямую стоит денег или данных. Поэтому, автоматизируя такие процессы, вопрос офлайн-работы стоит задать в самом начале: добавить слой синхронизации потом гораздо сложнее и дороже.

Когда выбирать offline-first

Offline-first добавляет сложности: синхронизация, разрешение конфликтов и тестирование требуют больше времени на разработку. Если ваши сотрудники всегда работают в офисе с надёжной связью, он может и не понадобиться. Но если работа идёт на выезде, в мастерской, в зале или на мероприятии, а обрыв связи означает потерянную работу, вложения окупаются быстро. Как отмечено в ответах на частые вопросы Multi Score Screen, бесперебойный ввод счёта при слабой связи создан для того, чтобы ни один матч не прервался. Экраны продукта можно посмотреть на нашей странице Multi Score Screen, а если вам нужно приложение для вашего бизнеса, работающее без сети, посмотрите услугу разработка ПО на заказ.

Поделиться:XLinkedInWhatsApp