Local-first-приложения

Попалась мне недавно статья 2019 года с названием Local-first software. В этой статье авторы предлагают идеологию построения софта, которая меня сильно зацепила.
Сейчас у нас есть две крайности при выборе архитектуры софта. С одной стороны, имеются «старомодные» оффлайновые приложения, в которых все данные для работы хранятся у пользователя на компьютере. Для работы с такими приложениями не требуется постоянное подключение к интернету, если что-то случится с компанией, которая производила такой софт, то никто не мешает продолжать пользоваться последней доступной версией софта. В таких приложениях пользователь полностью владеет теми данными, которые он создает в этих приложениях. В то же время у полностью оффлайновых приложений есть проблемы с синхронизацией данных между устройствами, и почти всегда в таких приложениях невозможно организовать одновременную совместную работу над одним и тем же документом нескольким пользователям.
С другой стороны у нас есть веб-сервисы, в которых все сделано для совместной работы и нет проблем с синхронизацией данных. Пользователю не надо устанавливать сторонний софт, достаточно открыть сайт в браузере. Но расплачиваться приходится тем, что пользователь фактически не владеет данными, которые он создает. Все данные лежат на сервере компании-разработчика, и доступ к ним будет потерян, если компания прекратит существование или перекроет доступ для вашего аккаунта. Кроме этого, веб-сервисы работают заметно медленнее оффлайновых приложений, потому что малейшее действие должно выполняться удаленно на сервере.
Авторы статьи, на которую я дал ссылку вначале, пытаются взять все лучшее из этих двух миров, и такие приложения они назвали local-first software. Согласно этой идеологии такой софт всю работу над данными должен делать на стороне пользователя. В первую очередь это должно быть полноценное оффлайновое приложение, которое может работать без интернета и даже после того, как компания, производящая софт, прекратит свое существование. Сервер должен использоваться только для синхронизации данных между устройствами и организации совместной работы над документом.
В статье авторы вводят 7 признаков, которым должны удовлетворять local-first-приложения:
- Скорость. Для выполнения действий над данными не требуется отправлять данные на сервер или получать данные от сервера, благодаря этому повышается отзывчивость интерфейса. Для выполнения большинства действий не придется смотреть на спиннер, сообщающий о том, что идет обмен данными с сервером.
- Поддержка многих устройств. Должна быть синхронизация. Для этого используется сервер.
- Работа в оффлайне. Для работы не требуется доступ к интернету. Данные можно синхронизировать, когда интернет снова появится.
- Совместная работа. В идеале приложение должно иметь возможность расшаривать данные между пользователями. Это самый сложный пункт, статья во многом посвящена проблемам, связанным с реализацией такой возможности.
- Долголетие. .Возможность редактировать файлы после окончания поддержки приложения разработчиком. Можно продолжить работу даже после того, как компания, разрабатывающая софт, исчезнет.
- Приватность. Сервер не должен хранить данные пользователя в открытом виде. Должно использоваться шифрование.
- Контроль у пользователя. Пользователь всегда может скопировать или обработать файлы из приложения любым другим доступным ему способом. Работа осуществляется над файлами, которые расположены на компьютере пользователя.
В статье авторы сравнивают имеющиеся сервисы по этим признакам: пересылку файлов по email, Google Docs, Trello, Pinterest, Dropbox, Git+GitHub, абстрактные тонкие и толстые клиенты, сервисы удаленных баз данных. Из всего перечисленного по мнению авторов ближе всего к идеалу находится связка git и github, но слабое место этого тандема — слияние файлов и возникающие при этом конфликты.
Самый сложный пункт в этом списке — реализация совместно работы при условии, что нет единого источника истинных данных в виде файла или записи в базе данных на сервере. С git проблема в том, что он использует слишком крупные участки текста при слиянии. Он оперирует строками и абзацами, а нам хотелось бы, чтобы пользователи могли бы изменять слова, расположенные в одном абзаце.
Над решением этой проблемы уже давно работают ученые в области computer science, и еще в 2011 году была написана статья, описывающая формат хранения данных Conflict-free Replicated Data Types, или сокращенно CRDT.Если очень коротко, то идея таких данных заключается в построении дерева документа таким образом, чтобы каждая правка пользователя затрагивала как можно меньшее количество узлов дерева. Слияние изменений сводится к слиянию деревьев. Проблема в том, что для синхронизации требуется хранить много промежуточных данных на сервере, описывающие каждое изменение.
В 2017 году вышла статья про CRDT-версию формата JSON. Есть библиотеки, реализующие работу с данными CRDT (я узнал про local-first-приложения, когда мне попалась ссылка на библиотеку для работы с CRDT на Rust, и я полез смотреть, что это такое и зачем оно нужно).
Кроме этого, разработчики таких приложений столкнутся с проблемой раздачи прав для совместной работы, а также возникнет вопрос о том, что делать с данными у пользователя, если у него надо отобрать права.
Очень интересная концепция, надеюсь, что она когда-нибудь local-first-приложения заменят имеющиеся у нас сейчас веб-сервисы. Что-то уже начинает появляться. Например, редактор кода Zed, похоже, следует этой идеологии. Это полноценный оффлайновый редактор, в котором встроена возможность совместной работы. Будем наблюдать дальше.
PS. Заходите на мой Телеграм-канал, я там стараюсь писать чуть чаще, чем здесь, хотя это не всегда удается.
PS. Вы можете подписаться на новости сайта через RSS, Группу Вконтакте или Канал в Telegram.
В принципе идея хорошая и давно витает в воздухе. Жаль, что мы на работе по такому пути не идём (у нас чистый веб). Но мысли есть.
И да, опять с прошедшим Днём рождения 🙂
13 ноября 2024, 7:59 ппСпасибо большое 🙂
14 ноября 2024, 9:58 дп