Lovable、データ権限を一元管理するリアルタイムサービスを構築

Lovableは2026年11月9日に報告し、Lovable Realtimeの全面展開に伴い、フロントエンドをFirestoreから移行したと明らかにした。認可を一元管理する独自サービスで、30日間の測定期間中に、同時サブスクリプション数のピークは206万件に達した。

この移行により、アクセス権と表示するフィールドの判断は、LovableのGoバックエンドに集約された。同社のAIアプリ構築プラットフォームにおいて、このサービスはFirestoreとSpannerのデータを組み合わせるとともに、基盤となる情報またはユーザーの権限が変更された際に、そのユーザーの表示内容を更新する手段となる。

権限とリアルタイムデータの一元管理

以前はLovableの一部で、ブラウザー上のFirestoreを onSnapshot 更新用のリスナーとして使用していた。ブラウザーにはドキュメント全体が送信される一方、FirestoreのルールはGo APIの権限モデルを反映する必要があった。また、この設計では、通常のドキュメント変更に伴ってデータの露出範囲も変わり得た。フィールドを追加した人が、その変更によってユーザーのブラウザーに何が届くかを左右しながら、その影響に気付かない可能性もあった。

FirestoreのルールはFirebaseのデータを照会できるが、Spannerは照会できない。そのため、ユーザーとグループをLovableのワークスペースに同期するSCIMを通じて同期された、大規模な企業グループに影響する認可更新が困難だった。ビジネスおよびエンタープライズ顧客向けに一時的に設けたGo API経由のプロキシでは、APIの権限チェックを再利用した。一方で、クライアントごとに依存関係を処理するFirestoreの上流リスナーを個別に開く必要があり、ストリームが重複し、通常のデータベースリクエストと共有する接続プールの容量を消費していた。

Lovableは、既存の両データベースに対応し、アクセス権を継続的に再評価するとともに、権限を取り消されたユーザーのストリームをセッションの途中で閉じられる代替手段を必要としていた。また、権限のないフィールドがサーバーから外部に送信される前に除外されることも求めていた。同社の評価では、検討したトランスポート、同期、データベース統合型の選択肢では、大規模な統合作業、データベースの変更、またはPostgresへのレプリケーションなしに、これらの要件を同時に満たすことはできなかった。

完成したGoサービスはGKE上で稼働し、ブラウザーのタブごとに1つのWebSocketを開き、その接続上で複数のサブスクリプションを多重化する。変更データキャプチャのフィードは、ブリッジを介してFirestoreとSpannerの変更を、サービスのメッセージバスであるNATSに送る。一致するサブスクリプションは表示内容を再計算し、xxh3-128ハッシュを比較して、出力に変更があった場合に限り差分を送信する。1つのサブスクリプションで両方のデータベースからデータを取得しながら、APIの権限フレームワークを適用できる。

認可は、別のリアクティブデータソースとして扱われる。これにより、通常のドキュメント編集とは独立して、権限の変更を新たな結果の取得につなげられる。Lovableによると、関連するドキュメントが更新されるたびに再計算するのではなく、アクセス判断に関わるフィールドが変更された場合に限って再計算することで、権限の再計算を約84％削減できた。このサービスには約40種類のサブスクリプションがあり、7つのチームがそれぞれ管理している。また、型付きインターフェース、共有サーバー側サブスクリプション、担当チームに振り分けられるアラートを備える。

シャドートラフィックで段階展開を検証

Lovableはまず、シャドーモードでサービスを稼働させた。フロントエンドは新しい経路全体を通じて処理を実行する一方、そのペイロードは破棄し、Firestoreからのデータで引き続き画面を表示した。実際のトラフィックとデータ形状を使ったことで、デプロイ後の再接続集中、誤分類されたエラー、実データに対して小さすぎるペイロード上限が明らかになった。その後、機能フラグを使い、数日かけて対象ユーザーの割合を1％から10％、50％、そして100％へと引き上げた。Lovableによると、この段階展開でユーザーに影響するインシデントは発生せず、監視対象の指標にも悪化はなかった。

WebSocket接続は特定のポッドに固定され、数時間続くこともあるため、ポッドを追加するだけでは既存の負荷は移動しない。Lovableは接続数を基準に負荷を分散し、CPUとメモリに加えて接続数も使ってスケーリングする。また、再接続の集中を抑えるため、ポッドごとの接続数に上限を設けている。再接続後、クライアントはキャッシュ済み状態のフィンガープリントを送信する。これによりサーバーは、認可を再確認したうえでデータに変更がないことを確認でき、データを再送せずに済む。

記事の著者によると、基盤部分の構築には実作業で40日を要し、アーキテクチャとエッジケースを十分に検討した後の実装の大半はコーディングエージェントが担った。統合テスト環境では、Firestore、Auth、Spannerのエミュレーターに、組み込み型のNATSサーバーと、実際のエミュレーターで発行したIDトークンを組み合わせた。これにより、エージェントはスタック全体を通じて変更をテストできた。

本番環境での成果とアプリへの対応の可能性

Lovableによると、2026年9月5日から10月5日までに、再開時の制御フレームを除いて、データフレームとパッチフレームが合計26億1,000万件送信された。また、計算された結果をすべて完全なスナップショットで送信した場合、アプリケーションのペイロードは40 TBに達していたと推定した。重複排除、差分送信、再接続時のデータ再利用によって、実際の送信量は1.11 TBとなり、この基準値から推定97％削減された。ペイロードの数値には、プロトコルおよびトランスポートのオーバーヘッドは含まれない。

Lovableが測定したのは、ソースデータベースへの書き込みから、送信するフレームの準備が完了するまでの時間で、p50では66ミリ秒、p99では249ミリ秒だった。この測定にはソケットへの書き込み、ネットワーク上の所要時間、クライアント側の処理は含まれないため、ユーザーが体感する更新時間全体を示すものではない。

Lovableは、データのスナップショットではなく、何かが起きたことを利用側に通知する必要があるケースに対応するため、ドメインイベントのプリミティブを積極的に追加していると述べました。また、将来的には、このサービスがLovableで構築されたアプリに組み込める機能となる可能性もあるとのことです。こうした拡張により、バックエンドで制御される権限とリアルタイムビューを、顧客が作成したアプリで利用できるようになります。現在の導入環境はすでに、データインフラの進化に合わせて、Lovableのチームがより充実したコラボレーションを実現するための共通基盤を提供しています。