로깅(logging)은 어플리케이션에서 발생하는 모든 오류 및 정보등 각종 이벤트를 남기는 것으로, 문제 발생 시 원인을 파악하는데 매우 중요한 역할을 합니다. 현재 테크팀은 스프링 프레임워크의 경우 logback을 이용하여 로깅 처리를 하고 있으며, 일명 ELK(Elasticsearch, Logstash, Kibana)를 구성하여 로깅 정보를 집계하고 확인하고 있습니다. NestJS 프레임워크 역시 이러한 로깅 처리는 매우 중요한 기능이였고, 고민하지 않고 Node.js에서 사용하던 winston log 모듈을 사용하기로 결정 하였습니다. Node.js에서 log를 효율적으로 관리할 수 있게 도와주는 모듈인 winston log 모듈은 실제 서버를 운영할 때 console.log와 console.er..

기본적으로 스프링에서는 다음과 같은 요청의 흐름이 있습니다. (스프링 시큐리티 필터의 경우 DelegatingFilterProxy 라는 필터를 만들어 메인 Filter Chain에 추가하여 동작하는데 DelegatingFilterProxy는 서블릿 컨테이너 영역의 필터와 ApplicationContext에 Bean으로 등록된 필터를 연결시켜주는 역할을 합니다.) 이 요청 흐름은 스프링을 공부하고 사용하고 계신 분들이라면 모두 알고 있을겁니다. 그리고 저희 테크팀에서도 처음 NestJS를 사용하면서 가장 먼저 관심을 가지게 된것은 이러한 요청 생명 주기 였습니다. 기본적으로 NestJS의 요청 흐름은 다음과 같이 이루어 집니다. Middleware : 가장 먼저 전역으로 설정된 미들웨어 부터 실행되며, 이..

그동안 웹프로젝트 및 API프로젝트 개발을 하면서 JAVA를 기반으로 하는 스프링 프레임워크를 이용 하였습니다. 스프링은 경량급 프레임워크 이면서 IoC 컨테이너, DI, AOP라는 핵심 기능을 가지고 있고 개발을 편리하게 해주고 있습니다. 그러나 이러한 스프링을 이용하기 위해서는 지옥같은 방대한 양의 XML 설정이나 특유의 라이브러리 의존 충돌 문제등 신경써야 될 것이 많았습니다. 후에 JAVA 설정으로 변경되었고, 스프링 부트에서는 필수적인 설정이 기본으로 되어 있거나, 최소한의 구성으로만 쉽게 작동한도록 변화 되면서 복잡한 설정 정보를 간략화 할 수 있도록 하였습니다. 그러나 작은 규모의 서버를 스프링 부트로 개발하려면 최소한의 스프링의 지식과 설정 및 구현시간이 필요합니다. 그래서 몇년전부터 N..