프론트엔드 개발자가 배운 Nest.js - ep.1

Nest.js를 배우려는 이유

1. 웹 개발자로서 혼자 웹사이트를 만들줄은 알아야지 라고 생각했다. 그래서 얕게나마 백엔드 웹 프레임워크 하나 정도는 언젠가 배워야겠다고 생각을 했었다. 새로운 프레임워크들이 계속 나오겠지만, 하나만 잡고 평생 써먹으리라.. 하는 가성비 좋은 생각!
2. 굳이 백엔드를 배우지 않더라도 대체할 수 있는 플랫폼이나 툴이 많지만 항상 미지의 영역이라고 생각했던 부분을 직접 파헤져 보고 싶었다. "대체 JWT는 어떻게 만들어서 나에게 주는 것인가!?"
3. JS에 익숙한 상태였기 때문에 node를 기반의 프레임워크를 선택하고자 했다. express를 선택하지 않은 이유는 nest가 express에 비해 더 자율성이 더 적은 것 같았다. 자율성이 크면 클수록 초심자인 내 입장에서는 배우는데 시간이 더 오래 걸릴 것 같았다. 또한 회사 프로젝트는 스프링으로 구축이 되어 있는데 nest.js가 스프링과 흡사하다는 여러 의견도 선택의 이유가 되었다. 스프링은 아니지만 백엔드 팀원들과의 커뮤니케이션에 손톱만큼의 도움이라도 될까 싶었다.

어떻게 공부할까?

1. 공식문서도 있고, 책도 있고, 강의도 있었는데 강의가 제일 효율적인 것 같다고 생각했다. 전~혀 모르기때문에 구글에서 찾은 파편화된 정보를 이어 붙이고 확인하고 하는 시간에 차라리 더 공부하자. 하는 생각이었다.
2. 강의는 노마드코더의 우버잇츠 클론코딩으로 정했다. 여러 강의를 봤지만, 강의가 나에게 개인적으로 잘 맞는 편이고 더불어 백/프가 모두 있는 강의이기때문에 겸사 겸사 리액트도 더 공부할 수 있는 강의이다.
3. 강의 커리큘럼 진행하면서 우버잇츠 클론 프로젝트를 진행한다. 근데 경험상 강의만 보면 따라치게 되기때문에 별로 남는게 없다. 위장 지식만 가득해질뿐! 그래서 호기롭게 바로 회사 동료들과 백엔드 포지션으로 사이드 프로젝트를 시작해버렸다. 이제 죽이되든 밥이되든 해야한다.

무엇을 공부할까?

1. 일단 프레임워크는 nestjs! 그리고 DB는 postgresql, 그리고 프론트에서도 직접 사용할 일이 없어 써보지 못한 graphql로 만든다! 그리고 나중에 언급하겠지만, SQL을 쓰지 않고 타입스크립트로 SQL 명령을 내려주는 (오메..) ORM은 typeORM을 사용한다. (이 표현들이 맞는지 모르겠지만, 아직 배우고 있는 중이라...적절하지 못한 표현일수도 있습니다. 😅)
2. 그리고 배포는....! 노마드코더 강의에서는 heroku를 통해서 진행하는데, 이왕 시작하는거 한번 더 해보자 하는 생각에 항상 말로만 듣던 로드밸런서.. ec2, RDB 이런 것도 사용해보기 위해 aws beanstalk을 사용해보려고 한다. 사실 프론트엔드 배포를 vercel과 같은 플랫폼을 이용해왔어서 aws에 대해 아는게 없다.. 🤔 그래서 과감하게 프론트엔드 배포도 vercel이 아닌 nginx를 띄우고 그 안에서 배포를 하고 이 과정에서 Docker도 사용해보고.. Travis CI 도 이용해서 배포 자동화까지 구축하는게 목표다.
3. 그리고 아직 한번도 시도해보지 못한 테스트코드도 이번 공부 계획에 포함했다. 백엔드 테스트코드까지는 조금 버거울 것(변명..) 같아서 프론트엔드 테스트코드부터 중점적으로 해보려고 한다. jest와 cypress를 배워보자!

첫 날 느낌

1. 노마드코더 우버잇츠가 나름 "고급" 강의였다. 그래서 강의를 껐다. 일단 nest.js의 기본 강의를 수강했다. Controller, Entity, DTO, Service, Repository 등 생소한 용어들이 마구 나오기 시작했다. 리액트 훅을 처음 들은 느낌이랄까. Component, Props, State 를 처음 들었을 때 느꼈던 그 느낌을 오래만에 다시 느꼈다.
2. nestjs는 굉장히 견고했고, 무척 타이트했다. 개발하는 방식이 딱딱 정해져있어서 그 방식만을 따라가야했다. 그래서 굉장히 만족스러웠다. Repository 패턴을 적용하면서 Controller, Service, Repository의 목적을 알게 됐고 또한 목적에 맞게 퍼즐 맞춰지듯이 코드가 착착 정리가 됐다.
3. 이러한 패턴으로 코딩을 지속하면서 "리액트가 굉장히 자유분방했구나" 하는 다시금 생각이 들었다. 가령 리액트에서는 컴포넌트 하나를 만들더라도 방법이 굉장히 많아서 항상 고민을 하게 된다. 컴포넌트의 상태값은 어떻게 분리하는게 좋을지, 서버로부터 데이터는 어떤식으로 fetching을 하고 어떻게 관리를 하는게 좋을지.. 등. 어쩌면 Controller, Service, Repository 들의 역할이 리액트 컴포넌트에서도 같은 구조를 가질 수도 있지 않을까 하는 생각이 문득 들었다. 정말 아주 문득 든 생각이라 사실 아직 구체화는 되진 않았다.
4. 클래스의 향연이었다. 리액트에서는 함수 컴포넌트를 주로 쓰게 되면서 클래스를 쓸 일이 거의 없었다. 사실 프레임워크이다보니 클래스를 클래스로 쓰는게 아니라 "그렇게 써야해" 라고 해서 아직 클래스 자체의 장점을 몸소 느끼진 못했지만 어찌됐건 컴포넌트 만들듯이 클래스를 만들고 있는건 사실이니까. 이전보다 클래스와 많이 친해졌다. Service에서는 주로 Repository를 통해 DB에서 가져온 데이터(값)를 가공하고 반환하는 로직이 많이 들어있는 것 같았다. 리액트에서도 서버에서 가져온 값을 가공하거나 처리하기 위해 로직들이 필요한데 그럴 때 클래스를 써볼까? 하는 생각이 들었다. 물론 커스텀훅이나 또는 전역상태관리쪽에 그 로직들을 담을 수 있어서 굳이 클래스까지 거칠 필요가 있나? 싶은 생각도 같이 들었지만 그 로직을 다시 클래스로 담아서 처리한다면? 하는 생각이 들어서 곧 한번 해보려고 한다.

다음 이야기

1. nest 기초 강의를 끝내고 다시 우버잇츠로 돌아오다. 근데 graphql이 다시 새롭다. 갑자기 튀어나온 Resolver..!
2. Entity? DTO?
3. 모듈? 다이나믹 모듈..?