[TIL] 프리온보딩 마지막, 일곱 번째 과제_Cardoc

일곱 번째 과제 🔥 

이번 과제는 처음으로 혼자 진행하는 과제였다. 한 달동안 잦은 밤샘에 지쳐가던 중이었는데, 개인 과제에 기한도 일주일이나 주셔서 행복했다. 

우리 팀은 개인과제임에도 불구하고 활발하게 소통하며 과제를 진행했다.

주된 목적은 어몽어스와 캐치마인드 였지만..

시간에 쫓기지 않아도 되니, Nestjs 및 도커를 공부하면서 진행할 수 있어서 좋았다.

 

github 링크 : https://github.com/sally0226/assignment-7-cardoc

GitHub - sally0226/assignment-7-cardoc

 

1) DB 모델링 🤔 

처음에는 테이블을 두개만 두어 User와, User가 가진 자동차와 그에 따른 타이어 정보를 한 테이블에 저장하려고 했으나, trimId가 동일한 자동차는 타이어 정보가 같으므로, Cars 테이블로 만들어 동일한 컬럼들의 중복 저장을 줄이고자 했다.

• OwnedLists
  • 한 user가 동일한 trimId의 차량을 여러개 등록할 수 없도록, id + trimId 컬럼을 묶어 Unique속성을 부여

@Unique(["user", "car"])

• • Unique 속성 데코레이터 공식 문서
• Cars
  • 처음에는 폭 , 편평비, 휠 사이즈 컬럼을 두어 frontTire정보가 있으면 저장, 없으면 rearTire정보로 저장하려고 했다.
  • 하지만, frontTire와 rearTire의 규격이 다른 경우가 있을 것으로 판단되어 frontTire와 rearTire의 정보를 따로 저장할 수 있도록 컬럼의 수를 늘림
  • 하지만 아래와 같이 rearTire의 정보가 없는 case를 발견하게 되어, rearTire관련 컬럼에 nullable 속성을 주었다.

2) 인증 🤝 

지난 대부분의 과제들에도 인증 기능이 필요하여 구현했지만, 시간이 넉넉하지 않아 다른 팀원분이 이전에 nestjs로 작성해놓으신 폴더구조와 코드를 보고 베끼다시피 구현했었다. 

그래서 이번 과제를 할 때는, Nestjs 공식 문서를 꼼꼼히 보면서 이해하면서 구현했다.

공식문서를 보며 구현하니, JwtStrategy와 localStrategy가 guard를 위해 필요하다는 것을 알게 되었다.

 

guard를 만들고, 해당 guard가 필요한 곳에서 @UseGuard() 데코레이터를 사용했다.

그리고, 회원가입 성공시 바로 로그인 처리를 해주어 JWT를 발급해주는 방식을 적용했다.

 

3) 사용자가 소유한 타이어 정보를 저장하는 API 🚓 

이 API는 여러 사용자의 정보를 한 번에 요청할 수 있는 API이지만, 과제 안내 페이지에

이후의 API는 인증된 사용자만 호출할 수 있다.라는 문구가 있었기에, 로그인이 되어있는지 검사했다.

다만, 누가 로그인했는지는 신경쓰지 않았다. 

 

이 API의 res를 정하는 과정에서 많은 고민을 했다. 

Request body로 사용자 정보 + trimId 쌍을 최대 5개 까지 받을 수 있는데, 

그래서 일부는 성공하고, 일부는 실패한 경우에 어떻게 Response를 보내줄지에 대해 고민이 되었다.

 

1. 한 개라도 실패하면 Error Res

2. 한 개라도 성공하면 200 Res, 대신에 안에 배열로 메세지 적어 보내기 

중에 고민을 했는데, 1번 방법은 비효율적이라는 생각이 들었다.

가능한 항목에 대해서는 최대한 처리해주는게 좋을 것 같았기 때문이다.

따라서 1개라도 성공하면 200으로 Response를 보내되 메세지로 실패한 경우를 나타내주었다. 

[예시]

• 한 개라도 성공한 경우
  • 성공한 경우는 생성된 id와 trimId쌍이,

    [
        {
            "id": "bada1",
            "trimId": 5
        },
        "중복된 정보입니다.",
        "존재하지 않는 user입니다."
    ]

  • 실패한 경우에는 해당 case에 대한 error message가 들어있다.
  • 200과 함께 배열이 Response된다.
• 전부 실패한 경우

  {
      "statusCode": 400,
      "message": [
          "중복된 정보입니다.",
          "존재하지 않는 user입니다."
      ],
      "path": "/owned-lists"
  }

  • 400과 함께 메세지가 배열형태로 Response된다.
  • 각 항목마다 실패한 이유가 다를 수 있기 때문에 메세지를 배열형태로 전송했다. 

다만, DTO가 한 개라도 어긋났을 때에는 바로 400이 Response된다.

Nestjs가 DTO가 어긋났을 때, 어떻게 Error Handle을 하는지 더 공부할 수 있는 시간이 있었으면 좋았을 것 같다.

다음엔 이 부분을 공부해볼 것이다.

