Ignore: ✨ Receive Chatroom Detail Informations

[psychology50]

작업 이유

• Enable users to retrieve chatroom details (e.g., recent messages, participants, user info) upon accessing the chatroom.

작업 사항

1️⃣ Design

Data requirements:

1. myInfo
2. recentChatMessages
3. recentParticipants
4. otherParticipantIds

Since the participant list can reach a max of 300 users, sending all at once is impractical. To handle this, the server will first send recently active participants. The client can then request additional participant details as needed.

2️⃣ Reuqest & Response Specification

• request
  • url: GET /v2/chat-rooms/{chatroom_id}
  • pre-condition: Authenticated User, Joined Chatroom
• response
  

3️⃣ Redis Chat Message Structure

Previously, we stored chat messages with a key format of chatroom:{chatroom_id}:message:{message_id} in a hash. Although message_id is unique and sortable, it didn’t ensure order when saving. By switching to a Sorted Set, we resolve issues around slicing chat history and counting unread messages.

4️⃣ DTO Naming

• We need a response DTO, but ChatRoomRes.Detail already exists.
• Maybe we can try to serialize with ignored fields in the original detail DTO. (Creation must be processed using a static factory method.)
  • This requires thorough testing, and exception handling is challenging since record types provide a public constructor by default.

// 1. View 중심의 네이밍
public final class ChatRoomRes {
    public record Summary(...) { }  // 목록 표시용 간단 정보
    public record Info(...) { }     // 기존 Detail을 Info로 변경 (기본 정보)
    public record View(...) { }     // 새로운 DTO (상세 페이지 전체 뷰)
}

// 2. 사용 목적 중심의 네이밍
public final class ChatRoomRes {
    public record Summary(...) { }           // 현재와 동일
    public record BasicDetail(...) { }       // 기존 Detail
    public record CompleteDetail(...) { }    // 새로운 DTO
}

// 3. 도메인 중심의 네이밍
public final class ChatRoomRes {
    public record Summary(...) { }                 // 현재와 동일
    public record RoomDetail(...) { }             // 기존 Detail (방 정보만)
    public record RoomWithParticipants(...) { }   // 새로운 DTO (방+참여자+메시지)
}

• I selected the third solution among the three choices:
  • clarity of domain information
  • other developers can easily infer what information it contains
  • intuitive and straightforward documentation.

리뷰어가 중점적으로 확인해야 하는 부분

• I think the client has the responsibility for sorting based on the user’s name, as the server initially fetches only partial data.
• Is the hasty data send at first approach optimal?

발견한 이슈

• Update the socket application image to reflect the revised chat message-saving strategy.
• Add unread message count to chatroom search response.