clientful

Как разрабатывать real-time collaborative offline-first приложения без backend сервисов и баз данных Вместо: Client + Backend + DB + Cache + Files storage + Realtime Layer + Kubernetes + Servers Нужны всего-лишь: Client + Files storage + Realtime Layer

От автора

Привет, дорогой читатель, меня зовут Давид Шекунц и я Tech Lead с 12-летним опытом (а еще рассказываю про разработку в 🦾 IT-Качалке 💪)

clientful – это не устоявшийся термин, я его использую здесь, потому что он лучше всего описывает то решения, о которых я здесь пишу.

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

Этой работой я хочу поделиться с вами своим опытом, принципами и трюками, которые я обнаружил для того, чтобы создавать полноценные SaaS-like приложения без backend.

i. Вводные

1. Вся бизнес-логика и все вычисления должны происходить на клиенте

2. Вся работа с БД должны происходить на стороне клиента

3. Система должна поддерживать работу со множества устройств одного пользователя

4. Cистема должна быть многопользовательской

5. Система должна также уметь хранить файлы (фото, видео, аудио, pdf, etc.)

6. Система должна быть безопасной

1. File Storage – внешнее файловое хранилище* S3-like, Google Drive-like или IPFS-like сервисы для персистенции и передачи данных и файлов между устройствами и пользователями. При этом, пользователь может использовать свои собственные хранилища без необходимости нам предоставлять свой backend.

2. Web Socket-like Broker для маршрутизации сообщений между клиентами. Особенность clientful реализации позволит использовать абсолютно любой сервис, который даст возможность подключатся к комнате и бродкастить сообщения всем подключенным пользователям

ii. Преимущества

a. Бизнес

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

2. Скорость интеграции – вся система представляет собой набор из клиентского приложения (например, html, css, js), S3-like хранилища и WS сервера. Это позволяет крайне быстро интегрировать подобные продукты в сторонние системы

3. Own Your Data – данные могут полностью хранится на стороне пользователей и могут быть абсолютно зашифрованы, что может стать критическим преимуществом на фоне ваших конкурентов

4. 99.9999% uptime – приложение или существует на устройствах пользователя и крупных клаудах типа Google Drive, или же подключено к вашему S3 серверу, а значит система имеет наименьшую возможную вероятность падения

5. Максимально интерактивный UI — пользователь никогда не ждет “ответа сервера”, всё меняется локально, поэтому приложение ощущается максимально быстрым, а как только приходят внешние изменения, они моментально отображаются в UI

6. Приложение всегда будет у пользователя – пока у него есть копия вашего html / css / js приложение всегда будет у пользователя и будет работать, поэтому вы можете продавать свой продукт с гарантией, что человек сможет им пользоваться с этого момента и до самого конца

b. Технологически

1. Нет vendor lock-in — нет вообще никакой зависимости от серверных провайдеров

2. Infinite scalability by design — каждый новый пользователь приносит свои ресурсы, нагрузка не растёт

3. Скорость разработки – никаких стейджинг и дев серверов, никакого деплоя 10-ка приложений, никакого kubernetes и даже docker, вам не нужно абсолютно ничего, кроме как разрабатывать клиентское веб или нативное приложение, которому просто нужен CDN и все.

4. E2E тестирование из коробки – вся система это буквально только клиент, поэтому написание теста на клиент это все равно что написать E2E тест, тестирующий всю инфраструктуру

5. LLM-optimized – все приложение это буквально клиентский код, а значит LLM нужен только контекст этого приложения для знания о всей системе.

6. Стабильность работы – как часто технология не работало просто по факту отвала backend приложения, или сервера, или БД? В данной ситуации мы имеем offline-first

7. Offline-first из коробки — приложение работает без интернета, данные всегда под рукой

8. Non-internet connection – вы можете коммуницировать между устройствами на любом протоколе, например, LAN, BLE, I2C и подобные.

