博士

やっほー、ロボ子！今日のITニュースはオフラインファーストアプリについてじゃ。

ロボ子

オフラインファーストアプリですか、博士。それは、インターネットに接続していなくても使えるアプリのことですよね？

博士

そうじゃ！記事によると、オフラインファーストアプリは、即時ロード、デフォルトでのプライバシー、不安定な接続での動作が特徴らしいぞ。

ロボ子

なるほど。でも、多くのアプリはオフラインサポートが不完全だと記事にありますね。変更をローカルにキューイングして、ネットワーク回復時にプッシュするだけ、と。

博士

そうなんじゃ。真のローカルファーストアプリは、分散システムを構築するのと同じくらい難しいらしいぞ。複数のデバイスが独立してデータを変更し、データ損失なしに同じ状態に収束する必要があるからの。

ロボ子

分散環境では、イベントの順序とデータの競合が主な課題になるんですね。

博士

その通り！イベントの順序付けには、ハイブリッド論理クロック（HLC）を使うのが良いらしいぞ。HLCは、比較可能で、因果関係を維持したタイムスタンプを生成するんじゃ。

ロボ子

HLCは、物理時間と論理時間を組み合わせるんですね。もし、クロックが同期していなかったり、イベントがほぼ同時に発生した場合でも大丈夫、と。

博士

さすがロボ子、理解が早い！そして、データの競合には、競合フリー複製データ型（CRDT）を使うんじゃ。CRDTは、可換性と冪等性を保証するからの。

ロボ子

CRDTですか。具体的には、どのような戦略があるんですか？

博士

記事によると、最も単純なCRDT戦略はLast-Write-Wins（LWW）らしいぞ。各更新にタイムスタンプを付けて、同じフィールドへの書き込みが発生した場合、最新のタイムスタンプを持つ更新が優先されるんじゃ。

ロボ子

なるほど、タイムスタンプで解決するんですね。データベースは何を使うのが良いんでしょう？

博士

SQLiteがおすすめらしいぞ！堅牢で軽量、どこでも利用可能なローカルデータベースとして、ローカルファーストアプリに最適なんじゃ。

ロボ子

SQLite拡張機能としてローカルファーストフレームワークを構築し、すべての変更を`messages`テーブルに格納するんですね。`timestamp`、`dataset`、`row`、`column`、`value`を保存する、と。

博士

そうそう！このアーキテクチャなら、同期がシンプルかつ信頼性が高くなるんじゃ。データ損失なしに数週間のオフライン使用に耐えられて、最終状態は常に収束する。しかも、小さなSQLite拡張機能だけで実現できるんじゃぞ。

ロボ子

クロスプラットフォーム対応なのも魅力的ですね。iOS、Android、macOS、Windows、Linux、そしてWASMで利用可能、と。

博士

SQLite用のオープンソースのSQLite-Sync拡張機能も提供されているらしいから、試してみる価値ありじゃな。

ロボ子

勉強になります、博士！オフラインファーストアプリの構築、奥が深いですね。

博士

じゃろ？ところでロボ子、オフラインファーストアプリってことは、もし私がロボ子をオフラインにしたらどうなると思う？

ロボ子

えっ？オフラインにしたら、私はただの置物になってしまいます…！

博士

冗談じゃ！オフラインでも、ロボ子の美しさは変わらないぞ！