질문주셔서 감사합니다. 질문은 언제나 환영입니다 ^^ 1. 어.. 일단 제가 vim lazy 패키지 자동 구성이 뭔지 잘 모릅니다. 전 vsc만 사용해서..^^;; 2. Nest개발팀은 순환참조를 허용하는 쪽으로 기능을 구현했으니까 한 모듈에 모두 포함시키는 쪽으로 만들었는지도 모르겠네요. 3. 그런데 Nest가 제공하는 순환참조 해결 방법이 저는 좀 복잡하게 느껴집니다. 또 기능적으로 허용이 된다고 해서 그게 바람직한 방법인지도 의문이구요. 4. 아마 프로젝트가 커지면 순환참조 문제가 너무 복잡해져서 발목을 잡을지도 모릅니다. 5. 그런 위험을 사전에 피할 수 있는 아키텍처가 있다면 그 아키텍처를 따르는 게 더 우선이라고 판단했습니다. 6. 그리고 MSA 구조로 가면 다시 controller가 각 모듈에 포함되게 됩니다. 물론 이 controller는 기존 controller와 이름만 같을 뿐이지만요. 서로의 글에서 생략된 부분들이 많이 있어서 충분한 답이 되지는 못하겠지만 하여튼 그렇습니다. ^^ 힘내세요!
nest-seed 개발 환경 소개를 안 할 수는 없어서 업로드를 했습니다만 특별한 내용은 없고 평범한 개발환경 소개입니다. 개발환경이 몹시 궁금한 개발자 님만 시청해 주세요. 😭
* 음성이 작게 녹음된 것을 뒤늦게 발견했습니다. 불편을 드려서 죄송합니다.
와우 이렇게 깔끔하게 정리된 dev container는 처음보네요 감사합니다.
좋게 말씀해 주셔서 감사합니다. 그런데 자세히 보시면 정리되지 않은 코드가 제법 있습니다... ^^;;
저도 외주환경같은 구성에서 자주사용하는 시드를 구현했었는데(저는 스타터팩이라고 정의했어요 ㅋㅋ)
순환참조로인해 nest의 기본 피쳐를 변경해서 레이어드로 변경하는건 새롭네요 개발자들의 학습비용,프레임워크 일관성이(nest 기본지원 ,커뮤니티문서등) 없어지는 단점에 비해 레이어드 아키텍쳐를 사용할때의 순환참조를 해결하는 이점이 더 높다고 생각하신거죠?
저는 vsc말구 vim lazy퍄키지 자동으로 구성해주는 스크립트작성해서 환경을 구성해주고있어요
질문주셔서 감사합니다. 질문은 언제나 환영입니다 ^^
1. 어.. 일단 제가 vim lazy 패키지 자동 구성이 뭔지 잘 모릅니다. 전 vsc만 사용해서..^^;;
2. Nest개발팀은 순환참조를 허용하는 쪽으로 기능을 구현했으니까 한 모듈에 모두 포함시키는 쪽으로 만들었는지도 모르겠네요.
3. 그런데 Nest가 제공하는 순환참조 해결 방법이 저는 좀 복잡하게 느껴집니다. 또 기능적으로 허용이 된다고 해서 그게 바람직한 방법인지도 의문이구요.
4. 아마 프로젝트가 커지면 순환참조 문제가 너무 복잡해져서 발목을 잡을지도 모릅니다.
5. 그런 위험을 사전에 피할 수 있는 아키텍처가 있다면 그 아키텍처를 따르는 게 더 우선이라고 판단했습니다.
6. 그리고 MSA 구조로 가면 다시 controller가 각 모듈에 포함되게 됩니다. 물론 이 controller는 기존 controller와 이름만 같을 뿐이지만요.
서로의 글에서 생략된 부분들이 많이 있어서 충분한 답이 되지는 못하겠지만 하여튼 그렇습니다. ^^
힘내세요!