Express의 단점과 해결방법

Express

NodeJS 애플리케이션으로 들어오는 request의 메서드, uri, 헤더 등을 읽고 그에 맞는 응답을 쉽게 처리 할 수 있는 웹 서버 프레임워크

기능이 안정적이고 유연하며, 확장성이 좋다

 

 

 

Express의 한계

- Promise 미지원

자바스크립트에서 Promise가 정식 도입되기 전 부터 존재한 프레임워크이기 때문에 비동기 처리를 콜백 방식으로만 처리할 수 있다

때문에 로직의 비동기 결과를 Express 미들웨어에 맞게 처리해주는 wrapper (혹은 interceptor) 함수를 작성해야 안전하게 request를 처리할 수 있다

 

- request 타입 검증

Express는 바닐라 자바스크립트를 기반으로 작동하며, request로 들어온 값에 대해 별도의 타입 검증을 하지 않는다

이에대해 사람이 직접 밸리데이션을 처리해야하는 단점이 존재한다

 

- 문서화

Express는 자유도가 매우 높기 때문에 API 라우터를 어떻게 작성하고 사용해야하는지 정해진 것이 없다

때문에 request 정보를 어떻게 사용하고 응답할지는 온전히 개발자에게 달려있다

이로인해 swagger 같은 도구로 문서화를 하면 데이터 타입이 바뀔때마다 일일이 사람이 고쳐줘야 한다는 단점이 있다

 

 

 

 

 

NestJS

Express의 부족한 부분들을 완벽하게 채울 수 있는 프레임워크

Spring과 같은 프레임워크를 지향하기 때문에 정해진 파일 구조나 제시된 기술 스택을 따라 개발하지 않으면 어려움이 발생한다

운영중인 프로젝트의 규모가 크다면 Nest에 맞는 구조로 갈아 엎는 것은 아주 부담스러운 작업이 된다

 

 

 

 

TSOA (TypeScript Open API)

특정 방식으로 작성된 컨트롤러 코드를 정적 분석해 openAPI 스펙에 맞게 express 등 http 라이브러리에 대응하는 코드로 빌드해주는 라이브러리

Nest의 경우 requst 밸리데이션, API 문서화 등의 기능을 사용하려면 서드파티 패키지들을 데코레이터로 호출해야한다

때문에 Express에서 전환할 경우 프로젝트 전체 구조가 바뀌어야 한다는 단점이 존재한다

TSOA는 프로젝트의 구조를 바꿀 필요도 없고 강제되는 서드파티 패키지들도 거의 없다

컨트롤러 클래스를 TSOA에서 요구하는 방법대로 작성하고 작성한 컨트롤러 파일이 프로젝트의 어느 경로에 위치하는지 등의 정보를 설정 파일로 잘 정의해주면 된다

TSOA는 런타임에서의 타입 괴리를 해결하기 위해 컨트롤러 코드, 컨트롤러가 참조하는 타입 파일들을 읽어서 소스코드를 파싱해 그 결과를 런타임에도 읽을 수 있는 코드로 변환한다

이때 타입뿐만 아니라 주석까지도 파싱한다

 

 

 

 

 

결론

프로젝트의 규모가 작다면 NestJS로 전환하는 편이 낫고

프로젝트의 규모가 크다면 TSOA로 전환하고 API가 마이크로 서비스화가 됐을때 NestJS로 전환하는 것이 낫다

 

 

 

 

 

 

Reference

TSOA로 HTTP API 개발하기 | 비브로스 기술 블로그