유동

다른 프레임워크에서는 어떻게 validation을 처리할까?nestjs와 같은 프레임워크에서는 class-validator & class-transformer를 통해 값에 대한 validation을 진행합니다. 프레임워크 자체가 객체지향을 지향하고 있고, swagger를 사용하기 위해서(swagger decorator) dto 또는 entity를 클래스로 정의해야 하죠. (interface같은 타입들은 런타임 시 사라지기때문에 데코레이터를 적용할수가 없습니다)class-validator같은 라이브러리를 사용하지 않는 이유하지만 express에서는 프레임워크 자체가 함수형을 추구하고있기도 하고, 저 자체도 클래스를 필요 이상으로 만드는걸 선호하지 않습니다.다들 아시다시피 class는 상태를 내포하고있습니다..

이번 프로젝트에서 typedi를 이용해서 express/prisma 환경에서 레이어드 아키텍처를 적용했습니다.레이어드 아키텍쳐가 무엇이고, 왜사용하는지는 저번 글에서 다루었습니다만 [NodeJS] Express + Inversify DI (3 layerd architecture)예전 글이기도 하고, 부족한 부분이 많은것같아 다시한번 간단하게 설명하겠습니다.간단하게 말하자면 한 함수 (또는 메서드)에서 모든 로직을 처리하는것이 아니라 (app.use에서 모든로직 처리하는 그거) 역할별로 관심사를 나누자는 모토로 나온 개념입니다.웬만한 REST-API 백엔드 어플리케이션에서의 요청 흐름을 간단하게 그려보았습니다.서버에서는 클라이언트의 요청을 받아 적절한 응답을 내려줍니다. 응답을 내려주기까지 수많은 작업들이..

Express + Inversify 를 이용한 Dependency Injection 구현 소개 Express에서 layered architecture를 적용하여 사용된 라이브러리 or 프레임워크 Node.js Express.js Typescript Inversify Typeorm + pg layerd archutecture를 적용해야하는 이유는 무엇인가? 1. 각 레이어 별 관심사를 분리하기 위해 2. 변경과 확장에 용이하기 때문 3. 테스트에 용이하기 때문 관심사의 분리(separation of concerns, SoC) 나누어진 각 계층은 관심사가 존재한다 각 계층은 다른 레이어를 신경 쓰지 않고 자신의 관심사만 집중한다 계층 별로 결합도를 낮추면(DI를 이용하여) 변경과 확장에 용이해진다 각 계층별..

express 라우트 핸들러에서 아래와같이 error를 던지면 우리가 미리 global error handler를 정의해놨다면 middleware 안에서 에러를 던지면 자동으로 저기로 쏙 들어가서 에러 핸들러에서 정의해놓은 내용에 따라 에러를 클라이언트에 전달해준다. 하지만 비동기함수 내에서 error를 던진다면 어떻게될까? Error: 비동기함수 안에서 error 던집니다잇 at /Users/yoodongseon/Desktop/티스토리/index.ts:10:9 at Generator.next () at /Users/yoodongseon/Desktop/티스토리/index.ts:8:71 at new Promise () at __awaiter (/Users/yoodongseon/Desktop/..