노드 장점
1. js 기반 클라이언트 sdk를 백엔드에서 자동생성해줄 수 있음
이 sdk를 기반으로 msa 구조에서 js 기반 서버들끼리 통신하기도 좋음
(이건 java도 가능)
2. 나온지 5년만에 nestjs 깃헙 스타 수가 spring보다 많음(스프링 부트65k, 스프링 프레임워크50k, nestjs53k)
3. 언어적으로 장점이 많음(타스 포함)
DTO를 인터페이스로 표현 가능하고, 과도한 상속이나 패턴을 안 써도 되는 TS가 좀 더 설계에 유리함
4. 풀스택 개발할때 넘사벽으로 편함
대기 생각
1. 여러 dto를 다루기 좋고 웹 fe와 궁합도 좋아서 msa 환경에서 read 전용 서비스들의 언어로 쓰기 좋아보임
2. 그 외에는 자프링 쓰는게 좋아보임
조선은 스프링이지
스타수가 무 슨상 관
3번제외하곤 그닥 공감안되는 장점뿐
Dto 인터페이스표현 말곤 장점을 진짜 모르겠음. 삼촌이 말한 장점들 너무 하찮아
본인이 풀스택 개발자라고 생각해보면 넘사벽 장점 맞다고 생각함 근데 백엔드 개발자면 장점이 좀 애매하지
대충 맞다. 스프링도 자동화 한갈레 포함해서 나온셈이고. 다른 언어들 프레임웍들 찍먹해봤지만 아직 스프링 했던것 야금야금 포팅해가는 수준. 노드는 물론 막대한 사용자로 인해 더 발전 중인것 같은데 자바가 서버에서 C잡아 먹었듯이 자스가 자바 잡아먹을지는 미지수 ㅇㅅㅇ
새싹비빔밥 의견 메모 뭐 간단한 경량 서버 필요할때 좋은거야 다 알고 복잡한 서비스 만들때 좋았던점 하나. 처음 기획단계에서는 인터페이스 계속 변할수밖에 없는데 프론트랑 nest.js백엔드 모노레포로 관리하면서 인터페이스 공유하니까 개꿀이더라 아니면 진짜 귀찮은데말이야
그거말고는 삼촌이 말한 Typia, Teactia는 솔찍히 저것때문에 노드 쓸 이유가 1도 없어보임. 오히려 nest쓰면서 자잘하게 빡치는게 더 많은데 Nestia가 그것들을 해결해주면 그래도 쓸만할듯. 안써봐서 확신없음
더 자세히 얘기하면 dto 인터페이스들과 거기에 관련된 이넘이나 리터럴타입같은걸 모노레포 내의 별도 패키지에서 관리했음