개발을 처음 배웠을때 nestjs로 개발을 시작했었다. 지금 생각해보면 참으로 의아할수도 누군가는 근본없다고 할수도 있을것같다. 아니 express도 모르면서 nest로 시작했다고...? 그래서 일까? 나 스스로도 뭔가 자신이 없었다. 기본을 모르고 무언가를 시작했다는 이 느낌... 이도저도 아니게 될거같아 어차피 이렇게 된거 nest를 파보자! 그러면서 중간중간 express와 겹치는 개념 또는 express에서는 이렇게 하는데 nest에서는 다르게 하는것에 대해 공부하며 두가지를 동시에 익혀보려 한다.
express vs nest
express: 중앙에서 모든걸 통제한다(app.js). middleware로 모든것을 통제하는데 예를 들면 express.json()으로 json형식의 데이터를 입력받았을때 req객체 안에 파싱해서 넣어준다거나, express.urlencoded()로 url이 encoding되어 들어오는 데이터를 파싱해서 읽어준다. 이 외에도 morgan, cookieParser등 여러가지 셋팅들을 중앙에 셋팅한다. 그리고! process.env.NODE_ENV로 prod환경인지 dev환경인지를 구별하여 prod환경에서는 조금 무겁지만 보안설정을 더 할수도있고 dev환경에서는 개발에 용이한 세팅들을 더해줄수있다.
=> express와 nest를 비교하면 express는 뭔가 DIY같은 느낌이라면 nest는 조립이 되는 순서나 모듈을 만들어주고 그 만들어진 모듈을 합치는 느낌이다. 위에서 잠깐 설명했었는데 express는 middleware를 만들거나 import하여 그것들을 조합한다. 반면에 nest는 의존성을 주입하여 기능을 만든다.
npm: 예전에는 repo를 따로 가지고 있어야해서 하나의 repo안에서 back 과 front가 package.json을 가질때 따로따로 넣어줘야했고 공통된 부분은 또 분리해서 해줘야했다면 7 부터는 yarn에서 제공하던 mono repo기능을 제공하기 시작하여 package.json내부에 dependancy관리가 편해졌다.
nest는 요청을 받아 기능을 수행함에 있어 티어가 나뉘어져 있다. module, controller, service로 나뉘고 더 아래로 가자면 repository, entity도 있을것이다. 각각의 티어는 자신이 맡은 역할이 명확하게 나뉘어져 있다. 이제부터 간단하게 나마 각 티어별 수행하는 역할에 대해서 설명해보도록 하겠다.
Module: @Module로 선언되며 module이 하는 역할은 기능별 사용되는 컨트롤러와 서비스를 묶어 하나로 모듈화 하여 app.module에서 조립이 된다. => user기능을 만들때 비지니스 로직을 담당하는 서비스를 한데 묶고 그 서비스들을 조합하여 사용자에게 리턴값을 주는 컨트롤러를 하나의 커다란 묶음으로 만드는것이 모듈이다.
controller: @Controller라는 데코레이터로 선언하면 nest가 해당 클래스는 controller의 역할을 수행할것이다 라는것으로 인지하여 해당 클래스 안에서는 controller의 기능을 사용할수있다. 컨트롤러는 여러가지 서비스를 조합하여 원하는 기능을 유저에게 보내주는 역할을 한다. 컨트롤러를 사용자와 맡다아 있는 인터페이스라고 보면 이해가 쉬울것같다.
Service: @Injectable 이라는 데코레이터로 선언하며 nest가 해당 클래스를 주입가능한 class로 인지한다. 이렇게 인지된 클래스는 사용하고자 하는 곳에서 DI를 통해 주입되면 사용이 가능하다. => Injestable이라고 선언하면 그 클래스는 주입(클래스를 가져와 그곳에서 메소드로서 사용)이 되어 해당 클래스에서 만든 메소드들을 주입이된 다른 모듈에서 사용한다. 서비스의 기본적 기능은 비지니스 로직을 수행하는 것이다. 서비스에서 비지니스 로직을 만들고 컨트롤러에서 조립하여 유저에게 요청사항을 전달해주는 역할이다.
service를 왜 분리함? => 서비스는 business logic이 수행되는 역할을 맡아서한다. 서비스를 나눈 이유는 재사용성에 있다. 위에서 말했다 싶이 Injectable로 선언하면 해당 서비스는 어디에서든 사용이 가능한 클래스가 된다. 그래서 user에 관련한 서비스를 만들고 그걸 상품의 컨트롤러에서 사용하고 싶으면 상품 컨트롤러에 주입해주면 끝이다.
configModule => 기존 dotenv를 썻었다. nestjs에서도 사용이 불가능한것은 아니나, 이미 configModule이 dotenv의 기능을 가지고 있다. 따라서 그냥 configModule을 사용하고자 하는 모듈에넣어주고 설정하면 구지 dotenv없이도 환경변수를 읽어오는것이 가능하다. 그리고 configModule은 현재 개발 환경 ex) 개발환경인지 운영환경인지에 따라 따로 환경변수경로를 지정하는것이 가능하다.
사실 nest도 express 프레임워크 기능위에서 수행되는것이라 express로 할수있는것은 nest에서도 할수있다. 다만 express와 비교하여 nest가 좋은점은 구조나 설계적인 측면에서 잘 잡혀있다고 생각한다. 예를 들어 express는 항상 인자에 req,res,next를 받아 실행한다. 이 인자들이 없으면 요청정보도 응답정보도 그리고 next기능도 수행할수 없다는 뜻이다. 좀더 쉽게 말하자면 너무나도 강하게 결합되어 있다는 뜻이다. 이렇게 강하게 결합되어 있는것을 좀더 느슨하게 만든 구조를 nest에서 제공한다. 물론 req, res, next를 가지는 use함수를 실행시킬수도 있지만 그렇게 하지않아도 정보를 제공받아 결과를 전달해줄수있다. 처음에는 이런것들이 당연하다고 생각했지만 express로도 개발해보며 nest가 생각보다 많은 기능을 알아서 제공하고 있었구나 깨닫게 되었다. 앞으로는 nest를 공부하며 배운 내용에 대해서 공유해보도록 하겠다.
