From 08bb42b588e87f5d75228266ad27d0e4e5cd2589 Mon Sep 17 00:00:00 2001 From: Yoji Shidara Date: Mon, 3 Feb 2025 10:43:43 +0900 Subject: [PATCH] Write report --- .../_posts/2025-01-27-0065-TokyoRubyKaigi12Report.md | 12 ++++++++++-- 1 file changed, 10 insertions(+), 2 deletions(-) diff --git a/articles/0065/_posts/2025-01-27-0065-TokyoRubyKaigi12Report.md b/articles/0065/_posts/2025-01-27-0065-TokyoRubyKaigi12Report.md index 6c5061cf..45ec0055 100644 --- a/articles/0065/_posts/2025-01-27-0065-TokyoRubyKaigi12Report.md +++ b/articles/0065/_posts/2025-01-27-0065-TokyoRubyKaigi12Report.md @@ -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とRailの組み合わせにはあまり試されていない可能性がまだまだありそう」「僕らはRubyのポテンシャルをもっと引き出せるはず」とのメッセージで締めくくられました。 + +私はリアルタイムWebアプリケーションが大好物で、複数のスタックで実装した経験もあって、とても興味深く聞きました。ただ、複数のモデルが複雑に関連するようなものはあまり経験がありませんでした。発表では親が変わるケースや複数あるケースにも言及されており、これは大変そう…という気持ちになりました。現代Web技術とRuby / Railsの新たな可能性、気になります。 + +(darashi) ### ryopeko『functionalなアプローチで動的要素を排除する』