リアルタイム同期+共有ToDoの最良のアプローチは？
とりわけ共有ToDoリストを持つアプリを実装しています。リアルタイムで同期させたい。これは、「通常の」シングルユーザーアイテム（たとえば、ユーザーが2つのデバイスでアプリを開いている、一方のデバイスで更新を実行すると、もう一方のデバイスですぐに表示される）、およびすべての参加者が更新を受信する必要がある共有リストに対して機能する必要があります。リアルタイムで。
これを達成するためにどの種類の構造が最適かは完全にはわかりません。ユーザーuuid->ソケットリストの辞書を保存することを考えていました。ユーザーがログインするか、ログイン中にアプリを開くと、接続が開始されます。ここで、辞書にエントリまたは更新を追加します。彼らがログアウトするかアプリを閉じると、接続が閉じられ、それに応じてマップが更新されます。アプリがサーバーで更新を行うたびに、影響を受けるユーザーを検索し、辞書でこれらのユーザーが開いている可能性のあるWebSocketを検索して、更新を送信します。
私が持っていたもう1つのアイデアは、ユーザーではなく、接続をアイテムに関連付けることでした。 ToDoリスト。繰り返しになりますが、辞書がありますが、今回のキーはtodoリストuuidであり、このリストの接続（「オブザーバー」）の配列があり、リストが変更された場所でブロードキャストします。このアプローチは「シングルユーザー同期」には適していませんが、ここでは要素が必ずしも独自のIDを持っている必要はなく、ユーザーに関連付けられているため、辞書ユーザー->接続を使用した最初のアプローチに戻ります。
しかし、詳細に入る前に、これが正しい思考の流れであるかどうかを確認したいと思います。これは通常どのようにモデル化されますか？これは理論的な質問ですが、何かに関連する場合は、Play Framework 2.4/Scalaを使用しています。
わかりました。WebSocketを使用してパブリッシュ/サブスクライブの実装を終了しました。さまざまなカテゴリ（ToDoリストやシングルユーザーイベントなど）のセット辞書を実装しました。ここで、キーはサブジェクト（私の場合はリストまたはユーザーのuuid）であり、値はサブスクライバーのリストです。実装の詳細に関しては、PlayアクターとAkkaアクターを使用してこれを行いました。
これは、古典的なパブリッシュ/サブスクライブシナリオのように聞こえます。バックエンド（JMSやAMQPなど）でpub/subデザインを使用し、ブラウザーのフロントエンドにAMQP/JMS-> JavaScriptフレームワークを使用することをお勧めします。次に例を示します。 http://www.websocket.org/demos/todomvc/index.html 非常に簡単です。
サブスクリプションベースのクラウドサービスを使用することがユースケースのオプションである場合は、Realtime Cloud Storage（私が働いている会社）を確認する必要があります。
これは、スケーラブルなリアルタイムデータ同期機能を備えたデータバックエンド（AWS DynamoDBを利用）です。詳細 http://framework.realtime.co/storage/
また、JavaScriptで記述されたオンラインのtodoデモがあります http://storage-public.realtime.co/samples/todo-lbl/index.html#/