Offline-first или постоянный онлайн: что остаётся от приложения без сети?

Страницу Notion можно заранее сохранить для работы без интернета. Но сохранённая страница не означает, что вместе с ней загружены все вложенные страницы и вся база данных. По действующим правилам Notion, вложенные страницы нужно отмечать отдельно, а для базы автоматически доступными становятся первые 50 строк первого представления. Если нужная задача находится дальше, само слово «офлайн» уже не помогает.

У Яндекс Карт другая граница. Скачанная карта позволяет без интернета искать адреса и строить автомобильные, пешеходные, велосипедные маршруты и маршруты на общественном транспорте. Но актуальные пробки, камеры и дорожные события в такой маршрут не попадут: эти сведения приложение получает из сети. Расписание транспорта без связи тоже может устареть.

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

Противоположный выбор — держать приложение постоянно связанным с сервером — тоже не обязан быть архитектурной ошибкой. Для совместного редактирования, бронирования ограниченного ресурса или приёма платежа серверная сторона может быть не техническим придатком, а частью самой услуги. Ошибка появляется, когда зависимость от неё распространяют на действия, которым немедленный ответ сервера ничего не добавляет.

Документ доступен. А работа — нет

Сравнение Notion с Obsidian полезно не потому, что один продукт «правильный», а другой «неправильный». Они обещают пользователю разную организацию данных.

Obsidian хранит заметки как локальные файлы. Для чтения и редактирования собственного хранилища связь не нужна; обмен между устройствами подключается отдельно. Это даёт человеку свободу работать с уже имеющимися файлами, но переносит на него или на выбранный сервис часть ответственности за сохранность. Даже документация Obsidian подчёркивает: синхронизация не заменяет резервную копию.

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

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

У такого решения есть цена. На устройстве окажется больше данных, потребуется отслеживать изменение состава подготовленного проекта, ограничивать размер и учитывать доступ к страницам после изменения прав. Это не предположение о том, что команда Notion не думала об этих вопросах: в техническом разборе своего офлайн-режима она описывает отдельную модель причин, по которым страница хранится локально, обновление по изменениям и отказ от постоянного опроса каждой страницы как плохо масштабируемого варианта. Расширить офлайн-сценарий — значит расширить и эту ответственность.

Для автора личных заметок, которые должны быть доступны всегда, подход Obsidian выглядит естественнее. Для команды, где важны единое пространство, права и совместная работа, Notion получает другую пользу от сервера. Рекомендация «пусть оба станут полностью локальными» не улучшит оба продукта одинаково. А вот вопрос «можно ли выполнить конкретную задачу в дороге?» способен обнаружить недостающую возможность без смены всей архитектуры.

Карта есть, дорожной обстановки нет

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

Представим приложение для выездной сервисной команды, опирающееся на похожие данные. За день назначено несколько объектов. Адреса, задание, схема оборудования и необходимая для проезда область карты известны заранее. Если всё это загружается только в момент открытия очередного заказа, плохая связь останавливает сотрудника ещё до того, как ему понадобились актуальные внешние сведения. Подготовка рабочего дня на устройстве могла бы сохранить маршрут и документы доступными. Но обещать точное время прибытия по старому снимку пробок было бы уже другой ошибкой.

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

Расширять локальную копию без границ тоже нельзя. Карты занимают место и нуждаются в обновлении; Яндекс позволяет настраивать их автоматическое обновление. Поддержка работы без связи не равна попытке сохранить на телефоне весь мир. Она означает заранее отобрать то, что понадобится для выбранной работы, и честно обозначить, что останется живой онлайн-информацией.

Такой подход не требует заставлять весь продукт жить по одной схеме. Экран задания может открываться из локального хранилища, маршрут — использовать подготовленные картографические данные, а прогноз дорожной обстановки — появляться только при связи. Три части одного рабочего дня имеют разные сроки актуальности. Их не следует ни объединять в один безусловный cache, ни одинаково привязывать к серверному ответу.

Касса работает без сети. А оплата?

В магазине связь пропадает уже после того, как кассир собрал корзину. Что именно остановится: продажа, выдача чека, оплата картой или только передача сведений о чеке? Слово «касса» скрывает здесь несколько разных операций.

Эвотор указывает, что его контрольно-кассовая техника способна работать без интернета: сведения о чеках сохраняются в фискальном накопителе и передаются оператору фискальных данных после восстановления связи. ФНС отдельно разъясняет, что при временном отсутствии интернета бумажный чек всё равно печатается в момент оплаты. Но отложенная передача чека не означает отложенного подтверждения оплаты картой.

