Lovable перенесла обновления на свой сервер и сократила объём данных примерно на 97%

Добавили в документ проекта внутреннее поле — и браузер пользователя уже может его получить. Такой риск возникал у Lovable, пока фронтенд напрямую подписывался на документы Firestore. Разработчику приходилось думать о публичном API даже при обычном изменении структуры базы. А права доступа нужно было согласованно поддерживать в двух местах: правилах Firestore и серверном коде на Go.

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

Что происходит после отзыва доступа

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

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

Это особенно пригодилось для корпоративных групп: нужные сведения находились в разных базах, Firestore и Spanner. Правила безопасности Firestore не могли читать Spanner. Собственный серверный слой позволил объединять данные из обеих баз в одном ответе и применять общую систему разрешений API.

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

Как обновления доходят до браузера

На вкладку приходится одно WebSocket-соединение, внутри которого работают несколько подписок. Изменения Firestore и Spanner через механизм захвата изменений поступают в мост, затем в NATS. Сервис на Go получает событие и пересчитывает затронутые подписки.

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

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

За указанные в статье 30 дней сервис доставил 2,61 млрд кадров с данными и изменениями. Команда оценила гипотетическую передачу каждого вычисленного результата целиком в 40 ТБ. Фактически переданный объём составил 1,11 ТБ благодаря подавлению повторов, отправке разницы и повторному использованию состояния при переподключении. Отсюда оценка сокращения примерно на 97%. Это сравнение с расчётной базой полных ответов, а не измеренное снижение расходов на Firestore.

Что взять в свой продукт

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

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

Строить такую систему с нуля потребуется далеко не каждой команде. Здесь выбор определили существующие базы, Go-бэкенд и требования к изменению прав во время сессии. Но проверить собственный продукт можно уже сейчас: какие поля уходят в браузер, что происходит после отзыва доступа и выдерживает ли сервер одновременное возвращение множества вкладок.