Конспект выступления Martin Kleppmann: The past, present, and future of local-first

22.06.2024

Рассказ про историю появления понятия Local-first в 2019 году и во что это эволюционировало к 2024 году: The past, present, and future of local-first - Martin Kleppmann (Local-First Conf), 30 минут.

Автором первоначальной концепции является непосредственно Martin Kleppmann, в соавторстве с Adam Wiggins, Peter van Hardenberg, Mark McGranaghan (лаборатория Ink&Switch). Данный термин они ввели в обиход в статье «Local-first software. You own your data, in spite of the cloud».

−

Это вводный доклад с первой Local-First Conf, прошедшей в конце мая в Берлине.

• В плейлисте конференции на текущий момент размещены ещё 16 докладов.
• На сайте доступна информация по всем спикерам и организаторам мероприятия (там много отслеживаемых мною проектов и персоналий, что радует :0)

Текст ниже по формату ближе к транскрипту, а не к конспекту (подобные выступления предпочитаю фиксировать максимально подробно).

Предыстория от докладчика

—

Началась всё с того, что Martin Kleppmann и ребята из Ink & Switch начали разработку проекта Automerge CRDT в 2017 году.

У Martin к тому времени был опыт теоретических изысканий и разработки с использованием CRDT. В частности, в 2015 он написал простенький редактор на Ruby с поддержкой данной технологии (который был ужасен :0)

Первая версия библиотеки Automerge была написана на JS и поддерживалась несколько лет, в 2022 году он переписал её на Rust.

В процессе работы над Automerge у команды и формализовалась концепция Local-first, о которой они в 2019 году написали эссе.

—

Local-first за 5 лет превратился в настоящее движение

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

—

Но такой взрывной рост интереса к концепции привел к непониманию. По мере того, как люди присоединялись к сообществу, они задавали очень разумные вопросы. Local-first, это:

• просто ребрендинг термина «offline-first» (2013)?
• просто «приложение, использующее CRDT»?
• Peer-to-peer или облако или оба?

Определение local-first

Причина, по которой авторы ввели новый термин ➜ Они хотели отобразить что-то новое, нечто большее, что было отражено в термине offline-first. Поэтому они сформулировали 7 идеалов:

—

Идея была в том, что если приложение отвечает всем | большинству этих пунктов, то его можно будет называть local-first. Тут может быть и градиент, а не просто да | нет.

Но со временем команда пришла к пониманию, что обозначенные ими в эссе 7 идеалов не являются хорошим определением того, что такое local-first. Их правильнее, с точки зрения конечного пользователя, называть «преимуществами», которые несут подобные приложения.

—

Обновленное определение local-first

Удобнее всего его показать на противопоставлении. Эта цитата является хорошей иллюстрацией того, что авторы хотели избежать с помощью local-first:

Очень знакомо большинству пользователей? Многие современные приложения и сервисы ведут себя именно таким образом. Из свежих примеров, когда падают сервера у Notion, Github или просто массово в мире валится интернет, то работать с ними становится невозможно.

Соответственно:

Важные составляющие данного определения (к чему его относить):

• это программное обеспечение для работы на нескольких устройствах (есть синхронизация данных),
• обязательно есть поддержка полноценной оффлайн-работы (включает в себя понятие offline-first),
• не зависит от разработчиков приложения и их серверов. Даже если они обанкротятся и отключат сервера, то вы все-равно сможете пользоваться приложением.

Local-first ➜ Это надежность. Не только в отношении сетевой доступности (когда сеть не работает), но и в отношении привязок к другим компьютерам (выходят из строя, отключены).

Вариации того, как можно реализовывать обновленную концепцию

—

Incredible journey ➜ Давний прикол про то, как очередной стартап пишет письмо о «невероятном путешествии», которое он совершил вместе со своими пользователями: спасибо, всё было прекрасно, но мы закрылись. Есть даже сайты, которые коллекционируют такие «письма счастья».

Крупные корпорации а-ля Google в этом плане недалеко ушли от стартапов и тоже регулярно закрывают свои сервисы.

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

Обновленная концепция local-first предполагает, что пользователь будет избавлен от подобных проблем («не зависим от разработчиков приложения и их серверов»).

Есть 3 явных и распространенных варианта решения, все они не очень удачные, хотя и могут послужить отправной точкой:

• Open source server, можно организовать self-host ➜ требуются технические навыки, но даже если они есть, то мало кто хочет заниматься обслуживанием серверов.
• Peer-to-peer синхронизация ➜ Технология до сих пор не обкатана. Все узлы могут быть одновременно недоступны. Есть сервисные функции, завязанные на доступность. Для надежности приходится настраивать узел-сервер. А если предполагается сервер, то проще уж классическую синхронизацию в своем приложении делать.
• Синхронизация через облачные файловые хранилища ➜ Надежно, но ключевой минус, что они заточены под файлы. Real-time обновления технически не приспособлены поддерживать.

А вот последний вариант — multiple interoperable sync providers — Martin считает лучшим решением.

The Local-first Endgame

—

Дано:

1. У пользователя одновременно есть несколько разных local-first приложений на разных устройствах. Они должны синхронизироваться между собой. Людей не волнует как это происходит.
2. Так как приложения у нас Local-first, то вся логика и данные у нас по умолчанию на устройстве. Мы синхронизируем лишь изменения.

Martin предложил концепцию Generic syncing service (предполагается, что в дальнейшем он будет работать параллельно с p2p) ➜ Универсальный сервис синхронизации, который поддерживается всеми вашими local-first приложениями. Они дружно через него гоняют свои данные, а не придумывают каждый свой собственный велосипед.

