LiveStore - リアクティブなSQLiteと組み込み同期エンジンを使用する状態管理ソリューション

 (livestore.dev)
27 ポイント 投稿者 xguru 2025-06-04 | 2件のコメント | WhatsAppで共有
  • 同期ロジック開発の負担なく、高性能なアプリケーション開発を可能にするよう設計された状態管理データレイヤー
  • リアクティブな SQLite と組み込み同期エンジンを使用するのが特徴
  • ローカルファースト(Local-first) で、オフラインでも高い性能を提供し、ネットワーク復旧時には自動同期をサポート
    • すべての状態管理演算がローカルの SQLite データベース上で高速に実行される
  • リアクティブデータストリーム: データ変更時に即座にUIと接続されたリスナーへイベントが発生し、状態変化をリアルタイムに反映可能
  • さまざまな環境（Web、モバイル、デスクトップなど）に適用できる
  • 既存の 状態管理ツール と比べて、ネイティブ性能とデータ整合性で優れた結果を提供

関連記事

2件のコメント

 
laeyoung 2025-06-04

ホームページのメインにあるDemo、本当によくできていますね。少しクリックしているうちに、使ってみたくなるほどです。
 
GN⁺ 2025-06-04
Hacker Newsのコメント

  • こんにちは、LiveStoreの共同創業者です（以前はPrismaを作っていました）。
    この4年間、Overtoneというネイティブ級の高性能音楽クライアントを作る中で、自分たちで使うためにLiveStoreを開発することになりました。
    LiveStoreはSQLiteにリアクティブなシグナルレイヤーを追加し、イベントソーシングベースの同期（Gitに近い）を組み合わせています

    • いろいろなローカルファースト環境を評価してきましたが、LiveStoreほどきれいに解決しているソリューションはほとんどありませんでした
      同程度に成熟したツールとしてtinyBaseもありますが、あちらは構造が異なります（CRDTs vs イベントソーシング）
      気になっているのは、なぜデータ容量を1GBに制限しているのか、もっと大きなデータをSQLiteに保存してディスクに残せるオプションを設けられないのかという点です
      単に設定だけで永続化モードを切り替えられないでしょうか？
      マルチテナンシーも興味深いシナリオになりそうです。JIRAのように各組織が別々のネームスペースを必要とする場合、各ユーザーにも全チケットではなく自分のチーム・部署分だけを配信できると良さそうです
      基本的にはローカルデータベースが全データのサブセットになる構造です。Bun/Nodeでそのまま動かせる同期サーバー（Cloudflare不要）が同梱されていたら本当にすばらしいと思います
      今検討中のプロジェクト案にもかなり合いそうです。特にマルチテナンシーが必須だからです

    • 先月、趣味プロジェクトでLiveStoreを使ってみようと思って確認したのですが、ベータプレビューだったのでアクセスが難しかったです
      近いうちにもっと深く見られるようになることを期待しています。ローカルファーストに関する議論を積極的にリードしている姿勢が印象的です
      オフライン同期可能なWebアプリを作ったことがある人なら、同期エンジンの有用性をすぐ理解できると思います

    • 今日のLocal-First Confでの発表、とても良かったです
      イベントソーシングをSQLiteで実装する構造についての説明が明快で説得力がありました
      SQLite、特にOPFS Wasm SQLiteをWebで積極的に広めてくれてありがとうございます
      PowerSyncもSQLiteを強く支持する立場なので、LiveStoreのような成功例はうれしく感じます

    • LiveStoreがイベントソーシングモデルをグローバルに拡張する際、通常はすべてのクライアントに対して中央同期バックエンドを置いて同期すると思いますが、これが必須要件なのか気になります
      あるいはフェデレーションノード（federated nodes）や完全なP2Pモードも可能でしょうか。分散SNSのユースケースへの適用も考えています

    • ReactやWASMと組み合わせて、LiveStoreが多くの音楽アプリで使われているJuceフレームワークの代替になれるのか気になります
      私はビートメイカーなのですが、JuceとC++の組み合わせはいつも難しくて怖いと感じていました。音楽アプリ開発に入ろうとする人にとって、LiveStoreが良い代替になり得るのか知りたいです

  • Local-first Confで発表を見ましたが、最近は本当にさまざまな同期エンジンが登場しています
    LiveStoreはイベントソーシングと同期エンジンを組み合わせる興味深い領域を深く掘り下げています
    すでにここまで堅牢なシステムになっていることに驚きました
    ここ数週間、新しいプロジェクトで実際に使ってみましたが、本当にスムーズに動作しています

  • ローンチおめでとうございます！ このシステムがここで説明されている**"1. Serialization"戦略に当てはまるのか気になります
    ProseMirror-collabで言及されているように、頻繁に更新する    低遅延クライアントが高遅延クライアントの更新を妨げてしまう問題**がLiveStoreでも起こるのか知りたいです

  • LiveStoreはwa-sqliteを使っているようです
    オフラインデータ永続化の戦略について詳しく聞きたいです。具体的にはOPFS（AccessHandlePoolVFSのような派生を含む）とIndexedDBのどちらを使っているのか、あるいは両方なのかが気になります
    また、OPFSのブラウザ間での不安定さや、Safari IndexedDBの7日保持ポリシーにはどう対応しているのでしょうか
    SQLiteが公式WASMビルドを提供しているのに、wa-sqliteを使っている理由も知りたいです

  • 最近、LocalFirst.fmのポッドキャストでLiveStoreを簡単に紹介しました（https://www.localfirst.fm/24 のリンク参照）

    • エピソードの共有ありがとうございます。近いうちにLiveStore単独のエピソードも準備する予定です

  • とても期待できそうなプロジェクトに見えますが、過度な期待（ハイプトラップ）に陥らないか少し慎重にもなっています
    同じように    ローカルファーストアプリ    をカスタムで作りながら、マルチデバイス対応を試しています
    E2E暗号化もオプションとして追加できるのか気になります。ドキュメントを見る限り、イベントペイロード単位で暗号化を加えれば、サーバーログ圧縮が難しくなる点を除けばほぼ可能そうです

    • 「ハイプトラップ」という意見には同意します
      私はOvertoneを作る中で生まれた必要性をもとに、LiveStoreを自分で作っています
      LiveStore/Overtoneはいずれも長期的な持続性を目標に作っています。E2E暗号化はすでに実現可能な構造です
      私自身ではまだ試していませんが、問題があればいつでも手伝えます
      クライアント側だけでログ圧縮（log compaction）を試みるのも一つの方法だと思います。このユースケースも必ず念頭に置いて設計を進めるつもりです

  • クロスプラットフォーム対応という主張には懐疑的です。最初に見えたのがAndroid Web非対応だったので

    • もっともな指摘です。Android/Chromeチームとは技術的な問題について継続的にやり取りしています。3年ほど前から原因は把握しているのですが、いまだに解決されていないため、LiveStore側で別の回避策を用意する必要がありそうです
      進捗は公式GitHub（https://github.com/livestorejs/livestore/…
      Web APIの対応状況はプラットフォームごとに違うので、このような野心的なシステムを作るには非常に多くの労力と時間が必要だという点をご理解いただければと思います

  • デモ動画で気になった点が1つあります！ 1分7秒あたりで音声が左に寄る現象がありました。細かいことですが、参考になればと思ってお知らせします

  • 開発者ツールも一緒に提供しているのが印象的で、かなり長い間自社プロジェクトでテストしてきたように見えます
    気になるのは、長時間動作するアプリ/ページのcompactionを長期的にどう処理するつもりなのか、またイベントソーシングは魅力的な概念ですが、アプリケーションレイヤーが進化するにつれてコード管理（旧バージョンのクライアント、スキーママイグレーションなど）が難しくなり得ることです
    Overtoneはいろいろなソースに対応しているようですが、オフライン再生も提供する予定でしょうか。特にSpotifyのUIが使いづらいので代替が切実に欲しいです

    • 良い質問です！ compactionについては多く問い合わせをもらっており、近いうちに解決策を公開する予定です
      中核となるアイデアは、各イベントにより多くの意味情報を与えて、イベント間の重なりを定義できるようにすることです
      たとえばtodoアプリでは、同じタスクIDに対する"todoCompleted"イベントが、そのタスクの"todoCompleted"/"todoUncompleted"イベント群を圧縮できる、という考え方です
      進捗はGitHub（https://github.com/livestorejs/livestore/…
      イベントソーシングでは確かに規律と設計が重要です。データに「ただ飯」はないので、トレードオフこそが核心です
      Overtoneなど私の主な用途では、イベントソーシングのトレードオフのほうがより良いと感じています
      旧バージョン対応などにはシンプルな方法がいろいろあり、結局は各アプリケーションの特性とトレードオフ次第です
      Overtoneに興味を持ってくれてありがとう。私もSpotifyへの不満からこのプロジェクトを始めました。オフライン再生については音源の提供元によって変わります
      たとえばDropboxなど自分で所有しているアルバムなら対応できますが、Spotifyのようなストリーミングサービスはポリシー次第になるでしょう

  • このアーキテクチャは気に入りました。特にイベントソーシングが良いです
    ただしイベントソーシングには注意も必要です。求めるビュー次第ではマテリアライズ（view materialization）が遅くなることがあり、データが大きくなるほどさらに遅くなります
    その解決策としては、トリガーなどを使ってトランザクション内でマテリアライズ更新を自分で管理する必要があります
    レプリケーションや同期の際にも考慮が必要で、競合解決についてもCRDTの概念は必ず理解しておくべきです
    Postgresの言語機能を持つSQLite3に似たデータベースがあれば、local-firstとremote-firstを設定だけ切り替えて使えて本当に良さそうです

    • 最後のコメントに関連して、pglite.dev(https://pglite.dev)を参照するとよいでしょう
      マテリアライズのコストという本題については、compactionは今後さらに改善していく予定で、LiveStore全体がパフォーマンス最適化を目標に細かく設計されたフレームワークです