스프링에 비해서 너무나도 부족하고,
메타데이터 만드는 데코레이터 (자바의 어노테이션)도 정말 있는 게 거의 없는 수준임.
직접 커스텀으로 만들어야 할 정도다.
DI, AOP 개념은 있지만 스프링처럼 지능적인 건 아니다.
imports 개념하고 참조 개념이 있어서 처음에 모듈을 imports 했으면
다음에는 참조를 해야 한다. 이걸 무시하면 각종 오류(순환 참조 오류라던지)가 난다.
이 참조라는 개념은 C/C++ 을 공부했던 사람이 아니라면 이해 못할 수 있음.
근데 CLI가 빵빵해서 단순 CRUD 만드는 건, 정말 최강인 듯 싶다.
걍 nest g res <이름> 이걸 치면 dto, controller, service, provider 등이 알아서 생성된다.
뭐, 이런 기능은 루비 온 레일즈나 요즘 프레임워크들은 다 있지만.
일단 정보가 너무 없음.
그냥 사막과도 같음.
사막에서 오아시스 찾기 힘든 것처럼 공식 문서의 설명은 그저 튜토리얼 수준임.
즉, 실제 서비스에서 써먹을 만한 코드는 제로에 가까움.
이걸 쓰는 사람들은 이미 Express의 달인이거나 다양한 프레임워크의 경험이 있는 사람이 대상이여야 함.
그리고 이게 Express 기반이라서 결국에는 Express를 먼저 배우고 Nest.js를 배워야 한다.
근데 부가적인 기능이 많다.
레디스나 웹소켓 등 마이크로서버 만드는 데는 좋은 기능을 많이 제공한다.
다만 매뉴얼이 부족하고, 평소 스타일이 구글에서 남 코드를 긁어서 코딩하는 스타일이었다면
이건 절대 쓰지 못한다..
대부분 직접 개발해야 하고 생각해내야 한다.
그 이유는 정보가 너무 없어서 쓸만한 샘플 코드 자체가 거의 없다.
오류 터지면 스스로 해결해야 한다.
Express 기반의 소스 코드를 그대로 긁어온다고 작동하진 않아서 바꾸기도 해야 하고,
문제 터지면 대체적으로 구글에 영어로 검색해도 해결법이 나오지도 않음.
Nest.js 디스코드 여기에 질문하거나 하루 종일 디버깅 해가면서 문제점을 알아서 찾아야 됨.
진짜 아직은 시기 상조임.
직접 써보고 느끼는 거임.
자바 쓰는덴 다 이유가 있다 ㄹㅇ;
메인 서버는 자바로 짜고
특정 서비스 붙이는덴 쓸모있을듯
결론은 능숙해지면 그만큼 유연하고 빠른다는거로 이해되는데