Naweke - 1차 프로젝트 전체 회고 - 3. API 제작 및 배포

[이전글]

1. Naweke - 1차 프로젝트 전체 회고 - 1. 기획

2. Naweke - 1차 프로젝트 전체 회고 - 2. DB Modeling

 

 

3. 엔드포인트 작성

우리 팀은 레이어드 아키텍쳐 패턴으로 API를 controller, service, modal로 나누어 제작했고,

내가 맡은 엔드포인트는 총 5개였다.

 

3.1. Auth API

Auth 부분에서는 Signup API(post)와 Login API(POST), Tokenvalidate(middleware)를 개발했다.

 

코드를 작성하면서 잘 했다고 생각하는 점은, 회원가입 이후 바로 로그인이 되도록 토큰을 발급하는 로직으로 회원가입 API를 제작했다는 것이다. 유저의 입장에서 회원가입을 한다는 것은 로그인이 필요하기 때문일 것이고, 회원가입 후 직접 다시 로그인을 한다는 것이 사소하지만 꽤 불편할 것으로 생각했기 때문이다.

 

새롭게 배웠던 점은 jwt토큰을 생성할 때 나는 claim과 payload를 별도의 변수에 담아서 생성했었는데,

그럴 필요 없이 jwt.sign 메소드 안에 직접 담아서 만들 수 있다는 점이었다.

하지만 이런 방식은 불필요하게 코드를 늘리기만 했고, 메소드를 효율적으로 활용하는 방법이 아니었다.

프로젝트 도중 sign 메소드의 세번째 인자(options)에 원하는 claim을 객체 형태로 담을 수 있다는 것을 알게 되었고,

sign 메소드의 공식 문서를 참고하여 코드를 리펙토링했다.

 

3.2 Products 상세 정보 API (GET)

products 부분에서는 상품의 상세페이지에 필요한 정보를 전달해주는 API를 제작했다.

Model Layer에서 작성해야 하는 raw 쿼리문 작성이 까다롭게 느껴졌지만 차근차근 구글링을 통해 필요한 기능을 구현할 수 있었다.

 

구현하는 과정에서 새롭게 배운 것은 쿼리문에서 '상품 상세 설명'에 대한 alias를 'desc'로 작성했었는데 mysql syntex 오류가 났었다.  mysql에 desc라는 예약어가 있어서 났던 오류였다. 그래서 alias를 다르게 주어 오류를 피할 수 있었다. 이외에도 Subquery, JSON_ARRAYAGG, JSON_OBJECT 등 익숙하지 않았던 query들을 작성하면서 조금 더 익숙해질 수 있는 시간이 되었다.

 

구현하는 과정에서 아쉬웠던 점은 예상치 못한 수정&변경사항이 생겨나며 pr이 merge되었음에도 두 번 이상의 새로운 pr을 만들기도 하면서 api 개발 속도가 늦어지게 되었다. 문제는 간단했다. 개발 과정에서 발생할 수 있는 변경사항에 대해 꼼꼼히 기록해놓고 있지 않아서였다. 개발 정도에 따라 추후에 요청 데이터가 추가될 수 있고 그에 따라 API가 수정될 수 있다는 사실을 알고 있었지만, 기록되어 있지 않았기 때문에 그 사실을 잊은채 프론트와 백엔드 통신 과정에서야 코드 수정이 깜빡했다는 것을 인지하고 코드를 수정하기도 했다.

2차 프로젝트에서는 프로젝트 진행 관련 히스토리를 꾸준히 업데이트해서 팀원들과 공유하고 놓치는 일을 최소화해야겠다.

 

그리고, 뒤늦게 회고를 하면서 발견한 것인데 쿼리문의 indent가 가독성이 좋지 않게 되어있었다.

쿼리문 indent나 작성 규칙들에 대해 공부하고 정리하는 시간을 따로 가져봐야겠다.

 

3.3 Orders API

Order API에서는 상품 주문을 생성하고(POST) 유저의 주문내역을 불러오는(GET) API를 작성했다.

Order를 POST 하는 API에서는 새롭게 배웠던 점은 Transaction이라는 개념을 알게 되었다.

Transaction이란 데이터베이스의 상태를 변화시키는 하나의 작업단위를 의미하는데, 작업자의 의도에 따라 INSERT, UPDATE등의 쿼리를 하나의 작업단위로 묶어 실행할 수 있다.

이런 트랜젝션의 개념은 말 그대로 여러 쿼리를 하나의 작업단위로 처리하기 위해 쓰이는데,

예를들면, 내가 작성한 주문을 예로 들 수 있다.

보통 유저는 상품 주문을 위해 주문서 작성 -> 결제 -> 주문완료의 과정을 거치는데, 이때 데이터베이스에는 보다 복잡한 작업이 수행된다.

먼저, 유저가 주문서를 작성하면 DB에는 order table에 새로운 order가 입력되고 order_items table에 해당 주문에 유저가 주문한 상품들의 정보가 입력된다. 그 이후에는 상품 주문 수량만큼 재고가 update되고, 유저의 카트에 담긴 상품 중 주문한 상품의 정보는 Delete된다. 이후 결제 과정이 완료되면 주문이 완료된다. 그런데 이 일련의 과정은 "유저가 상품을 주문하는 하나의 과정"으로 하나의 작업단위로 처리되어야 한다.

이 과정을 트렌젝션으로 묶어주지 않으면 유저가 주문서를 작성하고 결제 과정에서 이탈하더라도 DB에는 주문 내역이 남게 되어 문제가 된다. 이런 문제를 막기 위해 이 과정을 트렌젝션으로 묶어주게 되면, 중간에 유저가 이탈하거나 주문 과정에서 오류가 발생하더라도 DB는 해당 주문 내역을 남기지 않고 해당 작업이 실행되기 이전으로 상태를 rollback 시킨다. 만약 하나로 묶인 트렌젝션이 성공적으로 끝났을 때 commit하여 작업 내용을 한번에 DB에 반영할 수 있다.

 

order create api(post)

 

 

4. 배포

api 완료 후에는 aws ec2에 api 서버를 배포했고, rds에는 database를 배포하여 웹서버와 데이터베이스 서버의 통신을 완료했다.

서버에 배포하는 과정은 위코드의 aws 배포 관련 학습자료와 구글링을 통해 진행하니 VPC를 구축하지 않는 수준에서는 쉽게 완료할 수 있었다. 하지만, 데이터베이스 서버의 보안 등 여러 측면을 고려했을 때 VPC는 필수로 구축해야 하기 때문에 네트워크 관련 지식을 공부해 2차 프로젝트의 배포에 적용해볼 계획이다.

 

[다음글]

4. Naweke - 1차 프로젝트 전체 회고 - 4. 회고