[all] back/develop 브랜치에서 채팅 소켓 연결중 상의할 내용

[parktest0325]

back/develop 브랜치에서 채팅 소켓 연결중 상의할것들

front

@kimminkyeu
1. 소켓관리를 전역컨텍스트로 구현
게임소켓은 어떻게 관리되고 있는지 궁금한데, 채팅소켓은 useError와 비슷하게 useSocket으로 전역컨텍스트에 담아서 관리해보려고 합니다.
저희 최상단 템플릿 컴포넌트가 완전히 분리되어있는데 채팅소켓은 L1, L2 템플릿 모두에서 사용될 수 있어서 전역적으로 관리해야 될거같아요
최상단에서 바로 연결해서 관리하면 소켓을 로그인 이전에 연결하려고 할것같아서 connect 함수를 따로 분리해놨습니다.

// context/SocketContext.tsx
import { SOCK_URL } from '@/../config/backend';
import React, { ReactNode, createContext, useEffect, useState } from 'react';
import io, { Socket } from 'socket.io-client';

interface SocketContextProps {
  chatSocket: Socket | null;
  chatConnect: (props: ChatConnectProps) => void;
};

const SocketContext = createContext<SocketContextProps>({
  chatSocket: null,
  chatConnect: () => {},
});

interface SocketProviderProps {
  children: ReactNode;
};

interface ChatConnectProps {
  userId: number; // 나중에 세션쿠키로 변경예정
};

export const SocketProvider: React.FC<SocketProviderProps> = ({ children }) => {
  const [chatSocket, setChatSocket] = useState<Socket | null>(null);

  const chatConnect = ({ userId }: ChatConnectProps) => {
    if (!chatSocket) {
      const newSocket = io(SOCK_URL, {
        path: '/chat_socket',
        query: {
          user_id: userId,
        },
      });
      setChatSocket(newSocket);
    }
  };

  useEffect(() => {
    return () => {
      if (chatSocket) {
        chatSocket.disconnect();
      }
    };
  }, [chatSocket]);

  return (
    <SocketContext.Provider value={{ chatSocket, chatConnect }}>
      {children}
    </SocketContext.Provider>
  );
};

export const useSocket = () => {
  const { chatSocket, chatConnect } = React.useContext(SocketContext);
  return { chatSocket, chatConnect };
};

back

@kyu-baek
back/develop 에 back/chat-gateway 가 머지된걸로 보이는데 혹시 chat 소켓관련 추가된 사항이 있나요?
일단 오늘 클러스터에서 같이 이야기해볼 내용 정리해봤습니다.
주된 내용은 join을 어디서 하냐가 될것같습니다.

1. 소켓연결 방법. (동일한 포트로 연결)
=> 🔧 useWebSocketAdapter 때문인것 같음
주석처리 후 실행하거나 인자로 app을 전달하면 보면 3000포트로 정상적으로 동작함

