Why?

현재 채팅 기능의 로직은 이러하다

  1. 채팅 컴포넌트 마운트
  2. 서버 소켓과 connection을 위한 새로운 소켓 생성
  3. userId, sessionId를 알고 있는 상태에서 join_room 시도
  4. 서버에서 userId를 토대로 검증 후 채팅 가능 여부 전송

처음 채팅 기능을 설계할 때도 고민했던 지점은 매번 마운트&언마운트 시에 소켓을 생성해 connect하고 disconnect를 반복하는 부분이었다.

userId는 고유하지만 사용자가 여러탭으로 입장하게 된다면 하나의 userId에 대한 여러 socket이 연결된다는 문제가 있었고, 이로인해 불필요한 소켓 연결이 늘어나 서버의 리소스 낭비를 불러일으킬 수 있다는 결론이 나왔다.

https://www.youtube.com/watch?v=SVt1-Opp3Wo

그러던 중 토스에서도 같은 고민을 했었으며 해당 영상의 인사이트를 통해 하나의 userId에 대한 하나의 소켓으로 개선해보기로 결정하였다.

How?

브라우저 탭들이 하나의 상태를 공유할 수 있도록하는 외부의 무언가가 필요했다

그리고 Web Worker API는 그 역할을 해 줄 수 있었다!

Shared Worker Thread

image.png