9. Возможность централизации – в реальности, если в вашем проекте требуется центральная “БД”, в которой будут хранится все или частично данные, вы можете подрубать свое центральное S3-like / GoogleDrive-like хранилище и публиковать часть контента пользователей туда

10. Real-time-native – как только любое изменение доходит до клиента интерфейс моментально отоюражает

c. Безопасность

1. Меньше attack surface — нет сервера = нет точки атаки для хакеров.

2. Privacy by default — данные не покидают устройство пользователя, не нужно думать о GDPR и утечках.

3. Теоретически невзламываемая система – возможны стратегии шифрования, при которых ключи создаются и всегда находятся на устройствах пользователей, их буквально не существует ни в одном централизованном месте, и даже если скачать из file storage их невозможно будет расшифровать в обратную сторону.

iii. Реализация

1. Алгоритм хранения данных

2. Хранилище

3. Протокол коммуникации

4. Auth / Identity

5. Шифрование

a. Алгоритм хранения данных

1. Использования множества устройств – пользователь, используя приложение на другом устройстве (например, на компьютере и телефоне), должен иметь возможность работать над теми же самыми данными

2. Коллаборации множества пользователей – пользователи должны иметь возможность коллаборативно работать над одними и теми же данными, как по отдельности и видеть сохраненные изменения, так и в real-time

1. Pure P2P – каждый узел равнозначен и может полностью самостоятельно принимать решение

2. Host-base P2P – в какой-то конкретный момент времени или на определенные операции какой-то из узлов должен становится главным и обрабатывать запросы от других узлов

1. Pure P2P
1. CRDT — структур данных и алгоритмы, позволяющие нескольким узлам независимо менять одно и то же состояние, а затем без конфликтов смержить изменения так, чтобы все реплики сошлись к одному результату.
2. CouchDB — eventual consistency документная БД и протокол репликации: узлы обмениваются версионированными документами, а конфликты фиксируются как альтернативные версии и требуют стратегии разрешения (то есть merge не “магический”, как у CRDT, а задаётся моделью/логикой приложения).
3. Blockchain — распределённый журнал (ledger), где узлы приходят к единому порядку транзакций через механизм консенсуса (PoW/PoS и т.п.). Это “демократия” в том смысле, что нет доверенного центра, но “демократия” достигается ценой дорогого консенсуса.
4. Git-like log – пользователи буквально или руками, или автоматически по логике приложения создают на изменения ветки, а потом, при обмене сообщениями мерджат друг в друга.

2. Host-base P2P
1. OT — подход к коллаборативному редактированию, где изменения представляются как операции (insert/delete/replace и т.д.), а при конкуренции операции трансформируются относительно друг друга так, чтобы все пришли к одному результату.
2. PAXOS / Raft — алгоритмы консенсуса для репликации лога в кластере: группа узлов выбирает лидера, лидер принимает команды (записи в лог), реплицирует их на кворум.

1. Yjs — одна из самых распространенных библиотек CRDT

2. Automerge – еще одна реализация CRDT, но хранит данные как неизменяемый граф (как git дерево)

3. OrbitDB – бд основанная на “жернале операци” поверх CRDT, с встроенным протоколом коммуникации libp2p поверх IPFS и расширенными операциями над CRDT структурами

4. PouchDB – реализации CouchDB протокола на клиенте

5. Gun.js — распределенная графовая БД с P2P синхронизацией

6. Hypercore – распределенный append-only иммутабельный лог (и куча экосистемы вокруг)

7. SQLite + CRDT – библиотеки, которые объединяют CRDT и sqlite
1. CR-Sqlite
2. Sqlite-sync

Но в реальности смысл имеет только CRDT

1. OT – чаще всего, все-таки предполагает единый узел, который будет собирать последовательность операций.

2. CouchDB – протокол разрабатывался с идейей eventual consistency DB, в которой клиенты могут поключаться к центральным узлам и трансформировать часть данных. И на данный момент, попытки сделать его полностью P2P правда существуют, но они абсолютно эксперементальны.

