발단
추석에 내려가서 고양이 꾹꾹이 하는거 받아주고 있는 와중에 단전에서 nestjs에 대한 욕망 끌어올랐다. 그 동안 여러 강의와 토이 프로젝트로 찍먹을 해봤고 공식 문서를 보면 고양이가 있는데 그때는 별 생각이 없었는데 우리집에 고양이를 들이고 나니 왠지 모를 동질감(?)에 빠져들었다.😁
지금 쓰는 express의 내가 생각하는 문제점
- 높은 자유도 :
서비스가 어느정도 고도화되고 라우팅도 많이 쌓이고 TDD도 달고 swagger로 주석으로 달고 이러다 보니까 조금 복잡하다. 나름대로 깃허브에 starter(보일러 플레이트)를 참고 하고 여러 레퍼런스를 참고 했는데도 불구하고 이 모양 이 꼴인거 보면 나중에 고객이 상품을 조회하는 로그까지 붙히면 난리나겠다 싶더라. 그래서 나름대로 리팩토링도하고 좀 더 가독성을 생각하고 있는대도 불구하고 높은 자유도와 실력 부족으로 코드가 등산(❔)을 할까봐 겁이 난다. 아키텍처가 조금 정해져 있다보니 다른 개발자와 소통할때도 편리하겠더라. 그렇다 나같은 놈은 좀 가둬 놓을 필요가 있겠다.
자유도를 주면 이렇게 이놈처럼 꼬질꼬질해질수도 있다.😠😡
- OOP && 타입스크립트 : 물론 지금도 객체지향적 프로그래밍을 표방해서 하고 있지만 악간 함수형이랑 짬뽕이 된 느낌을 주고 있다. 지금 가독성을 돕기 위해 route 폴더를 따로 두고 있는데 controller와 왔다가 갔다가 조금 불편하다. 그래서 express의 데코레이터 도입으로 개편할것인가? 고민중에 있다. 또한 타입스크립트 기본적으로 제공하지 않아서 초반엔 자바스크립트로 개발을 했던적이 있다. 지금은 그냥 타입스크립트를 데이터를 타입분류로만 사용하는 거 같아서 과연 내가 타입스크립트를 잘 쓰고 있나라는 의구심을 품게 한다.
뚱뚱한거 싫어 간결한게 좋아👻
- Pipe && Validation : pipe나 Validation의 이점은 서비스의 안정성과 간결성이라고 생각한다. 그러다 보니 코드가 길어지게 되고 가독성이 떨어지는 것 같다고 느끼고 있다.
이제 집에 들어가자 😾
결론
위에 나열 했던 문제점들이 물론 express 에서도 사용 할 수 있다는 것을 잘 알고 있다. 결국 내 실력의 문제인 것이고 내가 express로 개발하면서 필요하고 불편했던 부분들을 nestjs는 이미 가지고 있어서 좋아 보는 것 인거 같다. 지금 express로 다른 라이브러리나 기능을 붙혀서 사용하고 nestjs 사용해보고 싶은 욕망만 갖고 있거나 nestjs를 사용하며 내 욕망을 해결하고 다시 설계된 아키텍처에서 하고 싶은 것을 할 것이냐의 선택에 있다. nestjs로 가기에는 시간, 다른 개발자들과 상의가 필요하기 때문에 험난하다.