Для сравнения, Т‑Банк требует дождаться на терминале чека с отметкой «Одобрено», прежде чем считать оплату прошедшей. Если терминал не видит банк, его инструкция предлагает восстановить соединение, в том числе через другое подключение. Это другой контур ответственности: данные о продаже можно подготовить локально, но отсутствие банковского подтверждения нельзя выдать за принятую карточную оплату. Примеры Эвотора и Т‑Банка описывают разные части торгового процесса, а не проверенную связку устройств.

Из этого следует не универсальное «касса работает офлайн», а более полезная продуктовая политика: кассир видит, что уже подготовлено и что действительно завершено; система не смешивает сформированный чек, отправку его сведений и подтверждение платежа. Если банковской связи нет, нужен понятный путь к другому допустимому способу расчёта или остановке продажи, а не зелёная плашка «готово» поверх неподтверждённой операции. Конкретные способы расчёта и работа кассы зависят от оборудования и условий продавца; статья не проверяет их на живой торговой точке.

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

Почему «полностью онлайн» не значит «каждый пиксель через сеть»

У облачных редакторов есть сильное основание держать сервер рядом с рабочим процессом. Figma описывает совместную работу в реальном времени как основу продукта. Без сети открыты лишь страницы, уже загруженные в текущей сессии; изменения можно продолжать делать и затем отправить, но новые библиотечные компоненты, действия других участников и история версий недоступны. Figma прямо не называет этот режим полноценной офлайн-работой.

Здесь тоже возможна проектная гипотеза: заранее подготовленный снимок файла помог бы индивидуальному дизайнеру продолжать работу в дороге. Однако ценность такого снимка ограничена. Общая библиотека и действия коллег продолжат меняться, а локальная копия потребует правил объединения и контроля объёма. Улучшение работы в одиночку нельзя без проверки представить как улучшение живого совместного редактирования.

Но из того, что Figma строится вокруг сервера, не следует, будто перемещение каждого объекта на один пиксель должно ждать сетевого ответа. Уже существующая возможность продолжать изменения на загруженной странице при обрыве связи показывает более тонкую организацию: интерфейс может реагировать локально, пока подтверждение и совместная картина догоняют его позже. Онлайн-зависимый продукт и «сетевой запрос на каждое движение» — разные архитектуры.

У постоянного сетевого обмена есть измеримая физическая цена. Android Developers предупреждает, что частые запросы удерживают радиомодуль активным и расходуют батарею. Но и обратное утверждение — «offline-first всегда экономичнее» — не выдерживает проверки: Flutter отдельно предупреждает о цене непрерывной фоновой синхронизации и ограничениях устройств. Экономию нельзя приписывать выбранному ярлыку архитектуры. Её надо измерять на конкретном сценарии, включая частоту запросов, объём загрузки и работу в фоне.

Что проверять в собственном продукте

После этих примеров вопрос «делать ли offline-first?» выглядит слишком крупным для одного ответа. Более полезна проверка нескольких основных работ пользователя. Для каждой нужно назвать результат, который человек считает завершённым, а затем попробовать пройти путь при нормальной связи, при медленной связи и без неё.

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

Для такого ревью достаточно небольшой матрицы:

Вопрос	Что он меняет в решении
Какая работа должна продолжаться без связи?	Определяет объём локальных данных и функций, а не абстрактную галочку «офлайн»
Сколько времени данные могут оставаться старыми?	Отделяет полезный локальный результат от опасной иллюзии актуальности
Что случится, если отложенное действие позднее не примут?	Показывает цену ошибки для человека и бизнеса
Что теряется при поломке или замене устройства?	Проверяет, есть ли восстановление, а не только синхронизация
Сколько стоят локальная копия и непрерывный обмен?	Заставляет учитывать хранение, обновления, сеть, батарею и сопровождение

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

Этот разбор опирается на опубликованное поведение названных сервисов и проектные гипотезы, а не на доступ к их внутреннему коду или метрикам. Предложения о подготовке проекта и рабочего дня, а также о локальных снимках файлов не являются заявлением о планах Notion, Яндекса или Figma. Описанные кассовые устройства не проверялись вместе или по отдельности. Flutter-прототип и замеры задержки, батареи и стоимости сервера для статьи не проводились. Именно эти проверки понадобились бы перед внедрением подобного решения в конкретном приложении.

---

Другие инженерные разборы — в ArkTelos Lab. Об экосистеме и её решениях — на официальном сайте ArkTelos.

Telegram: ArkTelos Lab RU | ArkTelos Lab EN | ArkTelos RU | ArkTelos EN.