Node.js Socket 모노레포 적용기

도입 배경

소켓 분산작업을 위해 아키텍쳐를 구상하면서 3가지의 파트로 socket을 분리하였다.

1. 로드 밸런싱 서버(Road Balancing Server)
   에이전트가 처음 접근하는 서버로 붙어야하는 서버의 ip&port를 알려준다.

2. 브릿지 서버(Bridge Server)
   WAS에서 접근하는 서버로 N개의 소켓의 정보와 관련정보를 전부 가지고 있다.

3. 기존 소켓 서버(Socket)
   기존 소켓의 기능을 제공하며, 로드 밸런싱 서버와 브릿지 서버에 연결되어있다.

이때, 처음 적용한 방식은 각 파트별로 repository 관리하는 방식이었다.

각 버전별, 기능별로 구성이 다르기 때문에 아래와 같이 구성을 했었다.

문제 발생!?!

1. 각 프로젝트간에 중복된 기능 구현 (공통 기능 공유X)
2. 모든 프로젝트의 중첩된 eslint, prettier, tsconfig (하나로 관리가 안됨)
3. repository마다 node_modouls 를 따로 설치해야함
4. 프로젝트 생성의 표준이 없음
5. 혼자서 챙겨야하는 repository가 너무 많음(관리 이슈)
6. repository별 의존성 이슈
7. 배포 순서 수동화
8. 인원 충원시 협업의 어려움

해결방안

모노레포란?

모노레포는 모놀리식 저장소(monolithic repository)라는 뜻으로, 프로젝트에 필요한 모든 코드를 하나의 저장소(repository)에 포함시키는 개발 방법론입니다. 모든 코드가 하나의 저장소에 저장되기 때문에 복잡한 의존성 문제를 해결할 수 있고, 코드 공유와 재사용성이 용이해집니다.

모노레포의 적용시 장점

1. 단순화된 의존성 관리, 종속성관리
2. 표준 적용의 용이
3. eslint, prettier, tsconfing 공통 적용가능
4. 각 도메인의 독립성과 유연성 확보
5. 중복코드 및 기능 최소화
6. 하나의 node_modouls로 가능하다.
7. 배포 순서 및 방식 자동화
8. 협업 용이 (빠른 피드백 가능)

모노레포 적용 방식

💡 현재는 yarn workspace로 점진적 yarn berry workspace 적용

workspace 지정한 packages List

node_modules

• packages List의 라이브러리화
• 공통부분 모듈화

모노레포 적용 Socket

의존성 관리

각 패키지에 node_modules는 yarn workspace로 nodeLink로 연결 해줍니다.
하단과 같이 private과 workspace를 설정합니다.

//root package.json
{
	...
	"private": true,
    "workspaces": [
        "packages/**/*"
    ],
    ...
}

모노레포로 구성을 변경 후 새로운 라이브러리를 적용방식은 다음과 같습니다.

전체 프로젝트에 라이브러리 적용시

yarn add -W 라이브러리

하위 프로젝트에 라이브러리 적용시

yarn workspace 패키지명 add 라이브러리

공통 기능 및 중복 코드 적용방식

공통 표준을 repository 를 따로 구성하여 적용