// main.ts
async function bootstrap() {
  const app = await NestFactory.create(AppModule);
  app.useWebSocketAdapter(new GameSocketIoAdapter(app));   // <- app 전달 혹은 이 라인 주석

2. handleConnection
연결시에 channel_id 전달? => 불필요해보임

  async handleConnection(@ConnectedSocket() socket: Socket): Promise<void> {
    const { user_id, channel_id } = socket.handshake.query; //string | string[] 으로 들어옴
    socket.data.user = user_id as string;
    socket.data.channel = channel_id as string;
    try {
      const userIndex = this.users.findIndex((u) => u.userId.toString() === user_id);
      if (userIndex >= 0) {
          this.server.in(this.users[userIndex].socketId).disconnectSockets();
          this.users[userIndex].socketId = socket.id;
      } else {
        this.users.push({ userId: parseInt(user_id as string), socketId: socket.id });
      }
    } catch (error) {
      socket.disconnect();
    }
  }

3. 소켓 join 관련 이벤트가 없음
3-1. 채팅방이 화면에 보일때만 메시지를 받게함
장점 : 쓸모없는 메시지가 들어오지 않는다.
단점 : 채팅방밖에 있을때 메시지를 받을 수 없어서 알람이 오지 않음 (필요하다면 알람소켓을 따로파기? 일단 생각없음)
3-2. 처음에 모든 채팅방에 join
장단점이 서로 반대로

현재 구현된 부분을 보면 처음에 소켓 연결 시 아무것도 하지 않고, join 관련 이벤트가 없어서
3-1은 이미 입장한 채팅방을 클릭했을때 호출할만한 이벤트가 없고
3-2는 처음 소켓 연결 시 채널에 join할만한 이벤트가 없습니다.

=> 3-1로 구현하는경우 소켓 join 관련 이벤트가 필요하고, 3-2로 구현하는경우 소켓연결 시 현재 가입된 모든 채널을 join시켜야합니다.
=> 소켓 join 관련 이벤트를 따로 만들고, 다른 이벤트에서는 join을 사용하지 않도록 한다면 3-1, 3-2 유동적으로 사용 가능할것같아요

4. enter-chat이 호출되면 join 됨
채팅방 입장 시 실제로 상세화면으로 이동되는게 아니라서 3-1 방식으로 만든다면 join되어선 안될거같아요
아마 leave도 마찬가지일듯 싶습니다.

지금까지 생각해봐도 뭐가 나을지는 모르겠네요 만약 채팅방 이름, 설정변경같은 부분이 실시간으로 변경될거라면 소켓으로 정보전달될거같은데 그런거 하려면 전체 채팅방에 미리 join되는게 맞는거같기도 하네요

현재 보고있는 채팅방 외에는 필요없는 메시지 : 밴, 뮤트, 킥
필요할수도 있는 메시지 : 오너변경, 채팅방 정보 변경

---

회의 결과

항상 listen 하는 이벤트
chat
alarm => userAlarm 으로 useError처럼 표시해줌 (추가기능)

1. invite
2. update room => { 채널 생성리턴값이랑 똑같은 객체 }
3. kick (=밴까지) => 메시지만 변경
4. error : 각 이벤트에 대한 에러 => 진짜 알람 useError

방에 들어갔을때 listen하는 이벤트
나머지

채널리스트 변경되는 시점
0. 처음 로그인 시
=> 전부 join => 메시지 전달받는거x

1. 방생성 (초대x)
   => 생성된 방 join => 서버에서 조인시켜줌 => 메시지 전달받는거x
2. 방 나가기
   => leave => 서버에서 leave해줌 => 메시지 전달받는거x
3. 킥 (=밴)당하는 순간
   => 본인에게 메시지 전달(alarm) {channel_id}
   => 본인 빼고 나머지에게는 kick 메시지 {user_id}
4. 초대
   => 당사자 빼고 브로드캐스트로 메시지 전달 { 채널 생성 리턴값과 동일한 객체 }
5. 설정 변경
   => 나머지 사람에게 브로드캐스트

[kimminkyeu]

@parktest0325
네 useSocket을 이용한 context 생성 좋다고 생각합니다! 추가로 의견 드리면,
L0 컴포넌트에 provider를 넘겨주면(아래 예시 참조) L1 L2가 BrowserRouter의 child이기 때문에 모두 사용 가능하지 않나 싶네요
(L0 컴포넌트의 <Outlet> 부분이 L1이 되고, L1 컴포넌트의 <Outlet> 부분은 L2가 되기 때문에 전달될 거라 추측합니다)

따라서 connect 시점 관련해서 connect 함수를 따로 전달하지 말고, socketProvider를 browserRouter의 "/" 경로에 넣어줘도 전달 될 것 같은데
예를 들면,

{
    // 홈화면 (로그인 후)
    path: "/",
    element: (
      <div>
        <SocketProvider>
          <L0Template organism={<Controller />} />
          <AlertSnackbar />
          <Game />
        </SocketProvider>
      </div>
    ),
 //...

이렇게 하면 로그인 이후에 소켓 연결 + L1 L2 모두 사용 가능하지 않을까 싶습니다 (추정입니다! 정말 로그인 이후 연결되는지는 테스트 필요)

[kimminkyeu]

@parktest0325 다시 생각해보니 제가 적은 방식보다는 동현님이 제안하신 방식이 맞는것 같습니다.
그 이유는
첫째, / 홈 경로로 들어왔을때 즉시 user_setting을 api 요청하면서(userId 획득 + 세션검증)을 하는데, 검증 통과시에만 소켓을 연결하도록 하는게 더 효율적이기 때문이고
(이렇게 안할 경우, 세션 검증 이전에 소켓 연결이 먼저 이뤄짐 -> 검증 실패시 연결이 의미없음)
둘째, 위처럼 연결시점을 명확히 하기 위해선 connect 함수가 따로 존재해야 하기 때문입니다

결론: gameSocket은 동현님께서 제안주신 규칙으로 작성하도록 하겠습니다.

[kyu-baek]

3번의 기능이 enter-chat 이고, 4번의 기능은 api 쪽에 있습니다~