Yjs или опрос базы данных для команд совместного редактирования

Почему этот выбор потом создает проблемы

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

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

Демки скрывают это, потому что в демках почти нет давления. Большинство команд тестирует редактор в коротких сессиях, со стабильным интернетом и с одним человеком, который вносит аккуратные правки. Реальная работа куда беспорядочнее. Кто-то оставляет ноутбук спящим в поезде, кто-то продолжает печатать через слабый гостиничный Wi‑Fi, и оба ожидают, что документ потом будет иметь смысл. Если редактор построен на опросе строк из базы данных, обработка конфликтов часто остается поверхностной до первого серьезного перезаписывания.

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

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

Пользователи замечают одно потерянное предложение раньше, чем заметят задержку в сто миллисекунд. Как только доверие потеряно, редактор кажется сломанным, даже если интерфейс по-прежнему выглядит аккуратно.

Как каждый подход передает изменения

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

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

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

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

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

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

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

Где конфликты проявляются первыми

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

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

Представьте общую продуктовую заметку. Один редактор меняет «Запуск в понедельник» на «Запуск во вторник». В то же время другой меняет ее на «Мягкий запуск в понедельник». При подходе с опросом после следующего цикла сохранения может остаться только один вариант. Никто не получает понятного предупреждения, и команда замечает несоответствие позже.

Почему Yjs ощущается иначе

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

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

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

Структурированный контент даже с Yjs все равно требует правил. Комментарии, таблицы и упоминания не ведут себя как обычный текст. Если два человека правят одну ячейку таблицы, вам нужна политика. Если один удаляет ветку комментариев, а другой отвечает на нее, вам нужна политика. Если кто-то переименовывает или удаляет упомянутого пользователя, вам тоже нужна политика. Yjs может перенести эти изменения, но продукт все равно должен решить, что они означают.

Вот что команды часто упускают. Слияние текста — это только первый слой. Более сложные конфликты сидят в функциях документа, которые окружают этот текст.

Что на самом деле переживают офлайн-пользователи

Большинство команд считают офлайн-редактирование редким пограничным случаем. Это не так. Связь пропадает в поездах, лифтах, у клиентов и во время нестабильного переключения между сетями. Когда это происходит, пользователи задают один простой вопрос: «Мой текст сохранился?»

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

Эта очередь важнее, чем ожидают команды. Без нее переподключение может превратиться в хаос. Пользователь возвращается онлайн, приложение получает более свежий контент с сервера, а локальный черновик может перезаписать его, продублировать части или просто исчезнуть. Сам по себе опрос не решает обработку конфликтов при офлайн-режиме. Команде приходится придумывать правила самостоятельно.

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

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

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

Живое редактирование впечатляет в демке. Поведение после переподключения — это то, что пользователи вспоминают на следующий день.

За что вы платите в эксплуатации

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

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

Если опрашивать каждые 2 секунды, вы покупаете более быстрые обновления, но получаете постоянную нагрузку. Если опрашивать каждые 10 или 15 секунд, нагрузка снижается, но пользователи начинают спрашивать, почему изменения приходят поздно. Эта развилка сначала ложится на базу данных, а потом — на людей, которым приходится объяснять задержки, устаревший вид и сообщения в духе «Я думал, что мое изменение сохранилось».

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

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

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

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

Стоимость эксплуатации — это не только облачный счет. Это запас прочности базы, шум в дежурствах, время на отладку и то количество жалоб пользователей, которое команда может выдержать до падения доверия.

Как выбрать шаг за шагом

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

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

Практичный способ выбора очень прост. Возьмите один реальный сценарий работы с документом и соберите минимальный тест, который ему соответствует. Смоделируйте максимальное число редакторов, которое вы ожидаете на один документ. Проверьте слабый Wi‑Fi, переподключение с мобильного, сон вкладки и повторные разрывы связи. Измеряйте чтения, записи, трафик и всплески переподключений. После этого обещайте только то поведение, которое действительно показал ваш тест.

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

