8/29 TIL 소켓 채팅 데이터 불러오기 / 기술면접 11. DI, IoC에 대해서

이승준·2023년 8월 29일

🤔메시지가 뒤 늦게 들어온 소켓에서만 보내지는 오류

socket.to(room).emit(어쩌구) 에서 받아오는 room 에 대해 문제가 있어서 생긴 오류였고, 프론트엔드 단에서 roomId를 받을 수 있는 코드를 넣었다.
~~정확히 기억이 안나서.. commit을 생활화하자.. !~~

🤔소켓에서의 db직접접근 vs API 호출

같은 서버를 운용하면서 API를 호출 할 필요는 없다고 한다.
고민한 이유는 검증을 하기엔 소켓 서버쪽 부하와 유지보수성을 고려했고,
결과는 함수화 모듈화 시켜 소켓서버쪽관리를 하던가 아님 프론트단에서 검증을 하는 api 또는 코드삽입

일단은 서버쪽에서 검증 로직을 구현하자

🤔데이터정리를 어디서할까?

DB에서 받아온 메시지 데이터를 현재 소켓을 기준으로 데이터를 가공해야한다. 서버에서 처리하고 보낼까.. 프론트에서 받아서 처리할까?

서버처리 -> 성능이슈가 생길 수 있다. 하지만 보안에서의 장점이 있다.
클라이언트 -> 오류를 잡기 힘들다. 보안성에서도 문제가 있다.

라는 피드백을 받았다.

서버에서 처리해야지

🤔user와 targetUser 알고리즘

접속한 사람 기준으로 서버에서 user와 targetUser가 바뀐다

예를 들어 짱구로 로그인 했으면

user : 짱구
targetUser : 훈이

훈이로 로그인 했으면

user : 훈이
targetUser : 짱구

받아온 메시지 데이터는 채팅을 만든 사람 기준으로
is_send 가 true/ false 로 나뉜다

그래서 is_send가 true라고 무조건 user를 넣으면 안된다.

가공하는데 뭔가 별거 아닌 것 같은데 상당히 오래 걸렸다.

소켓 : 짱구

is_send 가  1 이면 무조건 짱구가 나와야되고
is_send 가 0 이면 무조건 훈이가 나와야되고

const senderName = chat.is_send  1? :
근데 roomOwner 가 true 면 userName 짱구야
근데 roomOwner 가 false 면 targetUserName 짱구야

소켓 : 훈이

roomOner false 
const senderName = chat.is_send  0 ? :

그래서 결론은 채팅룸을 가져올 때 만든사람과 현재 접속한 사람을 대조해
roomOwner : true/ false 를 만들어 놨고,

roomOwner 와 is_send를 대조해 맞는 인원을 대입했다

function getMessage(chatData, userName, targetUserName) {
  const messages = [];

  chatData.forEach((chat) => {
    const senderName = chat.is_send === roomOwner ? userName : targetUserName;
    const message = `${senderName} : ${chat.message_content}`;
    messages.push(message);
  });
  return messages;
}

~~별거 아닌데 한시간정도 푼 것 같다~~

기술면접 11. DI와 IoC

DI (Dependency Injection)와 IoC (Inversion of Control)는 소프트웨어 개발에서 중요한 개념으로, 코드의 유연성과 테스트 용이성을 증가시키는 데 도움을 주는 디자인 패턴입니다.

1. Dependency Injection (DI):

DI는 의존성 주입이라고도 하며, 어떤 객체가 필요로 하는 의존성을 외부에서 제공받는 패턴입니다. 객체가 다른 객체에 의존하고 있다면, 이 의존성을 객체 내부에서 생성하거나 관리하지 않고 외부에서 주입받아 사용합니다. 이를 통해 결합도가 낮아지며 코드의 재사용성, 테스트 가능성, 유지보수성이 향상됩니다.

예를 들어, 클래스 A가 클래스 B에 의존하고 있다면, 클래스 A에서 클래스 B의 인스턴스를 직접 생성하는 대신, 외부에서 클래스 B의 인스턴스를 주입받아 사용하는 것이 DI의 원칙을 따른 것입니다.

2. Inversion of Control (IoC):

IoC는 제어의 역전이라고도 하며, 프로그램의 흐름 제어가 개발자가 아닌 프레임워크나 컨테이너에 의해 이루어지는 패턴입니다. 이는 프레임워크가 애플리케이션의 주요 흐름을 제어하고 필요한 작업을 수행하도록 합니다. IoC 컨테이너는 객체의 생성과 의존성 주입을 관리하며, 개발자는 객체 간의 관계를 설정하고 컨테이너에게 제어를 위임합니다.

DI와 IoC는 서로 밀접하게 연관되어 있습니다. DI는 IoC를 실현하는 수단 중 하나로, 의존성을 주입함으로써 IoC 원칙을 따릅니다.

장점:

코드의 결합도를 낮추고 모듈 간의 의존성을 분리하여 유연한 구조를 유지할 수 있습니다.
코드 재사용성이 증가하며, 유지보수와 테스트가 쉬워집니다.
객체 생성과 의존성 관리를 중앙에서 처리함으로써 일관성을 유지할 수 있습니다.

DI와 IoC의 구현:

DI와 IoC는 다양한 프레임워크와 라이브러리에서 구현되어 있습니다. Java에서는 Spring 프레임워크가 대표적인 DI와 IoC의 구현 예시입니다. 다른 언어와 환경에서도 Guice, Dagger (Java), Angular (JavaScript), ASP.NET Core (C#) 등의 프레임워크가 DI와 IoC를 지원하고 있습니다.