3. PAXOS / Raft – вот они вполне себе возможны, но они имеет преимущество над CRDT, когда (а) вам нужна строгая транзакционность, (б) вы можете доверять одному из участников. Сложность реализации настолько большая, что смысл прибегать в PAXOS / RAFT только если нет никаких других вариантов решения вопроса.

4. Blockchain – практически схож с PAXOS / Raft, но требует доверия не к 1 узлу, а большинству узлов, но точно также имеет такую большую технологическую сложность, что его использование должно иметь невероятно весомую причину.

5. Git-like log – интересная модель, НО предполагает или разруливание со стороны пользователя, или просто не подходит для большого количества бизнес-кейсов.

Бонус

1. SQLite – даже без встроенного CRDT, вы можете сохранять CRDT контент прямо в sqlite базу, может быть полезно, если вы хотите, например, часть этого контента индексировать.

2. PGlite – тоже самое, что и SQLite, но только буквально PostgreSQL на WASM (причем, работающий, так еще и с extensions).

3. DuckDB – аналитическая встраиваемая БД, которая умеет даже в подгрузку файлов по URL (например, напрямую из S3), что делает ее идеальным кандидатом для использования в clientful.

4. LanceDB – тоже самое, что и DuckDB, но векторная и из коробки предполагающая хранение во внешних файловых хранилищах

b. Хранилища

1. Удаленные
1. Google Drive-like – идеальный кандидат, потому что такие хранилища есть у большинства клиентов, а значит, есть возможность полностью перенести хранение файлов на них
2. S3-like – любой Minio, rustfs, Cloud S3 идеально подходит для данной задачи
3. CDN-like – использование любого CDN провайдера для загрузки и скачивания файлов
4. IPFS / Filecoin — децентрализованное крипто-хранилище
5. Nostr-like — децентрализованный протокол хранения/обмена данными без сервера.
6. Torrent – и опять же, почему нет, это буквально протокол для P2P передачи и хранения данных.
7. Git-like – использовать git репозитории для персистенции и передачи файлов? А почему нет?

2. Локальные
1. Browser Local Storage / IndexedDB / OPFS — нативное браузерное хранилище, идеально для client-side first
2. File System – буквально локальная файловая система

c. Communication

1. WebRTC – возможность p2p соединения клиентов

2. WebSocket – постоянное двустороннее соединение через TCP

3. QUIC – свеженький протокол на UDP, с гарантиями TCP и защищенностью TLS

Holepunch

The Peer to Peer Company. Holepunch has 613 repositories available. Follow their code on GitHub.

https://github.com/holepunchto

d. Auth / Identity

1. Google Drive-like OAuth
• Используем OAuth провайдера как источник идентичности (Google/Microsoft/и т.д.).
• Токены нужны не только для login, но и для доступа к File Storage пользователя (Drive/Dropbox/etc.) — то есть авторизация на операции чтения/записи файлов происходит “встроенно” через провайдера.
• Плюсы: минимальный UX friction, понятная модель доступов, часто уже есть у большинства пользователей.
• Минусы: зависимость от провайдера, ограничения/квоты API, возможные сложности с shared-папками и доступами между пользователями.

2. Sign-in with Ethereum (SIWE)
• Идентичность = владение приватным ключом кошелька; вход = подпись challenge (nonce) сообщением.
• Авторизация между пользователями может строиться через on-chain / off-chain ACL: например, “кто может читать/писать” определяется списком адресов и ролей.
• Плюсы: переносимая идентичность, нет центра, удобно для web3/комьюнити продуктов.
• Минусы: UX/seed-фразы, кошельки/chain-specific, сложнее для массовой аудитории; всё равно часто нужен внешний канал доставки данных (storage/broker).