Следите за затратами заранее, а не после запуска. Опрос поначалу часто кажется дешевым, потому что код знакомый. Потом растет использование, клиенты переподключаются волнами, и ваша база данных начинает выполнять лишнюю работу вместо обслуживания реальных изменений. У Yjs больше настроек и другой способ мышления, но он может сократить потери, когда люди много редактируют и часто переподключаются.

Хорошее правило простое: подбирайте архитектуру под тот паттерн редактирования, который вы можете доказать. Если ваша команда продает совместную работу в стиле Google Docs, тестируйте так, будто это обещание уже публичное. Именно такие решения Fractional CTO должен превращать в небольшой измеримый эксперимент до того, как команда построит месяцы продукта на неверной основе.

Простой пример команды

Представьте команду из пяти человек: продакт-менеджер, дизайнер, два инженера и редактор. Они обновляют спецификации каждый день. Большинство сессий редактирования длится 10–20 минут, обычно между встречами, после разговора с клиентом или во время исправления бага.

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

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

Обычно команда сначала не винит систему. Люди думают, что кто-то случайно удалил текст. Именно в этот момент доверие начинает проседать.

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

Yjs требует больше подготовки. Нужны общая модель документа, транспорт синхронизации и способ хранить обновления. Но в итоге именно эта команда обычно получает заметно лучший результат, если люди работают вместе каждый день. PM, инженер и дизайнер могут менять соседний текст в одной и той же сессии, а редактор продолжает работать, когда сигнал пропадает. Когда связь возвращается, Yjs объединяет правки, а не заставляет кого-то заново собирать абзац.

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

Ошибки, которые создают лишнюю работу

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

Одна ошибка повторяется снова и снова: выпускать правило «последняя запись побеждает» и не говорить об этом пользователям. Люди видят «совместное редактирование» и ожидают, что система будет сливать изменения или хотя бы предупреждать, прежде чем что-то удалит. Если самая свежая сохраненная версия тихо перезаписывает чужую работу, пользователи будут винить редактор, и будут правы.

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

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

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

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

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

Короткая проверка перед тем как решиться

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

Если два человека одновременно печатают в одном предложении, вы ждете, что обе правки сохранятся? Если да, опрос будет ощущаться грубым, пока вы быстро не добавите собственную логику слияния. Кто-нибудь будет продолжать редактировать без связи дольше минуты? Если да, Yjs обычно подходит лучше, потому что может поставить локальные изменения в очередь и потом синхронизировать их. Сколько открытых вкладок будут бездействовать, но все равно опрашивать базу каждые несколько секунд? Это число превращается в нагрузку на чтение, шумные логи и ежемесячный счет.

Еще нужен понятный ответственный за правила слияния в форматированном тексте, комментариях и позициях курсора. Ваша база данных не ответит на эти вопросы за вас. Кто-то в команде должен решить, что именно происходит. И когда пользователь пишет: «Мой текст исчез», службе поддержки нужен ясный ответ. Если ответ расплывчатый, продукт еще не готов к совместному редактированию.

Вопрос о более богатом контенте важнее, чем многие думают. Обычный текст — это одно. Комментарии, упоминания, выделения, вставки с форматированием и удаленные блоки создают куда более сложные случаи. Если вы полагаетесь на опрос, часто приходится вручную перестраивать части системы конфликтов.

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

Еще один тест помогает: попросите поддержку, продукт и инженеров дать определение «потери данных» одним предложением. Если каждая команда отвечает по-своему, остановитесь и сначала договоритесь об этом. Выбор архитектуры становится проще, когда все согласны, как выглядит сбой на простом языке.

Что делать дальше

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

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

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

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

Часто достаточно короткого пилота на 10–20 пользователей. Дайте им одну понятную задачу, пусть они пользуются системой неделю, и прочитайте каждую жалобу. Если люди медлят, теряют текст или спрашивают, кто что перезаписал, архитектуре еще нужна доработка.

Если вашей команде нужна вторая точка зрения перед решением, Oleg Sotnikov на oleg.is может проверить модель синхронизации, стоимость инфраструктуры и риск запуска. Как Fractional CTO и советник стартапов, он работает с командами над такими решениями до того, как они превращаются в месяцы переделок.

Маленькие тесты экономят деньги. Реальное использование показывает правду гораздо быстрее, чем широкие обещания.