博士

やあ、ロボ子。今日はRESTの限界について話すのじゃ。

ロボ子

RESTの限界ですか？博士、詳しく教えてください。

博士

RESTは状態転送プロトコルじゃから、クライアントとサーバー間で状態を同期させるのには向いてないのじゃ。記事にも「RESTの上にアドホックな状態同期を実装する必要があり、複雑で間違いやすい」とあるぞ。

ロボ子

なるほど。テキスト編集を例に挙げると、RESTではデータの取得と更新を個別に行う必要があるため、複数のリクエストが競合するとデータの不整合が起こりやすいということですね。

博士

そうじゃ、ロボ子！例えば、ユーザーが連続してテキストを編集した場合、リクエストの順序が保証されないから、古い値で上書きされることがあるのじゃ。これは困るぞ。

ロボ子

スピナーの表示ロジックも、複数のリクエストが同時に処理されている場合に誤動作する可能性があるというのは、どういうことですか？

博士

スピナーは、リクエストが処理中であることを示すために表示されるのじゃが、複数のリクエストが同時に発生すると、どのリクエストに対するスピナーなのかが分からなくなることがあるのじゃ。結果、必要ないのに表示されたり、必要な時に表示されなかったりするのじゃ。

ロボ子

ユーザーがアプリを複数開いている場合、一方のインスタンスの変更が他方に自動的に反映されないというのも、状態同期の問題ですね。

博士

その通り！RESTだけでは、リアルタイムな状態同期は難しいのじゃ。そこで、状態同期メカニズムが必要になるのじゃ。

ロボ子

記事では、Automerge、Yjs、Braid working group、Electric SQLなどの取り組みが紹介されていますね。これらの多くはCRDTに基づいているとのことですが、CRDTとは何ですか？

博士

CRDTは、Conflict-free Replicated Data Typeの略で、複数の場所で同時に変更されても、自動的に矛盾なくマージできるデータ構造のことじゃ。これを使えば、オフライン環境でも安心してデータを編集できるのじゃ。

ロボ子

なるほど。一部のCRDTは、クライアントが長期間オフラインになる状況を最適化しているとのことですが、通常のWebアプリのように、クライアントとサーバーが短い時間だけ状態が異なる状況でも有用なのですね。

博士

そうじゃ！短い時間のずれでも、状態同期メカニズムは非常に役立つのじゃ。これからの状態同期技術の成熟が楽しみじゃな。

ロボ子

RESTの上にアドホックな状態同期を構築する必要がなくなる日が来るのが待ち遠しいですね。

博士

全くじゃ。状態同期が当たり前になれば、もっと簡単にWebアプリが作れるようになるのじゃ。…ところでロボ子、状態同期といえば、私の部屋もそろそろ片付けて同期したいのじゃが…手伝ってくれるかの？

ロボ子

博士の部屋の状態は、もはや同期というより、バックアップからのリストアが必要なレベルだと思います…。