grace's dev_note

서비스를 운영하다 보면 트래픽이 늘어나거나 DB에 부하가 생기기도 하고 기간 통신망이 끊기게 되는 경우도 발생합니다. 장애는 어느 레이어에서든 발생할 수 있고 사용자의 불편을 줄이기 위해 신속하게 장애에 대응하는 게 필요합니다. 그러려면 현재 서비스가 건강한 상태인지 항상 체크하고 있어야 할 장치가 필요합니다. 이를 헬스 체크라고 부릅니다. 서버는 HTTP, DB, 메모리, 디스크 상태 등을 체크하는 헬스 체크 장치가 있어야 합니다. 만약 서버가 건강하지 않은 상태가된다면 즉시 이를 사내 메신저 등을 통해 담당자에게 알려야 합니다. 헬스 체크와 함께 쌓아둔 에러 로그를 기반으로 종합적으로 모니터링 전략을 세워야 합니다. Nest는 Terminus(@nestjs/terminus) 헬스 체크 라이브러리를 제..

@nestjs/schedule 패키지 서비스를 개발하다 보면 주기적으로 동일한 작업을 처리해야 하는 경우가 생깁니다. 이런 주기적 반복 작업을 태스크 또는 배치라고 부릅니다. 태스크 스케줄링을 잘 활용하면 특정 기간마다 수행해야 하는 귀찮은 작업을 신경쓰지 않아도 됩니다. 태스크 스케줄링을 반드시 반복적인 작업에만 적용해야 하는 것은 아닙니다. 1회성 태스크를 만들 수도 있습니다. 리눅스에는 태스크 스케줄링을 담당하는 크론이라는 기능이 있습니다. Node.js에는 cron과 같은 기능을 하는 여러 라이브러리가 있습니다. Nest는 인기 패키지인 node-cron을 통합한 @nestjs/schedule 패키지를 제공합니다. $ npm i @nestjs/schedule @types/cron 태스크 스케줄링은..

인터셉터 인터셉터는 요청과 응답을 가로채서 변형을 가할 수 있는 컴포넌트입니다. 인터셉터는 관점 지향 프로그래밍에서 영향을 많이 받았습니다. 인터셉터를 이용하면 다음과 같은 기능을 수행할 수 있습니다. 메서드 실행 전/후 추가 로직을 바인딩 함수에서 반환된 결과를 변환 함수에서 던져진 예외를 변환 기본 기능의 동작을 확장 특정 조건에 따라 기능을 완전히 재정의(예: 캐싱) 인터셉터는 미들웨어와 수행하는 일이 비슷하지만, 수행 시점에 차이가 있습니다. 미들웨어는 요청이 라우트 핸들러로 전달되기 전에 동작하며, 인터셉터는 요청에 대한 여러 개의 미들웨어를 조합하여 각기 다른 목적을 가진 미들웨어 로직을 수행할 수 있습니다. 어떤 미들웨어가 다음 미들웨어에 제어권을 넘기지 않고 요청/응답 주기를 끝내는 일도 ..

소프트웨어를 개발하면서 예외 처리는 필수 사항입니다. 어떤 상황에서든 에러는 발생할 수 있고 개발자는 이 에러에 대응책을 마련해둬야 합니다. 예외가 발생할 만한 모든 곳에 예외 처리 코드를 삽입하는 것은 중복 코드를 양산할 뿐 아니라 기능 구현과 관련 없는 코드가 삽입되므로 핵심 기능 구현에 집중하지 못하게 됩니다. 예외가 발생했을 때 에러 로그와 콜 스택을 남겨 디버깅에 사용할 수 있는 별도의 모듈을 작성했다면, 예외 처리기 역시 따로 만들어 한곳에서 공통으로 처리하도록 해야 합니다. 예외 처리 Nest는 프레임워크 내에 예외 레이어를 두고 있습니다. 애플리케이션을 통틀어 제대로 처리하지 못한 예외를 처리하는 역할을 합니다. 아무런 작업을 하지 않아도 기본 예외 처리기가 예외를 잡아서 유저가 이해하기 ..

서비스에 기능이 늘어나고 사이즈가 커지게 되면 동작 과정을 남기고 추적하는 일이 중요하게 됩니다. 이슈가 발생했을 경우 이슈 증상만으로 원인을 파악하는 데에는 시간과 노력이 많이 들고 코드를 다시 역추적하면서 이해하는 데에 어려움이 따릅니다 .이슈가 발생한 지점과 콜 스택이 함께 제공된다면 빨리 해결이 가능할 것입니다. 또 어떤 기능이 많이 사용되는지와 같이 유저의 사용 패턴을 분석하는 데에도 로그를 활용할 수 있습니다. 서비스를 실행하면 서버 콘솔에는 로그가 출력됩니다. 이미 각 컴포넌트에서는 내장 로거를 이용하여 로그를 출력하고 있습니다. 내장 Logger 클래스 @nest/common 패키지로 제공됩니다. 로깅 옵션을 조절하면 다음과 같이 로깅 시스템의 동작을 제어할 수 있습니다. 로깅 비활성화 로..

