Backend/NestJS (18) 썸네일형 리스트형 NestJS - 대충 서비스 만들어보기 (18) 이번 내용은 NestJS 라고 하기보단 클린 아키텍처 같은걸로 타이틀을 해야할 것 같긴 합니다만.. 지금까지 만들었던 광고 서버의 구조를 좀 바꿔보려고 합니다. 현재까지 만든 디렉토리 구조는 위와 같습니다. 뭐좀 하다보니 이상한 위치에 있는 것처럼 보이는 것도 있습니다만.. 아무래도 시작할 때 nest-cli 를 통해 하나의 모듈 단위로 컴퍼넌트를 만들었다 보니 광고 관련된 건 ads / 인증 관련된건 auth 그 외에도 config, slack, redis 등으로 나뉘어져 있죠. 가장 메인이라고 할 수 있는 광고쪽을 보면 흔히 알고 있는 layered architecture 라고 할 수 있습니다. - Layered Architecture 각 계층의 이름은 경우에 따라 Presentation, Web, .. NestJS - 대충 서비스 만들어보기 (17) 저번 포스팅에서 @nestjs/cqrs 에 관한 내용 중 이벤트 기반 프로그래밍에 대한 부분을 이번 포스팅에서 간략히 보도록 하겠습니다. - EventBus 수동으로 이벤트를 발송하고, 그 이벤트를 구독해 적합한 처리를 하는 것은 @nestjs/cqrs 에서 제공하는 EventBus 를 이용하면 간단하게 구현할 수 있습니다. 여기서 EventBus 를 사용해볼 부분은 광고를 생성한 후 생성 결과 내용을 Slack 으로 알리는 부분입니다. @CommandHandler(CreateAdCommand) export class CreateAdHandler implements ICommandHandler { ... async execute(command: CreateAdCommand): Promise { ... a.. NestJS - 대충 서비스 만들어보기 (16) - CQRS CQRS 는 command query responsibility separation 의 줄임말로써, command 와 query 의 책임을 분리하는 패턴입니다. 여기서 command 는 시스템의 상태를 변경하는 명령을 뜻하고, query 는 상태를 변경하지 않으며 조회만 하는 요청입니다. 흔히 알고 있는 CRUD 로 구분하면 command 는 CUD / query 는 R 에 해당하겠습니다. CQRS 를 도입했을 때 성능, 확장성, 보안성이 향상된다고 합니다. 아무래도 일단 서비스가 고도화되다보면 조회시 필요한 데이터 모델과 상태를 변경할 때 필요한 모델이 차이가 나기 마련인데 command 와 query 가 분리되어 있지 않은 상태에선 이를 같이 가져가야하지만, 이를 분리하면 조회시 훨씬 가.. NestJS - 대충 서비스 만들어보기 (15) - Health Check 서비스를 운영하다보면 현재 서비스 상태가 정상적으로 서빙할 수 있는 상태인지, 그렇지 않은지 체크가 필요합니다. 서비스가 건강한 상태인지를 체크하는 장치를 우리는 일반적으로 헬스체크 라고 부릅니다. 팀에서 운영하는 서버들에도 이 부분은 아직 좀 미흡한 점들이 있습니다. 서비스가 건강한 상태인지를 체크하려면 사용하는 RDB, ElastiCache 와의 커넥션 상태를 비롯해 장비의 인메모리, 디스크 상태등을 확인해야 하지만 어떤 서버들에 대해선 /health path 만 따놓고 그냥 200 OK 응답을 반환하도록 되어있는 경우도 있습니다. 현 팀에선 어디든 그렇겠지만 RDB 와 Redis 의 커넥션 상태가 제일 중요한데, 이러한 DB 들과의 통신이 되지 않는 상황에선 앱이 죽어버릴.. NestJS - 대충 서비스 만들어보기 (14) 이번 포스팅에선 NestJS 의 인터셉터에 대해 보려고 합니다만.. 미들웨어, 가드, 예외 필터, 인터셉터, 파이프 등 뭔가 비슷해 보이는 것들이 참 많네요. Express 로 개발시엔 미들웨어로 대부분 다 처리했던 것 같긴 합니다만, 이것들을 약간 구분하기 위해 NestJS 의 request lifecycle 에 대해 먼저 보도록 하겠습니다 (링크) - Request Lifecycle (요청 생명주기) 요청에 대한 생명주기는 들어온 요청이 처리되고 최종 응답되기까지 어떠한 컴퍼넌트들을 거쳐 처리되는지를 말합니다. 요청이 들어왔을 때 처리되는 컴퍼넌트의 순서를 NestJS 공식 페이지 내용을 참고해 도식화한 것 입니다. 요청 -> 미들웨어 -> 가드 -> 인터셉터(pre-controller) -> 파이프.. NestJS - 대충 서비스 만들어보기 (13) 이번 포스팅에선 NestJS 에서 제공하는 예외 필터 기능을 사용해보겠습니다. - 예외 (Exception) 예외 처리는 무언가를 개발하는 과정에선 필수 사항인 것 같습니다. 개발자는 항상 에러가 발생할 수 있는 상황을 대비해야하고, 그에 따라 빠르게 에러를 전파하던지 또는 아예 무시되도록 하던지 하는 방법을 선택할 수도 있죠. 예전에 Express 로 처음 개발할 땐 에러 처리를 controller 부분에서 필수 파라미터가 undefined 일 땐 res.json(400)... 를, 그 이후 로직에는 전체에 try - catch 를 걸어서 뭔 에러던 다 catch 에서 잡고 500 으로 처리했었습니다. 이러다보니 코드 전체에 try - catch 및 res.json.. 이 난무했고, 보기엔 상당히 지저.. NestJS - 대충 서비스 만들어보기 (12) 이번 포스팅에선 NestJS 에서 제공하는 Guard 기능을 사용해보겠습니다. - 인증 vs 인가 인증은 Authentication, 인가는 Authorization 으로 의미하는 바는 좀 다릅니다. 인증은 유저의 신원을 검증하는 프로세스로, 자신이 누구인지를 증명하는 것입니다. 인가는 인증 이후의 프로세스로 인증된 사용자가 어떤 리소스에 접근할 수 있는지를 확인하는 것을 인가라고 합니다. NestJS 에선 Guard 를 사용해 인가를 구현할 수 있습니다. 좀 희한한건 일반적으로 응답 상태를 나타낼 때 인증이 실패하면 401, 인가가 실패하면 403 인데 401 - Unauthrozied / 403 - Forbidden 으로 되어있습니다. Forbidden 은 이해가 되지만 Authentication 실.. NestJS - 대충 서비스 만들어보기 (11) 이번 포스팅에선 NestJS 의 미들웨어에 대해 간단히 보도록 하겠습니다. - Middleware NestJS 의 미들웨어는 원래 알고 있던 Express 의 미들웨어와 다르지 않습니다. 일반적으로 미들웨어라 함은 클라이언트의 요청에 맞는 응답을 하기 위한 중간에 거쳐가는 함수들이라고 볼 수 있습니다. Express 에선 미들웨어라고 하면 대략 아래와 같이 구성되어 있는데요. (req: Request, res: Response, next: NextFunction) { ... next(); } req(요청) 와 res(응답) 객체 및 다음 미들웨어 함수의 액세스 권한을 갖는 함수를 말하며 next 를 호출함으로써 다음 미들웨어로 현재 요청을 넘길 수 있고, 이러한 구성에 의해 미들웨어는 순차적으로 처리됩니.. 이전 1 2 3 다음
