Local-first архитектура

Данные живут на клиенте, сервер опциональный. Offline работает по умолчанию, синхронизация в фоне через CRDT, WebSocket, WebRTC.

Что это

Классическая web-архитектура: сервер — источник истины, клиент — окно. Без сети не работает.

Local-first: клиент хранит полную копию своих данных локально (OPFS, IndexedDB). С сетью — синхронизируется с другими узлами и/или сервером. Без сети — работает полностью. Сервер не обязателен и уязвим (single point of failure).

Стек технологий

┌─ UI (фронтенд-фреймворк, любой)
├─ State / Store (адаптер под привычный store)
├─ CRDT — разрешение конфликтов
├─ Persistence — OPFS / IndexedDB
├─ Sync transport — WebSocket / WebRTC / Service Worker
├─ Discovery — Blockchain или DHT (адреса нод)
└─ Crypto — Web Crypto (подписи, шифрование)

Компоненты

  • CRDT (Conflict-free Replicated Data Types) — структуры данных, у которых merge коммутативен и идемпотентен. Два клиента редактируют offline → при синке нет ручного разрешения конфликта.
  • OPFS (Origin Private File System) — приватная ФС в браузере, быстрее IndexedDB.
  • Service Worker — прокси сети, кэш, фоновая синхронизация, шина между вкладками.
  • WebSocket — синхронизация с сервером/нодами.
  • WebRTC — P2P между клиентами в одной локальной сети, без сервера.
  • Blockchain — публичный реестр адресов нод (не для денег, а для discovery).
  • Web Crypto — подписи операций для верификации.

Производительность / Подводные камни

  • Service Worker умирает через 30 сек — 5 мин после закрытия вкладок. WebSocket держит его живым.
  • WebSocket периодически отпадает — три проблемы переподключения: потеря событий между разрывами, дубли, порядок.
  • WebRTC только во вкладках — нужна «ведущая» вкладка через web.locks.
  • WebRTC не гарантирует порядок — поверх UDP-природа DataChannel; для упорядоченности — ordered: true в config.
  • WebRTC обходит ограничение origin — клиенты разных origin могут общаться напрямую.
  • Барьер входа высокий — нужны OPFS-tools (типа phpMyAdmin для блокчейна), npm-готовые компоненты.
  • Adapter под привычный store — иначе фронтендеры не будут использовать.

Изоляция слоёв в Metarhia-варианте

автор разделяет три слоя, ничего не знающих друг про друга:

  • UI ⟂ бизнес-логика
  • Бизнес-логика ⟂ сеть
  • Sync layer скрыт за Global Storage

Бизнес-логика пишется один раз и может исполняться:

  • В таб-вкладке
  • В Service Worker
  • На сервере
  • В тесте (mock-транспорт)

«Из-за того, что у нас всё отделено одно от другого Global Storage, это как раз и есть принцип Local First. UI и бизнес-логика работают как будто с локальным сториджем.»

Подменяемые стратегии

Все слои — Strategy pattern на уровне архитектуры:

  • Транспорт: WebSocket / WebRTC / MessagePort
  • Storage: OPFS / IndexedDB / Postgres / Redis
  • Sync: CRDT / operation log / patch-based / pessimistic

Зрелость экосистемы

  • Production-ready: Yjs, Automerge, Replicache, PouchDB.
  • В разработке: Metarhia GlobalStorage с CRDT + blockchain discovery.
  • Барьер входа: нужны OPFS-tools (типа phpMyAdmin для блокчейна), npm-готовые компоненты, adapter под привычный store — иначе фронтендеры не подключаются.

Слой sync — не катите свой

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

🎓 Источники

См. также