クライアント間の新しいメッセージ通知と未読メッセージ数
このUXの質問は、1つの画面内だけでなく、複数のデバイスやモダリティでのユーザーエクスペリエンスを扱うという点で珍しいものです。
ラップトップ、タブレット、モバイルなどで実行されているさまざまなクライアントからアクセスできるチャットアプリがあるとします。メッセージが着信し、チャットルームのすべての参加者に送信されます。どのクライアントも、サーバーに対して「オンライン」または「オフライン」になる可能性があります。チャットルームはクライアントに表示されることもあれば、非表示のタブに表示されることもあります（表示されません）。
- ユーザーがチャットの新しいメッセージのオフライン通知を受け取るように登録しているとします。いつ発送しますか？
1つのケースは簡単です。クライアントがオンラインでない場合です。しかし、1人のクライアントがオンラインで、チャットルームが前面にある場合はどうでしょうか。したがって、メッセージは「見られた」。しかし、ユーザーがデスクトップのチャットルームを開いたままにし、電話を持って立ち去ったらどうなるでしょうか。翌日以降は、オフライン通知は届きません。これを「完全に」解決するには、Bluetoothペアリングを使用するか、ユーザーの電話の動きを追跡する必要があるようです。または、マウスの動きなどがない場合に、本当に1分程度のタイムアウトを設定することもできます。
- さらに深刻な問題は、未読メッセージ数について表示する必要があることです。各クライアントで、トリプルを保存できます（チャットYのユーザーXがメッセージZまで見た）。これは安価で、クライアント側に保存するのが簡単です。ただし、各クライアントには、未読メッセージの数そのクライアントに対してが表示されます。この種のポイントは、ポイント＃1と交差します。つまり、他のクライアントがすでにメッセージを表示している場合はどうなりますか？ソフトウェアはそれが表示されていると想定する必要があります私にあそこにあるため、他のすべてのクライアントでメッセージを既読としてマークしますか？
技術的なものが続きます
＃2の場合、トレードオフはこれです。クライアント間での同期の方が望ましいと確信していますが、技術的にはveryのコストがかかります。サーバーでトリプル（X、Y、Z）を更新するには、everyevery chatroom every clientのメッセージに対する追加の確認が必要です。これにより、トラフィックが2倍になるだけでなく、サーバーがデータベース内の（X、Y）行をロックして、Zの数を増やすことができます。このロックは、ユーザーが何百万人もいるわけではないので、それほど悪くありません同時に開くクライアントの数は、おそらく最大3つまたは4つだけです。しかし、それでもクライアント間で（X、Y、Z）のトリプルを同期するための膨大な数の確認とロックです。
＃2の私の質問は、同期せずにクライアントごとに未読メッセージを表示するのに十分ですか、または未読メッセージの（X、Y、Z）トリプルの同期が非常に優れているため、このすべての余分なトラフィックの料金を支払う必要がありますか？
私が正しく理解していれば、ユーザーの前でチャットを開いていても、ユーザーがメッセージを読んでいるかどうかを追跡することはできません。現実の世界（単純な例）のように、誰かが話している人の前にいても、必ずしも聞いているとは限りません。
これが製品を破壊するような大きな問題である場合、私が考えることができる唯一のアイデアはクライアントがメッセージを明示的に受信または停止するです：
- クライアントはボタンをクリックして新しいメッセージを受信する必要があります
- クライアントはボタンをクリックしてチャットをオフにする必要があります
これらはチャット（特に最初のチャット）をフォローするのに最も便利な方法ではありませんが、メッセージの受信または受信の停止を明示的に決定したことを確認できます（メッセージを読んだり追跡したりできない場合は、afaik）。
さて、悪魔の詳細です。ただし、アーキテクチャの観点から、MQTTを見てみます。これは、さまざまなQoS設定でパブリッシュ/サブスクライブをサポートしています。ユーザーが複数のデバイスを介してログインした場合、ユーザーは同じIDを使用すると想定しています。おそらく、ユーザー+デバイスレベルのCookieを使用して、さまざまな接続を整理し、複数のデバイス間で同期のレベルを提供できます。
MQTTを使用すると便利なもう1つの理由は、WebSocketをサポートしているため、クライアントが低レベルのコードをあまり必要としないためです。