NestJS

Express에서는 다음과 같이 CRUD를 만든다. 사실 간편하고 빠르게 서버 어플리케이션을 확장할 수 있다는 게 장점이다. 하지만 Express는 구조적으로 짜임새가 있지는 않다. 그래서 결국에는 차세대 프레임워크에게 자리를 물려줄 것으로 보인다. 이제부터 직접 두

이번 글은 짧은 내용을 다룬다. 아마 dotenv를 사용하다가 Nestjs와 ConfigModule을 사용하려던 사람들은 시행착오를 많이 겪을 것이다. 사실 TypeORM을 써서 발생하는 문제는 아닌데, 이런 상황을 주로 만나는 게 아무래도 ORM일 것 같아서 제목에도

상품의 Entity 정의해시태그의 Entity 정의hashtag도 index 번호와 text만 가지게끔 간단하게 정의가 됐습니다.이런 다대 다 관계에서, 우리는 중간에 1:n, m:1이 되도록 관계 테이블을 만들 수 있을 거에요.상품과 해시 테이블 간 관계 Entity

공식문서 상에서 AuthModule은 다음과 같은 형태로 구현된다.보다시피, AuthModule에 UsersModule을 import한 형태로 작성된다.하지만 개인적인 소감으로는, 이 방식보다는 AuthModule이 직접 User를 다루는 게 맞다고 봤다.따라서 나라면

차근차근 Nest에 대해서 설명하고자 한다. 이 글에서는 Controller와 Service, Repository를 어떻게 구분하면 좋을지를 설명한다. 당연히 각 역할대로 구분하면 된다는, 간단한 소개가 되겠지만, 그 각 역할이 뭔지 이야기 해보자.Express 유저라

서비스를 구현하다보면 당연히 여러 사용자가 존재하게 된다. 이 사용자라는 표현은, 그냥 내 임의로 부르는 호칭인데, 말하자면 유저의 성격이다. 예컨대 커머스라고 한다면 구매자와 판매자, 관리자가 있을 수 있고, 예약 서비스를 만든다면 식당 주인과 손님이라는 관계가 생길

일반적으로 Local과 JWT를 사용하여 전략을 수립하고, 그에 따라 Guard를 만든다. JWT 자체는 쉽게 decode가 가능하기는 하지만, 그걸 대비해 내부의 식별 값을 하나 더 둔다. 임의로 값을 바꿀 경우, 이 식별 값도 함께 바뀌기 때문에, Token을 만들