Тендеры и лиды
Информация
От редакционных приложений в 2025 году ждут того же, что когда-то обеспечивали десктопные системы: возможность продолжать работу без сети и уверенность, что всё будет синхронизировано автоматически, без ручных попыток восстановить потерянное.
В первой части цикла статей про офлайн-сервисы рассказали про технологические решения в производственной и логистической сферах, в этой – покажем, как крупные медиа переходят на стек, который позволяет редакции работать так, будто интернет есть всегда.
Нестабильный интернет приводил к сбоям в редакционных процессах крупного международного бренда, который занимается выпуском газеты для москвичей и петербуржцев со средней прочитываемостью в 21.4 млн человек.
В случае нашего кейса, ПО для редактирования изданий, выпусков, тиражей и страниц было устаревшим и Desktop-ным. А у бизнеса накопились запросы, которые невозможно было реализовать вне open-source решений.
Красивым и экономичным выходом из ситуации стала разработка веб-приложения, которое ощущается как нативное десктоп-ПО, но работает в браузере и не зависит от качества соединения. Его главная задача – обеспечить непрерывность всех ключевых операций, сохранить порядок действий редакторов и гарантировать, что ни одно изменение не потеряется даже при полном отсутствии сети
1. Все потоки данных проходят через Persistent Cache + активно используется мутация
Команда выбрала стратегию offline-first – это когда приложение изначально проектируется так, будто у пользователя нет стабильного интернета. Оно должно запускаться мгновенно, показывать данные из локального хранилища и позволять выполнять ключевые действия без подключения. Как только сеть появляется, все изменения автоматически отправляются на сервер и приводятся в актуальное состояние.
Для создания такой среды используется комбинация PWA + Service Worker + React Query + Persistent Cache (IndexedDB):
PWA отвечает за то, чтобы приложение работало как самостоятельный клиент: быстро стартовало, сохраняло статику и было доступно даже при полном офлайне.
Service Worker берёт на себя кэширование и фоновую синхронизацию, позволяя загружать скрипты, стили и контент без запросов к серверу.
React Query управляет данными: хранит их в памяти, оптимистично обновляет интерфейс и сортирует все изменения в понятные очереди.
А persistent cache в IndexedDB обеспечивает долговременное хранение – изменения сущностей идут в основном через мутации, чтобы можно было восстановить последовательность действий в нужном порядке (через ключи) и отследить их статус в любом месте приложения.
Также ключи имеют запросы данных – это позволяет сохранять, находить и менять данные в кэше (результаты GET – просмотр выпусков, страниц, превью, а также очередь POST/PATCH/DELETE, вызванных в офлайне) при оптимистичном обновлении UI.
Наша система сама подберет вам исполнителей на услуги, связанные с разработкой сайта или приложения, поисковой оптимизацией, контекстной рекламой, маркетингом, SMM и PR.
Заполнить заявку
13215 тендеров
проведено за восемь лет работы нашего сайта.
Для работы с файлами важно корректно разрешать ситуации, когда один и тот же материал меняют несколько людей, или когда устройство долго было офлайн. Чтобы избежать потери данных, используется отдельный фоновый скрипт на бэкенде, который занимается синхронизацией и проверкой версий.
Каждый файл или сущность имеет свои поля updatedAt и version. Когда приложение пытается отправить изменения, скрипт сравнивает версии: если на сервере файл уже обновлён кем-то другим, возникает конфликт версий. В этом случае скрипт не даёт тихо перезаписать чужие изменения, а отправляет пользователю уведомление в операционной системе с описанием проблемы.
Дальше редактор уже принимает решение, что делать: оставить свою версию, просмотреть различия или объединить изменения. Приложение поддерживает несколько состояний для таких ситуаций, чтобы бизнес-процесс не ломался, а редакционная работа оставалась прозрачной и управляемой.
Чтобы редактор всегда понимал, что происходит с данными, в приложении предусмотрен набор наглядных индикаторов состояния. Они показывают текущее качество связи, статус синхронизации и работу очереди мутаций.
Плашки «онлайн/офлайн» отображает для пользователя информацию, есть ли сейчас интернет и будет ли операция отправлена сразу или попадёт в очередь. Счётчик очереди показывает, сколько изменений ждут отправки. Если всё успешно ушло на сервер, пользователь видит соответствующее уведомление. Если что-то пошло не так, отображается ошибка с расшифровкой и кодом, а в отдельном меню можно посмотреть подробности: какой запрос выполнился, какой не прошёл, почему, и что система делает дальше.
Такая прозрачность снимает тревожность у редакторов и уменьшает нагрузку на поддержку. Пользователь видит, что приложение не «зависло», а работает предсказуемо: либо ждёт сеть, либо отправляет запросы, либо повторяет их при ошибках. Все процессы понятны и контролируемы без обращения к команде разработки.
После внедрения платформа стала стабильно выдерживать редакционные циклы и сократила нагрузку на команды. Результат оказался особенно заметен в пиковые периоды.
Вот что изменилось:
Offline-first уже перестал быть просто удобной технологией. Для медиа это способ защитить производство контента от внешних факторов и сделать процессы стабильными в любой ситуации. В итоге выигрывают все: редакция работает спокойнее, бизнес получает меньше рисков, а продукт становится надёжным инструментом, который не подведёт в самый ответственный момент.
И самое интересное: подобный подход можно применять далеко за пределами издательской индустрии. Сервисы комментариев, заметок, CRM-операций – почти любой продукт содержит действия, которые должны выполняться без сети. А вы хотели бы себе бесперебойно работающий продукт? Напишите нам.
