이전에 'NestJs는 AOP를 지원할까?'에 대한 내용으로 포스팅을 했던 적이 있습니다. 당시에는 NestJs는 공식적으로 AOP를 지원하지 않는다고 했었습니다.  NestJs는 AOP를 지원할까? Spring AOP와의 비교 분석지난 몇 년간 Spring 생태계에 익숙해져 있었던 터라 Spring에서는 로깅, 트랜잭션, 예외처리등 공통로직을 '객체'로 바라보고 비즈니스로직에서 공통로직을 별도로 분리하는 AOP(Aspect Oriented Programmijminc00.tistory.com해당 블로그를 링크드인에 공유했는데, 토스의 Node.js 개발자인 김인성 님께서토스에서 NestJS에서 AOP를 사용하기 위해 만든 @toss/nestjs-aop 오픈소스 라이브러리를 소개해주셨습니다. (해당 라이브..

현대 애플리케이션 개발에서 의존성 주입(Dependency Injection, DI)은 코드의 모듈화와 유지보수를 크게 개선해 주는 중요한 설계 패턴입니다. NestJs와 Spring은 각각 TypeScript와 Java라는 서로 다른 언어를 기반으로 하지만, DI를 위해 비슷한 역할을 수행하는 개념을 가지고 있습니다.  NestJs에서는 Provider, Spring에서는 Component(혹은 Bean)라는 이름으로 이를 구현하는데, 두 프레임워크의 등록 방식과 곤리 방식은 어떤 차이가 있는지 궁금증을 가지고 해당 글을 적게 되었습니다. 이번 글에서는 그 차이를 상세하게 분석해보고, 각 방식이 가지는 장점과 단점을 살펴 보겠습니다.NestJs의 Provider vs Spring의 ComponentNe..

지난 몇 년간 Spring 생태계에 익숙해져 있었던 터라 Spring에서는 로깅, 트랜잭션, 예외처리등 공통로직을 '객체'로 바라보고 비즈니스로직에서 공통로직을 별도로 분리하는 AOP(Aspect Oriented Programming) 패턴을 지원하고 있음을 알고 있었습니다. 현재 근무 중인 회사에서는 새로운 프레임워크인 NestJs를 도입했고 저는 'NestJs도 로깅, 트랜잭션 등 공통로직을 구현하기 위해서 AOP 패턴을 도입하자고 주장'했습니다. 하지만, 저는 NestJs에서 AOP 패턴을 적용하려고 하면서 계속 한 가지 의문이 들었습니다. NestJs가 AOP를 지원하고 있는 게 맞나? 내가 알던 거랑 좀 다른데? 그렇습니다. 이번 포스팅의 주제는 NestJs에서 AOP를 지원하고 있는 게 맞나?..

이번글에서는 NestJs의 Guards를 사용해서 '인증'을 구현하는 방법에 대해 정리해보려고 합니다. 가드에 대한 개념적 설명이나 NestJs의 Request Cycle에 대한 이해가 필요하신 분은 NestJs Request Cycle 해당 포스트를 참고해 주세요. Passport(Authentication) 저는 인증을 구현하기 위해서 Passport를 사용하기로 결정했습니다. Passport는 보다 구조화된 방식으로 인증을 처리하기 위한 추상화와 전략을 제공하는 인증 미들웨어입니다. (Guards는 넓은 개념에서 미들웨어에 포함됩니다.)  Passport를 굳이 사용하지 않고 인증 서비스를 구현하는 것도 물론 가능합니다. 다만, 개발 조직 내에서 Passport를 사용한 인증 구현 전략에 익숙해있을..

이번 포스팅에서는 NestJs 프레임워크에서 Client로부터 Request가 들어오고 Response가 나가기까지의 전체 Request Cycle에 대해 작성해보려고 합니다. 해당 내용은 전부 NestJS 공식문서를 참고할 수 있지만, 일부 디테일한 설명을 추가했습니다. 추가적으로 해당 포스트는 NestJs의 Request lifecycle에 대한 개념적 이해와 철학에 대한 내용을 중심으로 작성했기에 구체적인 소스코드는 포함하지 않았음을 미리 말씀드립니다. Request lifecycleNestJs에서 client의 request가 들어오고 server의 response가 나가기까지 전체 과정은 다음과 같습니다. Client Request: 클라이언트가 HTTP 요청을 보냅니다. NestJs 서버가 요..

최근 사내에서 진행한 결제 프로젝트는 NestJS라는 새로운 프레임워크를 도입해서 진행했습니다. 현재 가장 큰 문제점은 오류가 발생했을 때 그 오류를 로컬 환경에서 재현하지 않으면 오류의 원인을 명확히 알 수 없는 상황이었습니다. 물론 현재는 Sentry Report를 통해서 오류가 발생했을 때 원인을 알 수 있도록 시니어 개발자분께서 환경세팅을 해주셨지만 Sentry는 메트릭과 관련된 데이터를 모니터링하는 것에는 한계가 있었습니다.  그래서 이번 포스팅에서는 Grafana, Loki, Promtail, Prometheus를 사용해서 실시간 로그 수집과 메트릭을 모니터링해 본 경험을 공유해보려고 합니다. 아직 사내에서 정식 채택되어 사용하지는 못했지만, 지속적인 공유와 디벨롭을 통해서 가까운 미래에 사용..