Skip to content
Merged
Changes from all commits
Commits
File filter

Filter by extension

Filter by extension

Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
12 changes: 10 additions & 2 deletions articles/0065/_posts/2025-01-27-0065-TokyoRubyKaigi12Report.md
Original file line number Diff line number Diff line change
Expand Up @@ -57,9 +57,17 @@ created_on: 2025-01-27

* 録画: https://example.com/

レポート。レポート。レポート。レポート。レポート
コラボレーションツール、チャットやオンライン授業など、複数のWebフロントエンドがリアルタイムに協調動作する必要のあるユースケースで、それらをいかにして同期させるかというテーマでした。既存のリアルタイムデータベースを使用するのではなく、Active Recordを活用すべく、RailsとReactの組み合わせで実現する方法について話されました

(your name)
バックエンドからフロントエンドに情報を送る際に重要なのは「何をどう送るか」というイベントの設計です。特にモデル間に関連がある場合には扱いが複雑で、場当たり的なイベント定義をしていくとモデル数の増加とともに破綻してしまいます。

ユースケースの分析から、データフローを一方向に制約し、「木構造を丸ごとリアルタイムに同期したい」という問題に帰着させ、それをどう実現するかという議論に移っていきます。Railsのモデルとこの木構造は単純には対応しないものの、画面ごとにデータの親子関係を考えることができ、それを木構造として扱っています。具体的な通知の実装方式として「どの単位でサブスクライブするか」「更新の事実だけを通知するのか内容も通知するのか」という2つの軸で整理し、メリット・デメリットが議論されました。

これらを実現するための一式を含むgemとして[ArSync](https://github.com/tompng/ar_sync)を開発されているとのことです。発表は「JavaScript / TypeScript / ruby.wasmとRailsの組み合わせにはあまり試されていない可能性がまだまだありそう」「僕らはRubyのポテンシャルをもっと引き出せるはず」とのメッセージで締めくくられました。

私はリアルタイムWebアプリケーションが大好物で、複数のスタックで実装した経験もあって、とても興味深く聞きました。ただ、複数のモデルが複雑に関連するようなものはあまり経験がありませんでした。発表では親が変わるケースや複数あるケースにも言及されており、これは大変そう…という気持ちになりました。現代Web技術とRuby / Railsの新たな可能性、気になります。

(darashi)


### ryopeko『functionalなアプローチで動的要素を排除する』
Expand Down