{
    "statusCode": 400,
    "message": [
        "list.1.id should not be empty",
        "list.1.id must be a string"
    ],
    "path": "/owned-lists"
}

 

4) 자동차 정보 조회 API의 사용 🏎️

[API 호출]

자동자 정보 조회 API를 호출하기 위해 axios의 HttpService를 이용했다.

비동기로 처리되는 API호출이 완료될 때 까지 기다릴 필요가 있었는데, return type이 Promise가 아니라 Observable이었기 때문에 바로 await를 사용할 수 없었다.

이를 해결하기 위해 rjax의 lastValueFrom 함수를 사용했다. 이 함수는 Observable를 Promise로 바꿔주며 함수 이름이 뜻하는 바와 같게 마지막 value를 return해준다.

 

지난 휴먼스케이프의 과제에서 외부 API 호출이 필요했었기 때문에, 어렵지 않게 구현할 수 있었다. 

axios말고, @nestjs/common에서 제공하는 HttpService도 있어서 지난 과제에서 이것을 이용하려고 했는데, 

"HttpModule" (from the "@nestjs/common" package) is deprecated and will be removed in the next major release. Please, use the "@nestjs/axios" package instead.
(대충 이제 이거 지원안하니까 axios 쓰라는 얘기)

이런 메세지가 떴기 때문에 axios를 설치해 이용했다. 

[정규식 이용]

또한, frontTire/rearTire.value가 205/75R18와 같이 하나의 string안에 폭, 편평비, 휠 사이즈가 모두 포함되어 있는 형태였다. 

따라서 주어진 string을 /와 R로 split해주어야 했는데, 정규식을 작성하여 한 번의 split함수로 [폭, 편평비, 휠 사이즈]를 구할 수 있도록 했다.

 

이번 과제를 통해 정규식에는 "(따옴표)를 붙이지 않는다는 것을 알게되었다. 

이걸 모르고 따옴표를 붙인 채로 왜 안되지? 하다가 나중에 알게되었다..

const frontInfo = frontTire ? frontTire.split(/R|\//) : null;

[nullable]

Cars 엔티티 모델링에서도 설명한 내용이지만,

frontTire와 rearTire의 정보를 각각 저장하는데, rearTire가 정보가 없는 경우가 있기 때문에, 그런 경우에는 null이 들어갈 수 있도록 해주었다.

frontTire, rearTire 모두 null → error

둘 중에 하나만 null → 통과 후 해당 컬럼값이 null로 저장되도록 처리

 

carService내의 자동차 정보 조회 API를 호출하는 함수 링크

async getCarInfo(trimId: number) {
    const url = `https://dev.mycar.cardoc.co.kr/v1/trim/${trimId}`;
    try {
        const responseData = await lastValueFrom(
            this.httpService
            .get(url)
            .pipe(map((response) => response.data?.spec?.driving))
        );
        const frontTire = responseData.frontTire?.value;
        const rearTire  = responseData.rearTire?.value;
        if (!frontTire && !rearTire) return null;
        const frontInfo = frontTire ? frontTire.split(/R|\//) : null;
        const rearInfo  = rearTire  ? rearTire.split(/R|\//)  : null;
        const result = await this.carsRepository.createOne(
            trimId, 
            frontInfo, 
            rearInfo
        );
        return result;
    } catch (error) {
        return null;
    }
}

 

5) HTTP Status Code ⛳

각 API의 status code는 과제 안내 페이지에 따라 200, 400, 401, 500으로 구성했다.

 

400의 경우, error의 이유가 다양하므로 error message를 다르게 넣어주었다.

ex) 회원가입 시 중복 가입의 경우, DTO가 안 맞는 경우 등..

// 중복 가입시
{
    "statusCode": 400,
    "message": "중복된 id입니다.",
    "path": "/users/signup"
}

// DTO와 맞지 않을 때
{
    "statusCode": 400,
    "message": [
        "id should not be empty",
        "id must be a string"
    ],
    "path": "/users/signup"
}

 

6) Exception 처리 🚫

지난 과제들에서도 Exception 처리 기능을 구현했었다. 하지만 Nestjs를 잘 모르는 상태여서 다른 팀원이 해 놓은 방식을 그대로 이용했다. 다만 그 구조가 파일이 많이 필요하고 복잡해서, 더 간단한 방법이 존재하지 않을까 생각했다. 

다른 팀원들도 나와 같은 생각을 해서, 나중에 공부해보자고 이야기를 나눴었는데 이번 과제를 통해 더 나은 방법을 찾을 수 있었다.

 

답은 역시 공식문서에 있었다. Nestjs 공식문서를 통해 구현했으며, 필요한 부분을 수정했다.

 

특히 message변수를 수정했다.

보통의 경우에는 exception.message에 string 형태의 message가 들어있는데,

DTO관련 error와 같이 error message가 1개 이상으로 배열 형태로 존재할때,

exception.message 에는 포괄적인 메세지만 들어있고,

자세한 메세지들은 exception.getResponse()["message"]에 존재했기 때문이다.

