На первый взгляд идея local-first приложений кажется идеальной: данные всегда под рукой, приложения мгновенно загружаются, конфиденциальность гарантируется самим фактом отсутствия постоянного обмена с сервером. Но реальность оказалась жёстче: большинство таких проектов не выходят за рамки экспериментов или нишевых решений.
Статья Марко Бамбини Why haven't local-first apps become popular? разбирает главные барьеры. Попробуем углубиться в детали и посмотреть, как эта проблема выглядит глазами инженера.
⚡ Основные препятствия
🕒 Неопределённость порядка событий
В распределённой системе два устройства могут менять одно и то же значение параллельно. Например: телефон офлайн устанавливает x = 3, ноутбук — x = 5. Какой результат считать “правильным”? Без глобальных часов это становится нетривиальной задачей. Решение — Hybrid Logical Clocks (HLC), которые совмещают физическое время с логическим счётчиком, сохраняя причинно-следственные связи.
⚔️ Конфликты изменений
Даже при правильной хронологии остаётся риск перезаписи данных. Тут на помощь приходят CRDT (Conflict-Free Replicated Data Types) — структуры, которые гарантируют:
- 🌀 операции коммутативны (порядок применения неважен),
- 🧩 они идемпотентны (повторное применение не ломает результат).
Самая простая стратегия — Last-Write-Wins: последняя запись по времени побеждает. Но для реальных приложений часто нужны более сложные CRDT, например для документов или совместного редактирования.
📦 Инфраструктурная сложность
Локальная база должна быть кроссплатформенной, надёжной и лёгкой. Здесь идеальным выбором стала SQLite: она везде, не требует серверов и легко расширяется.
🔍 Интересные факты из практики
- 💡 HLC активно применяются не только в локально-ориентированных приложениях, но и в крупных распределённых базах данных вроде CockroachDB и YugabyteDB.
- 🧠 CRDT давно лежат в основе Google Docs и других систем совместного редактирования. По сути, каждый раз, когда мы пишем в онлайн-документ, мы пользуемся результатами этих исследований.
- 📱 Apple в iCloud частично использует похожие механизмы, но тщательно скрывает технические детали — именно поэтому их заметки и фотоальбомы работают надёжнее, чем многие сторонние решения.
👨💻 Моё мнение
Я думаю, что главная проблема local-first подхода даже не в математике или алгоритмах, а в отсутствии унифицированных инструментов для разработчиков. Сегодня программисту нужно вручную встраивать CRDT, проектировать систему синхронизации и отлаживать десятки крайних случаев. Это огромный порог вхождения.
Будущее за библиотеками и фреймворками, которые скроют эту сложность так же, как SQL когда-то скрыл детали работы с данными. Представьте “React для синхронизации”: пишешь логику, а под капотом всё уже решается через HLC и CRDT.
🔮 Что может изменить ситуацию
🛠 Готовые SDK для локально-ориентированных приложений — как Firebase, но без серверного ядра.
📂 Гибридные базы с встроенным FHE и CRDT — безопасность и консистентность из коробки.
🌍 Рост спроса на приватность — если пользователи будут выбирать приложения, гарантирующие офлайн-работу и сохранность данных, индустрия сама подтолкнёт разработчиков.
📚 Источники:
- Marco Bambini — Why haven't local-first apps become popular?: substack.com/p/why-local-first-apps-havent-become