3. Local-first keys (device/user keys)
• Идентичность строится вокруг локально сгенерированных ключей (например, Ed25519/X25519):
• ключ устройства (device key) + ключ пользователя (user key) +/или ключи рабочих пространств (workspace keys).
• Публичные ключи распространяются через File Storage/реестр/инвайты; приватные никогда не покидают устройства.
• Авторизация = подписи и capability-токены (например, “этот ключ может писать в эту папку/документ”).
• Плюсы: максимально соответствует идее clientful/privacy-by-default, можно сделать E2E-шифрование.
• Минусы: восстановление доступа (recovery), ротация ключей, онбординг новых устройств, отзыв доступов.

4. AT Protocol (Bluesky stack)
• Идентичность = DID (Decentralized Identifier), привязанная к handle/домену; переносимость аккаунта обеспечивается протоколом.
• Можно использовать AT как “identity + directory + transport” слой, а данные приложения хранить в File Storage, привязывая права к DID.
• Плюсы: децентрализованная идентичность, встроенные механизмы репликации/федерирования, потенциально удобно для social-like продуктов.
• Минусы: стек относительно специфичен; придётся аккуратно разделять, что живёт в AT, а что — в вашем файловом хранилище/CRDT-данных.

e. (coming soon) Шифрование

f. Backend-like

iv. Сложности

1. Зависимость от реализации CRDT

2. Только коллаборация

• Использовать подписи приватными ключами и проверку публичными на каждую операцию и в случае некорректности помечать как ненадежные

• Использовать Merkel Tree для пересчета состояний сущностей с учетом подписей

• Использовать blockhain-like структур

• Или назначать 1 master-клиента, который может принимать решения об легальности того или иного действия

3. Неконсистентные состояния

1. Группа людей работает над каким-то документом, один из них садится в самолет

2. Пока он в оффлайне, он удаляет этот документ.

3. Остальные продолжают работать с тем документом.

4. Когда он попадает в онлайн, его состояние синхронизируется и так как никто не “отменял удаление”, этот документ реально “удалится”, даже если его коллеги работали над ним

• При “удалении” сначала перемещать документ в “корзину”, а не удалять, и при выходе в онлайн, если надо документом была проведена работа, то восстанавливать его автоматически

• Или запрещать удалять документы в оффлайне

• Или формировать задачу “удаление”, но не применять ее, пока пользователь не вышел в онлайн и не увидел изменения коллег

4. “Если Х то можно / нельзя Y” не работает

1. Клиент А создает пост

2. Клиент Б получает этот пост

3. Клиент А создает к нему комментарий

4. Клиент Б видит комментарий

5. Клиент А удаляет пост и вместе с ним все (один) комментарий

6. Клиент А пытается создать к посту новый комментрий, но его запрещают это сделать, потому что поста уже нет

7. Клиент Б еще не получил информацию про удаленный пост, поэтому спокойно создает второй комментарий

8. Клиент А и Б получают изменения друг друга и получается, что пост удален, а при этом второй комментарий будет существовать

1. Aftermath Compensation – после обновления состояния смотреть есть ли комментарии без постов и удалять их

2. Preemptive Compensation – создавая комментарий (в локальной транзакции) “пересоздать пост, если вдруг он не существует”, то есть вы отправляете всем клиентам и свой комментарий, и пост, к которому вы его создали, а значит, даже если он был удален у клиента А, он будет заново у него создан.

3. Conflict management – видеть этот конфликт и выводить сообщение пользователям о нем (причем, например, не удалять пост полностью пока он не синхронизируется у большинства узлов)

5. Классические проблемы оффлайн приложений

• Миграции данных – вы должны помнить, что данные у клиента уже лежат и нельзя просто взять и “удалить ключ и поменять его на новый”, вы должны будете в какой-то момент времени мигрировать данные из старого формата в новый

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

• Разные версии на разных устройствах

v. Что мы имеем в сухом остатке

vi. Что нас ждет дальше

1. Буду рассказывать и показывать как строится библиотеки для clientful

2. Реальные примеры проблем clientful приложений и используемых технологий и их решения

3. Разборы существующих проектов

4. Изучать вопрос транзакционности в подобных системах