@Catch(HttpException)
export class HttpExceptionFilter implements ExceptionFilter {
	catch(exception: HttpException, host: ArgumentsHost) {
		const ctx = host.switchToHttp();
		const response = ctx.getResponse<Response>();
		const request = ctx.getRequest<Request>();
		const status = exception.getStatus();
		const message = exception.getResponse()["message"] || exception.message;
		response.status(status).json({
			statusCode: status,
			message,
			path: request.url
		});
	}
}

 

7) Docker를 이용한 배포 🐳

인공지능 스타트업에서 인턴을 할 때, Docker를 처음 접했다. 직접 image를 빌드한건 아니었고, 빌드된 이미지 여러개를 실행시켜보고, 실행중인 컨테이너에 접속해 파일목록을 보는 정도의 작업만 수행했다. 

한 대의 컴퓨터에서 독립적인 환경을 만들어 이용해 서로 충돌이 일어나지 않게 하는 점이 매력적이었고, 차이점이 있긴 하지만, 아나콘다의 가상환경과 비슷한 개념이라는 생각도 들었다. 

내 서버에서 실행되고 있는 2개의 도커들! 🐳

[MySQL]

docker hub에서 latest버전의 image를 다운받아 컨테이너를 생성 및 실행했다.

[Nestjs 서버]

• v12의 node image를 이용
  • 개발시 이용한 버전은 v14.x.x 였지만, docker image들 가장 최신 LTS인 v12를 사용해보았는데, 버전 차이에 따른 별다른 에러가 발생하지 않아 그냥 v12 image를 이용했다. 
  • 추후에 docker의 node image들에 대해서도 알아볼 예정이다.
• 안정적인 백그라운드 실행을 위해 pm2를 이용
  • 그냥 pm2가 아닌 도커에 적합한 pm2-runtime 명령어를 이용
• --output option을 이용해, 특정 위치에 log파일이 생길 수 있도록 처리

최종적으로, 아래와 같은 Dockerfile을 작성하여 이용

From node:12

# 앱 디렉토리 생성
WORKDIR /usr/src/app

COPY package*.json /usr/src/app/
RUN npm install
RUN npm install -g pm2
COPY . /usr/src/app/

RUN npm run build

EXPOSE 3000

CMD ["pm2-runtime", "start", "dist/main.js", "-i", "max", "--output", "/home/contents/log/main_out.log"]

# 환경변수 설정

# DATABASE
ENV MYSQL_HOST ...
ENV MYSQL_USERNAME ...
ENV MYSQL_PASSWORD ...
ENV MYSQL_DATABASE ...

# JWT
ENV JWT_SECRET_KEY ...

 

이번 과제를 통해 처음으로 직접 Docker image를 빌드해보았다.

image를 빌드하는 과정에서 굉장히 탈이 많았으나,, 여러 번의 시행착오 끝에 성공하게 되어 굉장히 행복했다.

1. COPY . . 안되는 문제
   1. WORKDIR 명령어로 폴더를 지정해준 후, COPY . .를 해주면 해당 폴더에 카피가 되는 줄 알았는데, 되지 않아서 . 대신에 절대경로를 적어주었다.
2. pm2 실행 후 log를 확인할 수 없던 문제
   1. pm2 monit을 이용해 실시간으로 생기는 log를 확인할 수는 있었지만, 이전에 생성된 log들을 확인할 수 없었다.
   2. pm2-runtime으로 실행하니 defalut로 clustor가 2개 생성되어서 그런지 pm2 logs [이름]으로 log를 확인할 수가 없었다. 
      1. 따라서, pm2-rumtime 명령어를 실행할 때 --output명령어로 log경로를 지정해주었다. 이렇게 하니 해당 경로에 log파일이 생겨서 지난 log들을 정상적으로 확인할 수 있었다.

 

소감 열 마디 🌙

시작부분에도 적었지만, 프리온보딩 코스에서 처음이자 마지막인 개인과제였다. 

한 달동안 2박3일도 안되는 기한으로 6개의 과제들을 몰아치듯이 수행하면서, 

협업 방식이나, 기술적인 면에서도 많이 성장했지만 내가 배운것들을 소화시키지 못하고 꾸역꾸역 밀어 넣는 느낌이 들 때가 있었다.

이렇게 마지막 과제를 개인과제로 하면서, 그 동안 배웠던 것들을 천천히 정리하고, 공부하면서 돌아볼 수 있는 시간이 되어 참 좋았다. 

프리온보딩 코스 전반에 대한 후기는 나중에 따로 포스팅으로 남길 예정이다.

 

이 과제에 대해 더 얘기해보자면, 

Docker를 이용해 배포해볼 수 있어 좋았다. Docker 써봤다! nestjs를 Docker로 배포할 수 있다! 라는 역량 한 줄이 생겼기 때문이다. 

그리고, 이전부터 느끼던거지만 Nestjs랑 Spring이랑 비슷한 점이 많은 것 같다. 의존성 주입 및 데코레이터 등등..

다만 Spring을 겉핥기식으로만 배워서, 정확히 두 프레임워크가 어떻게 비슷하고, 어떻게 다른지 공부해봐야겠다는 생각이 들었다. 

 

끝!