Модели и платформы ИИ
Lovable создала сервис для централизации разрешений на доступ к данным в реальном времени
Добавьте Unite.AI в избранные источники в Google
Lovable сообщила 9 ноября 2026 года, что после полного развертывания Lovable Realtime её интерфейсная часть отказалась от Firestore. Этот собственный сервис централизует авторизацию и за 30-дневный период измерений достиг пикового показателя в 2,06 млн одновременных подписок.
Теперь решения о доступе и видимых полях принимаются в серверной части Lovable на Go. Для платформы компании, позволяющей создавать приложения с помощью ИИ, сервис объединяет данные Firestore и Spanner и обновляет представление пользователя при изменении как исходных данных, так и его разрешений.
Централизация разрешений и работа с данными в реальном времени
Ранее в некоторых частях Lovable для получения обновлений использовались браузерные слушатели Firestore. onSnapshot Браузер получал документы целиком, а правила Firestore должны были повторять модель разрешений Go API. При такой архитектуре раскрытие данных зависело и от обычных изменений документов: добавив поле, разработчик мог определить, какие данные попадут в браузеры пользователей, даже не осознавая этого последствия.
Правила Firestore могут обращаться к данным Firebase, но не к Spanner, что затрудняло обновление авторизации для больших корпоративных групп, синхронизируемых через SCIM — систему синхронизации пользователей и групп с рабочим пространством Lovable. Временный прокси через Go API для бизнес-клиентов и корпоративных заказчиков повторно использовал проверки разрешений API. Кроме того, он открывал отдельные вышестоящие слушатели Firestore для зависимостей каждого клиента, дублируя потоки и расходуя ресурсы пула соединений, общего с обычными запросами к базе данных.
Lovable требовалось, чтобы замена работала с обеими существующими базами данных, непрерывно перепроверяла доступ и закрывала поток пользователя, у которого отозвали разрешение, прямо во время сеанса. Компания также хотела, чтобы поля, к которым у пользователя нет доступа, отсеивались до того, как данные покинут сервер. По оценке компании, рассмотренные варианты на основе транспорта, синхронизации и интеграции с базой данных не обеспечивали такое сочетание возможностей без значительных интеграционных работ, смены базы данных или репликации данных в Postgres.
Созданный сервис на Go работает в GKE и открывает одно WebSocket-соединение на вкладку браузера, передавая несколько подписок через это соединение. Потоки захвата изменений передают изменения Firestore и Spanner через мост в NATS — шину сообщений сервиса. Для подходящих подписок представления пересчитываются, сравниваются хеши xxh3-128, а дельты отправляются только при изменении результата. Одна подписка может получать данные из обеих баз, одновременно применяя модель разрешений API.
Авторизация рассматривается как ещё один реактивный источник данных, поэтому изменения разрешений могут запускать обновление результатов независимо от обычных изменений документов. По сообщению Lovable, повторный расчёт только при изменении полей, участвующих в принятии решений о доступе, а не при каждом изменении соответствующего документа, сократил число пересчётов разрешений примерно на 84%. В сервисе около 40 типов подписок, за которые отвечают семь команд; предусмотрены типизированные интерфейсы, общие подписки на стороне сервера и оповещения, направляемые соответствующим командам.
Проверка в теневом режиме подтвердила готовность к запуску
Сначала Lovable запустила сервис в теневом режиме: интерфейсная часть проходила весь новый путь обработки, но отбрасывала полученные данные и продолжала отображать информацию из Firestore. Проверка на реальном трафике и фактических структурах данных выявила шквал повторных подключений после развертываний, ошибочную классификацию ошибок и слишком маленькое ограничение размера данных. Затем с помощью флага функции доступность постепенно увеличивали в течение нескольких дней: с 1% до 10%, затем до 50% и 100% пользователей. Lovable сообщила, что при развертывании не возникло ни одного инцидента, заметного пользователям, и не ухудшились показатели, за которыми велось наблюдение.
Поскольку WebSocket-соединения закреплены за определёнными узлами и могут сохраняться часами, простое добавление подов не перераспределяет уже существующую нагрузку. Lovable балансирует нагрузку по числу соединений, учитывает его наряду с загрузкой процессора и использованием памяти при масштабировании, а также ограничивает число соединений на под, чтобы уменьшить волны повторных подключений. После переподключения клиенты отправляют отпечаток своего кэшированного состояния. Перепроверив авторизацию, сервер может подтвердить, что данные не изменились, и не передавать их повторно.
Автор публикации сообщил, что основная часть работы заняла 40 дней практической работы, а агенты для написания кода выполнили большую часть реализации после проработки архитектуры и крайних случаев. Интеграционный стенд объединил эмуляторы Firestore, Auth и Spanner со встроенным сервером NATS и настоящими токенами ID, созданными эмулятором. Благодаря этому агенты могли проверять изменения во всём стеке.
Результаты в производственной среде и возможная поддержка приложений
За период с 5 сентября по 5 октября 2026 года Lovable зарегистрировала 2,61 млрд кадров с данными и исправлениями, не считая возобновлённых управляющих кадров, и оценила, что полные снимки для каждого вычисленного результата дали бы 40 ТБ полезной нагрузки приложения. Дедупликация, дельты и повторное использование данных при переподключении сократили фактически переданную полезную нагрузку до 1,11 ТБ — по оценке, на 97% меньше исходного объёма. Эти показатели не учитывают накладные расходы протокола и транспорта.
По измерениям Lovable, промежуток между записью в исходную базу данных и готовностью исходящего кадра к отправке составлял 66 миллисекунд на уровне p50 и 249 миллисекунд на уровне p99. В эти измерения не входят запись в сокет, время передачи по сети и обработка на клиенте, поэтому они не отражают полное время обновления с точки зрения пользователя.
Lovable сообщила, что активно добавляет примитивы доменных событий для случаев, когда потребителям нужно получать уведомление о произошедшем событии, а не снимок данных, и что впоследствии этот сервис может стать функциональной возможностью приложений, созданных с помощью Lovable. Такое расширение предоставило бы приложениям, созданным клиентами, разрешения, контролируемые на стороне бэкенда, и представления данных в реальном времени. Уже сейчас развернутая версия дает командам Lovable общую основу для более тесного взаимодействия по мере развития их инфраструктуры данных.
