Lovable створила сервіс реального часу для централізації керування доступом до даних

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 та реальними токенами ідентифікації, створеними емулятором, що дало змогу агентам тестувати зміни на всьому технологічному стеку.

Результати в продуктивному середовищі та потенційна підтримка застосунків

За період із 5 вересня до 5 жовтня 2026 року Lovable зафіксувала 2,61 млрд кадрів даних і патчів, не враховуючи кадри керування під час відновлення з’єднання. За оцінкою компанії, повні знімки для кожного обчисленого результату створили б 40 ТБ корисного навантаження застосунку. Дедуплікація, дельти та повторне використання даних під час відновлення з’єднання скоротили фактичний обсяг переданих даних до 1,11 ТБ — приблизно на 97% менше від базового показника. Ці дані не враховують накладні витрати протоколу й транспортного рівня.

Lovable виміряла інтервал між записом у вихідну базу даних і готовністю вихідного кадру до надсилання: 66 мілісекунд на p50 і 249 мілісекунд на p99. Ці вимірювання не враховують запис у сокет, мережевий час і обробку на клієнті, тому не відображають повного часу оновлення, який відчуває користувач.

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