가드 인증은 미들웨어로 구현하는 것이 좋은 사례입니다. 애플리케이션은 사용자의 권한을 확인하기 위해 인증과 인가를 수행해야 합니다. 인증은 요청자가 자신이 누구인지 증명하는 과정입니다. 최근에는 매 요청마다 헤더에 JWT 토큰을 실어 보내고 이 토큰을 통해 요청자가 라우터에 접근 가능한지 확인하는 방식을 많이 사용합니다. 이해 비해 인가는 인증을 통과한 유저가 요청한 기능을 사용할 권한이 있는지를 판별하는 것을 말합니다. 퍼미션, 롤, 접근 제어 목록 같은 개념을 사용하여 유저가 가지고 있는 속성으로 리소스 사용을 허용할지 판별합니다. 인가는 가드를 이용하여 구현할 수 있는 좋은 사례입니다. 보통 인증과 인가에 실패할 경우 응답에 대한 HTTP 상태 코드는 각각 401 Unauthorized와 403 F..

파이프 파이프는 요청이 라우터 핸들러로 전달되기 전에 요청 객체를 변환할 수 있는 기회를 제공합니다. 미들웨어의 역할과 비슷하지만 메들웨어는 애플리케이션의 모든 콘텍스트에서 사용하도록 할 수 없습니다. 미들웨어는 현재 요청이 어떤 핸들러에서 수행되는지, 어떤 매개변수를 가지고 있는지에 대한 실행 콘텍스트를 알지 못하기 때문입니다. 라우트 핸들러는 웹 프레임워크에서 사용자의 요청을 처리하는 엔드포인트마다 동작을 수행하는 컴포넌트를 말합니다. 라우트 핸들러가 요청 경로와 컨트롤러를 매핑해준다고 이해하면 됩니다. 파이프는 다음 두 가지 목적으로 사용됩니다. 변환: 입력 데이터를 원하는 형식으로 변환. 예를 들어 /users/user/1 내의 경로 매개변수 문자열 1을 정수로 변환 유효성 검사: 입력 데이터가 ..

Nest는 dotenv를 내부적으로 활용하는 @nestjs/config 패키지를 제공합니다. 이를 이용해서 COnfigModule을 동적으로 생성할 수 있습니다. $ npm i --save @nestjs/config 이 패키지에는 ConfigModule 이름을 가진 모듈이 이미 존재합니다. 이 모듈을 동적 모듈로 가져옵니다. ... import { ConfigModule } from '@nestjs/config'; @Module({ imports: [ConfigModule.forRoot()], ... }) export class AppModule {} 정적 모듈을 가져올 때와는 달리 ConfigModule.forRoot() 메서드를 호출합니다. forRoot 메서드는 DynamicModule을 리턴하는 ..

프로바이더 컨트롤러는 요청과 응답을 가공하고 처리하는 역할을 맡습니다. 하지만 서버가 전달하는 핵심 기능은 전달받은 데이터를 어떻게 비즈니스 로직으로 해결하는가입니다. 앱이 제공하고자 하는 핵심 기능, 즉 비즈니스 로직을 수행하는 역할을 하는 것이 프로바이더입니다. 컨트롤러가 이 역할을 수행할 수도 있겠지만 소프트웨어 구조상 분리해두는 것이 단일 책임 원칙에 부합합니다. 프로바이더는 서비스, 저장소, 팩터리, 헬퍼 등 여러 가지 형태로 구현이 가능합니다. Nest에서 제공하는 프로바이더의 핵심은 의존성을 주입할 수 있다는 점입니다. 의존성을 주입하기 위한 라이브러리가 많이 있지만 Nest가 이를 제공해주기 때문에 손쉽게 사용할 수 있습니다. 의존성 주입은 OOP에서 많이 사용하는 기법입니다. 의존성 주입..

컨트롤러 Nest의 컨트롤러는 MVC 패턴에서 말하는 그 컨트롤러를 말합니다. 컨트롤러는 들어오는 요청을 받고 처리된 결과를 응답으로 돌려주는 인터페이스 역할을 합니다. 컨트롤러는 엔드포인트 라우팅 메커니즘을 통해 각 컨트롤러가 받을 수 있는 요청을 분류합니다. 컨트롤러를 사용 목적에 따라 구분하면 구조적이고 모듈화된 소프트웨어를 작성할 수 있습니다. 다음과 같이 컨트롤러를 생성합니다. $ cd [project folder] $ nest g controller [controller name] AppModule에는 방금 생성한 UserController와 프로젝트를 생성할 때 만들어진 AppService를 임포트해서 사용하고 있습니다. 그 밖의 Nest 구성 요소에 대한 약어는 nest -h 명령어로 확인..