Это должен быть достаточно простой протокол, не привязанный к каким-то конкретным моделям данных или типам файлов и работающий поверх них. Он просто перемещает небольшие пакеты байтов (изменения).

В текущий момент такого стандартизированного Generic syncing service нет. И сейчас стоит задача

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

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

—

Логичное продолжение данной идеи, что пользователи смогут арендовать подобные сервисы синхронизации, как сейчас арендуются другие ресурсы в AWS | Azure | где-то ещё… А в приложениях указывать лишь адрес, каким сервисом он хочет пользоваться в данный момент.

Бенефиты для разработчиков приложений

—

Это ещё один момент, который авторы пропустили в первоначальном эссе пять лет назад ➜ Local-first приложения рассматривались в нем только с точки зрения их удобства для конечного пользователя. С тех пор Martin с командой пришли к пониманию, что преимущества для разработчиков возможно не менее важны.

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

• Своя команда инженеров серверной части. А это комплексная проблема, с которой приходится сталкиваться стартапам (написание облачных сервисов, управление конфигурацией AWS, devops и т.п.).
• Обеспечение круглосуточной доступности инженеров для мониторинга и поддержки серверной составляющей.

Модель разработки становится проще по сравнению с созданием облачного ПО ➜ no more writing network error handling code. И не нужно беспокоится об оплате инфраструктуры в облаке.

Вместо этого разработчики приложений могут сосредоточиться на тех частях приложений, где они действительно отличаются друг от друга:

• создание действительно хороших пользовательских интерфейсов и взаимодействий с пользователями (UI/UX).
• обеспечение того, чтобы конечные пользователи были очень хорошо осведомлены о цели, которой служит приложение (онбординг, справка и т.д.).

Изменение экономики разработки приложений

—

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

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

➋ Local-first хорошо подходит для создания прототипов. Это уже подтвержденная практика, есть примеры того, как небольшие команды за 1-2 недели создавали подобные приложения.

—

Проблема: будет ли традиционная SaaS бизнес-модель по прежнему работать в эпоху Local-first?

Martin надеется, что да :0)

При традиционной модели у разработчиков есть оружие, которое они могут направить на пользователей. То, что на жаргоне стартапов называется «the data moot» ➜ данные спорны. Рычаг на пользователя, возможность в любой момент пригрозить ему, что «если не заплатишь за подписку, то мы удалим твои данные». В local-first это оружие сильно ослаблено.

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

Технологии для Local-first

—

Помимо Automerge, которым занимается Martin, на рынке уже много других решений для Local-first (библиотеки, фреймворки, протоколы, приложения).

Здорово, что в этой экосистеме происходит такая оживленная активность. Но простой ответ пока заключается в том, что мы не знаем что из этого будет работать, а что нет. Поэтому нам нужно, чтобы эти «1000 цветов» распустились (проекты от разных команд). Чтобы мы могли получить опыт применения различных подходов и лучше понять компромиссы.

Поэтому прямо сейчас еще рано говорить о стандартизации протокола для «Generic syncing service». Martin считает, что текущая фаза «экспериментов» займет 2-3 года, после этого можно будет создавать комитет по стандартизации.

Local-first ➜ Это набор принципов и ценностей. А не просто какая-то одна технология

Как резюме всего выступления. Опора на данные принципы и ценности — лучший путь для создания приложений.

Комментарии для себя

2024/06/22

➊ Авторы эссе про Local-first планируют опубликовать дополнение к нему, с учётом опыта за прошедшие 5 лет. Как разместят у себя на сайте, то обязательно отдельно про него напишу.

—

➋ Относительно приложений-аутлайнеров (моя область исследований) ➜ Их разработчикам точно есть к чему стремиться. Как минимум, последний пункт из обновленного определения local-first у всех страдает.

Получается, что большинство аутлайнеров правильнее относить пока к offline-first приложениям.

—

➌ В качестве дополнительного материала можно посмотреть видео от Jess Martin, основателя DXOS, про 4 пока нерешённых проблемы, мешающих разработке полноценного коллаборативного Local-first software: partial sync; permissions; schema migrations; generic sync servers.

И про потенциальные решения этих проблем (половина по его мнению пока в подвиснутом состоянии).

Видео он записал как раз по итогам выступлений и обсуждений на Local-First Conf. Оно короткое на 7 минут.

—

➍ На самом деле у разных проектов всё же есть свои наработки по реализации Generic syncing service (хотя об устоявшейся модели рано говорить).

В ответ на видео из предыдущего пункта разработчики jazz.tools написали развернутый комментарий:

jazz.tools is built on top of what will be an open protocol (called CoJSON) that forms a minimal core of basic CRDTs, how to sync them and how to model identity & permissions on top of them (based on account keys, encryption and signatures)

It's designed so that the sync server is completely app-independent and untrusted (thanks to encryption). CoJSON is very small and as unopinionated as possible to allow implementation in as many languages and environments as possible.

As the name suggests, CoJSON just tries to be "collaborative JSON", everything more complex than that (like schemas) are delegated to frameworks.

It takes the pragmatic view that even without schemas or help from a third party app, you can work with the JSON you get out of it.

The hope is that this allows for an ecosystem of different high-level frameworks (not just jazz.tools) on top of it, while still achieving

• interop between different apps
• meaningful app-independent data ownership (thanks to key export and to-be-standardised formats)

Tags

• Local-first
• Malleable Software