42 s HoTechCourse愚かなチャットサーバを作成-01

MVC vs Webflux

そこで,MVCの様々な例を学習する際に,チャットサービスの基礎を理解しようとした.
この過程で、機能しないサンプルコードをどのように処理するか分からないJsなどの1週間の苦しい日の中で、私はずっとプログラミングが私の道かどうかを自責していました.
紆余曲折の末、Webflossを使ってテストすることにしました.

Webfluxは違います。

MVCはWebSocket Stompの購読と発行を利用してチャットサービスを実施する.
WebfluxはStompをサポートしていません.私はとても慌てて、どうすればいいか分かりません.
だから、webflowschatなどのグーグルを紫に染めましたが、答えは見つかりませんでした.
だからSpringdocsで答えを検索することにしました
そうやって見つけた手がかり
Websocketのみを使用するには、アプリケーションでメッセージプロトコルを実装する必要があります.
私は

STOMPがしたことを理解して、私は自分でしなければなりません.その瞬間MVCを使いたかったけどここにもきっと道があると思う

RSocketを使うとしたら?

RSocketは、TCPまたはWebSocketを介して双方向通信可能なチャネル機能を有する.これは私たちにチャットサービスを実施させるかもしれないと思います.

RSocket channel spring.ioブログ記事

では、今どのように実施すればいいのでしょうか。

キーワードが見つかりましたが、どのように表現すればいいか分かりません.Webfluxの例は思ったほど多くありません.
そしてdocsだけを見て「アハユリカ」と言うほどではありません
レゴを組み立てるように一つずつ載せていきます
私が望む例を探す旅...うまくやったことは一つもない.
まず重要なのは、Ruscoket接続は簡単ですが、html jsが全く分からないので、正しいかどうか確認できません.

2021-02-21(日)

上の手がかりを持って1週間以上探したが,むだだった。

何度も検索しましたが、私の検索力も未熟です!!
Rsocketを使うのは難しいと思います検索が終わらないことに気づきました.

だから私は韓国の春のキャンプを見学しています!

最終的にはRsocket実装の使用を放棄することにした.私は1週間かけてグーグルを紫に変えましたが、このビデオを見てサポートしていないときは、まだ私のレベルではありません.
何をしたいのか分からないが、何を検索するのか分からないので、盲目的に検索して、何ができないので心が乱れて、眠れない.だから最後にもう一度検索!
アリババBrokerを使えば...本格的な支援なら使いましょう!!再びWebMVCに戻ります!

メッセージのモデリング

20日から21日まで、メールの整理方法を考えていました.

ユーザは、メッセージを標準として作成する.

public class Message {
    private Long messageId;
    private User from_user_id;
    private User to_user_id;
    private String content;
    private Timestamp timestamp;

// 대화 리스트
elect to_user_id from message_table
				where from_user_id = A

//모든 메시지 출력
select * from message_table 
where from_user_id = A and to_user_id = B 
	  or from_user_id = B and to_user_id = A
order by create_at desc

すべてのメッセージを出力するには、whereセクションでandを検索する必要があります.
グループチャットの人数が増加すると、to user条件文はそれに応じて人数を増加します.
またKakaoTalkのように新しい情報があればチャットルームディレクトリの最上端にアップロードしますが不可能なようです

チャットアプリケーションの設計を検討する

ターゲット

1対1のチャットとグループチャットアプリケーションを導入したいです.
1対のユーザまたは複数のユーザが1つのスレッドを介して通信しようとします.
設計上の考慮事項

は、ユーザごとに独自のメールコピーを作成します.

の最も簡単なメッセージモデルでは、クエリー文が問題なので、できるだけ単一のユーザーのデータを同じ場所に保存します.

エンティティ

ユーザー:

は、唯一のUser idを有する.唯一のキーは(email、uuid、Long)です.

情報

ユーザが互いに送信するメッセージ.実際、メッセージを受信したのはThreadです.

チャットルーム(Threed)

チャットルームには、2人のユーザ間の会話が含まれている.1対1で、グループチャットにはユーザーごとにテーマがあります.また,情報交換はThreadのみで行うことができる.

アクション

メールの送受信

メッセージは、ユーザのすべてのトピックに追加されます.受信者の
上部に表示されていることを確認します.

アプリケーションモデリング

ユーザー:

ユーザーの場合、個人情報をモデリングして取得できるため、省略します.

情報

メッセージは、ユーザに直接送信されるのではなく、チャットルームを介して送信されるフォーマットに変更される.

新しいメールは、指定したトピックのメールリストに追加する必要があります.

トピックのメールリストは時間が経つにつれて増加するため、最後の50件のメールを検索できます.

メッセージは1対1でグループ化されている.

메시지

MessageID Long 메시지 인식키
author User 메시지 작성자
content String 내용
timestamp TimeStamp 밀리세컨드로 표시 (시간 순으로 메시지를 정리하기 위해서)
forwarded boolean 메시지가 제대로 전달 되었는지 확인
thread_id Long 대화방의 식별키
thread_type String 개인 또는 그룹 채팅인지 구분함

かいわしつ

owner idを使用すると、参加するすべてのトピックを検索できます.

update atを使用すると、最新のメッセージの順序で書き込み内容をソートできます.

대화방(쓰레드)

owner_id	Long 각 사용자에 관한 아이디
thread_id	Long 메시지 교환이 이뤄지는 쓰레드
participants_ids	json	각 대화에 참가자 명단
ismuted	bool	대화방 알람을 온오프 기능
nickname	String	대화방 이름
create_at	timestamp	2019-07-15 12:00:00
update_at	timestamp	2019-07-15 12:00:00

// 유저의 대화방 리스트 조회
$threadId_list = select thread_id from thread_table
where owner_id == A

// 본체 대화방 별 조회하기
select * from message_table 
where thread_id = A
order by create_at desc

// 대화방에 참여하고 있는 모든 유저 조회
$participantsId_list = select participants_ids from thread_table
where thread_id in $threadId_list
order by update_at desc

上記の手順でチャットアーキテクチャを決定します!

チャットサーバの構成と作成方法を決定しました.次に、チャットサーバの作成を開始します.