논의 주제

• 소켓 통신을 요청-응답 모델처럼 다루는 것이 필요한가?
• 소켓 서버의 역할의 최소화

본인의 의견(찬성 입장)

• 에러 핸들링이나 서버와의 통신의 일관성을 위해서 소켓 서버의 역할을 최소화해야합니다.
• 단순 구독이 아닌 요청이 필요하다면, 요청-응답 모델을 지원해야합니다.

근본적으로 HTTP 통신과 소켓 통신은 모델이 다릅니다.

• HTTP 통신 - 프로토콜 수준에서 요청과 응답을 보장
• 소켓 통신 - 구현 수준에서 요청과 응답을 보장

소켓 서버에 요청까지 하는 상황이라면, 요청-응답 모델을 보장해줘야합니다.

⇒ 소켓 서버가 특정 요청에 대한 응답을 보내도록 구현을 통해 요청-응답 모델을 보장할 수는 있지만, 이 로직은 HTTP와 달리 프로토콜 자체의 보장이 아닙니다. 따라서 개발자가 클라이언트와 서버 양쪽에서 이러한 요청-응답 흐름을 보장하도록 코드를 작성해야 합니다.

아래와 같이 크리티컬한 기능을 담당하고 있으면 더더욱 해당 모델 지원이 필요합니다.

%% 로그인 과정에서 소켓의 역할
%% 크리티컬한 기능을 담당하고 있기에, 소켓 통신은 HTTP 통신처럼 요청-응답 모델 구조를 지원해야합니다.
graph LR
    %% __START
    Client <--> |1.create_gwToken| GatewayServer
    Client --> |2.login| GatewayServer
    GatewayServer --> |2.login| AuthServer
    AuthServer --> |3.authToken| GatewayServer
    GatewayServer --> |3.authToken| Client
    Client --> |4.publish| SocketServer
    SocketServer <--> |5.create_accessToken| GatewayServer
    SocketServer --> |6.send_accessToken| Client
    %% __END