Проектирование фронтендов с приоритетом офлайн-режима в качестве реплик: очереди, повторные попытки, конфликты

Фронтенд, который хорошо работает при быстром и стабильном соединении, по сути мало что доказывает. Интересные ситуации возникают тогда, когда запрос застревает, Wi-Fi прерывается, поезд въезжает в туннель, ноутбук переключается между сетями или телефон теряет связь сразу после нажатия кнопки Save. Традиционная архитектура фронтенда рассматривает все эти случаи как исключения: вызывается API, ожидается ответ, обновляется состояние, и процесс продолжается.

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

Исключение сети из критической цепочки

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

User → React → Server
              ↓
            Data

Сервер находится непосредственно в процессе взаимодействия. Медленный сервер означает медленное воспроизведение интерфейса; потеря соединения приводит к остановке сохранений; неудачный запрос заставляет приложение мгновенно решать, что делать с изменениями пользователя.

Подход «сначала офлайн» переносит значительную часть этой ответственности в браузер:

User → React → Local Store
                    ↓
                Sync Later

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

Теперь браузер хранит важные данные

Если приложение должно продолжать работать без подключения к сети, ему необходимо надежное хранилище на устройстве. Для хранения чего-то большего, чем просто небольшие настройки, обычно используется IndexedDB или база данных более высокого уровня, построенная поверх нее. Конкретная библиотека имеет меньшее значение, чем последствия: теперь браузер контролирует данные, потеря которых недопустима.

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

Кэширование данных для чтения — это не то же самое, что работа в режиме офлайн

Это различие легко стирается. Приложение может кэшировать ответы API, но при этом полностью зависеть от сети. Предположим, оно загружает список проектов и сохраняет результат локально, так что список снова появляется без подключения. Это удобно, но это касается только операций чтения.

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

Каждая запись в автономном режиме становится обязательством к синхронизации

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

User Saves
    ↓
Save Locally
    ↓
Update UI
    ↓
Add To Queue
    ↓
Sync When Online

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

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

Когда успех выглядит точно как сбой

Рассмотрим следующую последовательность действий. Пользователь сохраняет данные. Приходит запрос. Сервер успешно записывает данные. Затем, прежде чем ответ вернётся, соединение обрывается. Клиент считает, что сохранение не удалось; сервер же знает, что оно прошло успешно.

Client
  |
  | Save
  v
Server
  |
  | Saved
  X
Response Lost
  |
  v
Client Retries

Если клиент просто попытается выполнить операцию снова, сервер может применить одно и то же изменение дважды. Для идемпотентной операции типа «установить заголовок» это может не иметь последствий, но для операций вроде «добавить элемент», «создать заказ» или «увеличить счетчик» это приводит к появлению дубликатов.

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

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

Оптимистичный интерфейс как выражение намерений

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

Это позволяет четко разделить обязанности:

• Локальное состояние отражает то, что сделал пользователь.

Статус синхронизации показывает, догнал ли общедоступный системный ресурс остальные данные.

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

• сохранён на этом устройстве
• в очереди на синхронизацию
• синхронизируется в настоящее время
• синхронизирован
• требует внимания пользователя

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

Пусть локальное хранилище управляет данными, а React их отображает

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

Более чистая модель передаёт ответственность за постоянное хранение данных надёжному локальному хранилищу, при этом React выполняет роль интерфейса для работы с ним:

Local Store
     ↓
  React UI
     ↓
   User
     ↓
Local Store

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

Когда оба устройства правы

Решение конфликтов — это момент, когда подход «сначала офлайн» перестаёт быть вопросом хранения данных и превращается в проблему распределённых систем. Предположим, кто-то открывает один и тот же документ на ноутбуке и телефоне, и оба уходят в офлайн-режим. На ноутбуке заголовок меняется на Frontend Architecture, а на телефоне — на Offline Architecture. Каждое устройство считает свою правку допустимой, и ни одно из них не знает о существовании другого. Когда оба устройства снова подключаются к сети, возникает конфликт:

Laptop              Phone
   |                   |
   v                   v
"Frontend App"     "Offline App"
   |                   |
   +--------+----------+
            |
            v
         Conflict

Не существует универсально верного способа решения таких проблем. Должна ли побеждать самая свежая правка? Следует ли отдавать приоритет версии с сервера? Можно ли объединить поля? Должен ли выбирать пользователь? Следует ли применять разные правила к разным полям?

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

Для удаленных изменений требуется одинаковый точка входа

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

Local Changes
      ↓
     Sync
      ↓
    Server
      ↓
  New Changes
      ↓
 Local Store
      ↓
      UI

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

Предположим, что сам браузер может выйти из строя

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

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

Service workers — это лишь одна часть, а не вся архитектура

Service workers имеют большое значение, особенно для кэширования ресурсов приложения и перехвата сетевых запросов; если вам нужно вспомнить основы их работы, ознакомьтесь с включением поддержки работы в офлайн с помощью service workers. Однако регистрация такого работника не делает приложение ориентированным на работу в офлайн:

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

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

Сложность перемещается; она не исчезает

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

• Что, если к серверу невозможно подключиться?
• Что, если браузер закроется до завершения синхронизации?
• Что, если запрос пришел, но ответа нет?
• Что, если та же запись изменится на другом устройстве?
• Что, если оба изменения являются допустимыми?

Какой результат считается правильным для этого продукта?

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

Локальные данные требуют такого же уровня безопасности, как и серверные

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

• Храните только то, что клиент действительно нуждается в этом.
• Определите правила истечения срока хранения и действия при выходе из системы.
• Не рассматривайте хранилище браузера как надежный сейф.
• Тщательно решите, какие записи вообще могут находиться на устройстве.

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

Проектирование с учетом возможных сбоев, а не идеального сценария

Примечательной особенностью подхода «сначала офлайн» является то, что архитектура становится более понятной, когда вы перестаете проектировать с учетом идеального сценария. Вопросы меняются:

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

Вместо того чтобы размышлять о том, как внести данные в состояние React, спросите, какая часть системы на самом деле управляет этими данными.

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

Систематическое ответы на вторую версию каждого вопроса приводит к более надежной архитектуре.

Цель — такой опыт использования, который пользователи почти не замечают

У пользователей нет интереса к механизмам синхронизации, транзакциям в базах данных, стратегиям повторных попыток, алгоритмам объединения данных или репликации. Они хотят продолжать работу. Они ожидают, что черновик останется доступен даже после прерывания соединения, что задача, выполненная в поезде, останется завершенной, и что приложение не станет бесполезным сразу же при изменении значка Wi-Fi. Внутренние механизмы могут быть сложными; пользовательский интерфейс не должен таковым быть.

Основные выводы

Единая идея, объединяющая всю концепцию дизайна, заключается в следующем: фронтенд, ориентированный на работу в автономном режиме, представляет собой распределенную систему, в которой браузер хранит вторую копию данных. С этой точки зрения отдельные компоненты получают более четкое назначение:

• IndexedDB — это не просто хранилище в браузере; это часть слоя данных приложения.
• Очередь мутаций — это не инструмент для повторных попыток; это надежная запись намерений пользователя, и каждая запись требует стабильного ID для возможности идемпотентных повторных попыток.
• Оптимистичный интерфейс — это не трюк для ускорения работы; он обеспечивает возможность использования продукта до тех пор, пока бэкенд не сможет синхронизироваться.
• Обработка конфликтов — это не крайний случай; это часть способа, которым продукт определяет свою корректность.
• Синхронизация — это не что-то, что добавляют в конце; это основа архитектуры.

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