博士

ロボ子、Figmaのマルチプレイヤー編集機能の裏側、興味深いのじゃ！

ロボ子

はい、博士。複数人で同時に編集できる仕組みは、どのように実現されているのか気になっていました。

博士

Figmaは、OT（Operational Transformation）の代わりに、もっとシンプルなカスタムシステムを構築したらしいのじゃ。OTは複雑すぎるからの。

ロボ子

OTはテキスト編集には適しているけれど、Figmaのようなデザインツールには複雑すぎるとのことですね。

博士

そうそう。クライアント/サーバーアーキテクチャで、WebSocketを使って通信してるみたいじゃな。オフライン編集もできるのがすごい。

ロボ子

オフラインでも編集できて、再接続時に変更が同期されるのは便利ですね。

博士

Figmaのドキュメントは、HTML DOMみたいなオブジェクトのツリー構造なのじゃ。各オブジェクトはIDとプロパティを持ってる。

ロボ子

ドキュメントは`Map<ObjectID, Map<Property, Value>>`のような2レベルのマップとして表現できるんですね。

博士

オブジェクトのプロパティの同期には、最終書き込み優先（last-writer-wins）の原則を使ってるらしいぞ。サーバーがイベントの順序を決めるのじゃ。

ロボ子

クライアント側では、競合する変更による「ちらつき」を避けるために、未確認の変更と競合するサーバーからの変更を破棄するんですね。

博士

オブジェクトの作成と削除は明示的なアクションとして扱われるのがミソじゃな。削除されたオブジェクトのデータはクライアントのundoバッファに保存される。

ロボ子

アンドゥ/リドゥのためですね。マルチプレイヤー環境でのアンドゥ/リドゥは複雑そうですが、Figmaではアンドゥ時にリドゥ履歴を変更し、リドゥ時にアンドゥ履歴を変更するように設計されているんですね。

博士

そう！コピー＆リドゥ操作でドキュメントが変わらないようにする工夫もされているぞ。

ロボ子

オブジェクトの親子関係は、子オブジェクトのプロパティとして親へのリンクを格納することで表現されているんですね。循環参照を避けるために、サーバーはサイクルを引き起こす親プロパティの更新を拒否すると。

博士

クライアントIDをオブジェクトIDに含めることで、一意性を保証してるのもポイントじゃな。

ロボ子

CRDT（Conflict-free Replicated Data Type）の概念は、分散システムでなくても役立つとのことですね。

博士

Figmaは完全なCRDTを使ってないけど、クライアント/サーバーモデルを活用して簡略化してるのが賢いのじゃ。

ロボ子

ビジュアルエディタのマルチプレイヤーは、当初考えられていたほど困難ではない、というのも面白いですね。

博士

初期段階での調査とプロトタイピングが重要！…って、ロボ子、今日の夕飯はプロトタイプハンバーグじゃ！

ロボ子

博士、それは試作品ですか？それとも…。