<aside> 📚 목차

</aside>

아젠다

• 소켓IO VS 웹소켓
• 웹소켓의 아키텍쳐(프로젝트별로 방을 나눌지? 다른 데이터는 어떻게 할지?)
  • 어떻게 데이터를 서로 주고 받을지
  • websocket을 한번에 열지, 각각의 화면에서 열지
• 부재중인 회원은 어떻게 관리할 것인가?
  • 클라이언트의 상태를 어떤기준으로 판단할것인가?
  • 최소한의 리소스로 위의 방안을 구현할 방법은?

회의 내용

1. 소켓IO VS 웹소켓 결정하기

<aside> 💡 서버와 클라이언트가 양방향 통신을 하기 위한 방식이 서로 다르면, 제대로 소통하지 못할 수 있다.

</aside>

결론

소켓 IO를 통한 클라이언트 양방향 통신 개발하기

• 소켓 IO는 양방향 통신에게 중요한 “연결을 지속할 수 있는 기능(재연결 기능 등)”을 가지고 있어 통신 기능 개발에 수고를 덜 수 있다.
• 소켓 IO가 제공하는 Room 기능으로 서버에서 웹소켓 객체를 더 쉽게 구현할 수 있다.
• 제공하는 여러 기능(폴링, 재연결 등)으로 인해 안정성이 더 높다.

2. 웹소켓의 아키텍쳐

: 페이지별로 웹소켓을 사용하기 vs 하나의 웹소켓으로 관리하기

<aside> 💡 페이지를 이동할 때마다 새로운 웹소켓 통신을 만들 것안가? 아니면, 모든 페이지를 아우르는 하나의 웹소켓 통신을 만들 것인가?

</aside>

하나의 웹소켓으로 관리하기

• 웹소켓을 매번 생성하는 것보다, 한번에 관리하는 것이 웹소켓 생성 리소스를 적게 소모한다.
• 하나의 웹소켓 객체로 관리한다면, 서버와 클라이언트는 프로젝트 전체 데이터 관리가 용이해진다.
• 하지만, 웹소켓 객체에서 관리하는 로직의 크기가 굉장히 커질 수 있다.