2.24 회의록

논의사항

수만

• issue를 잘게 나누고 squash 머지를 사용하는 방식 해보는거 어때요?

  • 이유
    1. rebase 머지로만 경험하는 것보다 더 다양한 경험을 할 수 있을거 같음 (일주일동안 이런식으로 도전적으로 사용)
    2. PR을 보낼 때 이전 PR이 머지가 필요한 경우 불편함 발생
       • → 그렇다고 그냥 머지하기에는 머지 커밋이 남음
       • → 그래서 issue 단위로 squash 머지를 하는 방식이 좋아보임
  • ⇒ 일주일만 squash 머지를 하자

• API, Socket 간 요청 응답 로직 다시 생각해 볼 필요 있음 (Chat GPT 이상해..)

  <aside> 👀 질문

  API 서버와 Socket 서버가 있을 때 클라이언트에서 Socket서버에 요청을 보내고 Socket 서버에서 API 요청을 보내도록 하는 게 좋을까 아니면 API 요청, Socket 요청을 각각 클라이언트에서 보내는 게 좋을까?

  예를 들면, 사용자가 좋아요를 누르면 실시간으로 좋아요가 올라간 것을 브로드 캐스팅하고, Table을 업데이트 하는 API 요청을 보내는 경우

  </aside>

  <aside> 👀 응답

  이 경우에는 클라이언트에서 Socket 서버에 요청을 보내고 Socket 서버에서 API 요청을 보내는 것이 더 나은 방법일 수 있습니다.

  사용자가 좋아요를 누르면 브로드캐스팅을 통해 실시간으로 데이터를 전송해야하므로, 이에 적합한 방법은 WebSocket을 사용하는 것입니다. WebSocket은 실시간으로 양방향 통신을 지원하므로, 클라이언트에서 WebSocket을 통해 Socket 서버에 요청을 보낼 수 있습니다. 이렇게 하면, Socket 서버에서는 요청을 받아들여 API 서버에 전달하여 데이터를 업데이트하고, 동시에 WebSocket을 통해 브로드캐스팅을 수행할 수 있습니다.

  또한, WebSocket을 사용하면 클라이언트와 서버 간에 계속적인 연결을 유지할 수 있으므로, API 요청과 WebSocket 요청을 따로 보낼 필요가 없어집니다. 따라서 클라이언트에서 Socket 서버에 요청을 보내고 Socket 서버에서 API 요청을 보내도록 하는 것이 더 효율적이고 성능적으로 유리할 수 있습니다.

  따라서, 이 경우에는 클라이언트에서 Socket 서버에 WebSocket을 통해 요청을 보내고 Socket 서버에서 API 요청을 보내도록 하는 것이 적합한 방법일 수 있습니다.

  </aside>

1. API 서버랑 Socket 서버 각각 보낸다
   1. 장점: Socket서버의 부하를 덜 수 있다. 서버의 관심사, 역할을 분리할 수 있다.
   2. 단점: 동기화가 떨어질 수 있다. (데이터 불일치)
   3. ⇒ 우리는 실시간이 엄청 중요하진 않으니까. 채팅 서비스보다는 실시간이 중요하지 않다. 좀 느려도 괜찮다. Socket 서버 삑나도 API 서버 잘 돌아가면 괜찮지 않을까?
      1. 실시간 중요한가 중요함 우리는 강의나 강연에서도 실시간으로 사용되기를 원함 하지만 채팅 보다는 아님
2. Socket 서버가 API 서버에게 보낸다
   1. 장점: 동기화가 좋다.
   2. 단점: Socket서버의 부하가 생길 수 있다. Socket 맛가면 패널 페이지도 다 맛간다.

1번 방법

socket.emit(’event).then(’api요청’) // 밑에 방법보다는 동기화가 좀 잘 됨

api 요청

socket.emit(’event’)

일주일동안 고민해보도록

진행 사항

준영

• 토큰 방식 수정(리다이렉트)
  • refreshToken: 쿠키
  • accessToken: 인메모리
  • toquizToken: 쿠키 + 인메모리
• 메인페이지 UI → 다음 주 월요일 까지

수만