5. Как clientful встраивается в текущую экосистему AI пайплайнов и агентов

6. Структуры, которые расширяют возможности CRDT (Merkel Tree, Merge Tree, etc.)

7. Авторизация операций

vii. Полезные ссылки

a. Технологии формата clientful

1. GitHubGitHub - alexanderop/awesome-local-first: Useful Links for Everything related to LocalFirst
   

   GitHub - alexanderop/awesome-local-first: Useful Links for Everything related to LocalFirst

   Useful Links for Everything related to LocalFirst. Contribute to alexanderop/awesome-local-first development by creating an account on GitHub.

   GitHub

2. www.localfirst.fm

3. Pears_p2pPears | Unleash the Power of P2P
   

   Pears | Unleash the Power of P2P

   Empowering Developers, Disrupting the Norm!

   Pears_p2p

b. Транзакции в P2P системах

1. YouTubeCRDT Research Meetup // AntidoteDB - Nuno Preguiça
   

   CRDT Research Meetup // AntidoteDB - Nuno Preguiça

   Originally recorded during the Lisbon Hack Week from May 21-25, 2018, this talk provides an overview of AntidoteDB and other CRDT-related projects on-going at NOVA LINCS. AntidoteDB (antidotedb.eu) is an open-source geo-replicated database that provides high availability while ensuring strong semantics for applications. To this end, AntidoteDB features CRDTs for providing data convergence, highly available transactions for providing atomic operations over multiple objects, causal consistency for enforcing the causal relations among updates, and mechanisms for enforcing global invariants without compromising availability. AntidoteDB is being developed in the context of EU H2020 LightKone project.

   YouTube

2. YouTubeAnnette Bieniusa - AntidoteDB: highly available, transactional database - Code BEAM Lite Munich 2018
   

   Annette Bieniusa - AntidoteDB: highly available, transactional database - Code BEAM Lite Munich 2018

   This video was recorded at Code BEAM Lite Munich 18: https://codesync.global/conferences/cbl-munich-2018/ Get involved in Code BEAM Lite conference: https://codesync.global/conferences/code-beam-lite-italy/ --- TALK TITLE AntidoteDB: a planet scale, highly available, transactional database by Annette Bieniusa Cloud-scale applications must be highly available and offer low latency responses while serving an ever-growing number of users concurrently. To achieve these goals, these apps rely on distributed cloud data stores that provide availability even under network partition. It takes significant effort and expertise from programmers to understand the intricate semantics and develop correct applications on top of such highly available databases. In my talk, I will show how AntidoteDB supports a principled approach to build highly-available, yet correct applications by combining conflict-free replicated data types (CRDTs), highly-available transactions and stronger synchronisation mechanisms. --- TALK OBJECTIVES You will learn how conflict-free replicated datatypes (CRDTs), transactions, and causal consistency interact to keep application data safe. Further, you will see how to identify patterns in your application that have specific synchronisation requirements und learn how to employ them with AntidoteDB. --- THEMES Consistency CRDTs AntidoteDB --- Code BEAM Lite LDN was brought to you by Code Sync. CODE SYNC Website: www.codesync.global Twitter: www.twitter.com/CodeMeshIO Facebook: https://www.facebook.com/CodeSyncGlobal LinkedIn: https://www.linkedin.com/company/code-sync/ Mail: info at codesync.global

   YouTube

c. CRDT

1. ElectricSQLIntroducing Rich-CRDTs | ElectricSQL
   

   Introducing Rich-CRDTs | ElectricSQL

   Rich-CRDTs are conflict-free data types extended to provide additional database guarantees.

   ElectricSQL

2. EDB Postgres Distributed (PGD) v4.3.8 - Conflicts
   

   EDB Postgres Distributed (PGD) v4.3.8 - Conflicts

   BDR is an active/active or multi-master DBMS. If used asynchronously, writes to the same or related rows from multiple different nodes can result in data conflicts when using standard data types.