장바구니 담기
-
유저, 상품, 옵션, 수량을 받아서 장바구니 테이블에 저장한다.
-
같은 유저가 같은 상품을 골라도 옵션이 다르면 같은 cart 항목이 아니다.
또한 서비스 기획상 상품마다 옵션이 있는 것이 아니라, 모든 상품에 동일한 메시지 카드 옵션이 있는 상황이다. -
수량이 양의 정수로 들어오지 않으면 에러메시지를 반환한다. 프론트엔드에서 걸러내겠지만 한번 더 확인한다.
-
get_or_create()를 이용해 이미 존재하는 항목이면 수량만 증가할 수 있도록 했다. quantity default를 0으로 주라는 모델링 피드백의 이유를 깨달았다. cart의 다른 데이터가 create되면 quantity는 우선 0으로 들어오고 그다음 입력된 수량값으로 업데이트 된다. 만약 이게 안된다면 if문으로 두가지 경우를 분기처리했어야 한다.
장바구니 조회
-
저장된 장바구니 항목 리스트를 보내준다.
-
하나의 유저는 여러개의 장바구니 항목을 가질 수 있는 상황이다.
장바구니 수량 수정
-
특정 장바구니 항목의 수량을 수정하면 DB에 업데이트하고 업데이트된 수량을 보내준다.
-
쿼리 파라미터로 cart_id를 받고, body로 quantity를 받는다.
-
quantity 하나만 변경하기 때문에 patch 메소드를 사용했다. put 메소드는 모든 프로퍼티에 대해 값을 받아야해서 비효율적이라고 생각했다.
장바구니 삭제
-
cart_id를 쿼리 파라미터로 받아서 해당 항목을 삭제한다.
-
테스트와 시연을 하며 생성과 삭제를 반복하니 cart 테이블의 id가 띄엄띄엄 생기게되었다. 테이블의 id값들이 지저분해진다는 생각이 들었는데, 다시 맞추겠다고 정렬을 해버리면 관계된 모든 테이블의 외래키도 변경해야한다. "사망한 사람의 주민번호는 다시 사용하지 않는다"는 멘토님의 답을 듣고 완벽히 이해했다.
느낀점
-
장바구니 생성 post 함수를 구현하고 통신까지 완료하니, 나머지 핸들러들은 수월하게 작성할 수 있었다. 무엇보다 구현하려는 기능이 무엇이고 어떤 특징이 있는지 명확하게 파악하는 것이 우선이라고 느꼈다. 어떤 기능의 API를 만드려고 하는지 제대로 정하지않고 무작정 코딩을 시작하는 것은 지양해야겠다.
-
다양한 에러 핸들링을 하면서 특히 프론트엔드와 통신하며 생길 수 있는 예외 상황에 대해 많은 생각을 했다. 누가보면 프론트엔드를 못 믿는냐는 생각을 할 정도로 나름 철저하게 대비를 했는데, 결국 DB 데이터를 지키기 위함이다. 원래 아무리 QA를 철저하게 해도 유저들은 상상도 못한 방법으로 버그를 찾아내는 법이니까. 백엔드는 클라이언트쪽에서 어떠한 일이 벌어져도 DB는 항상 깨끗하게 유지해야할 책임이 있다.
-
장바구니 수량을 수정하는 과정에 transaction을 적용해보았는데, ACID 특징과 관련해 어떠한 역할을 하는지 이해할 수 있었다. 계좌이체, 결제, 장바구니 등에 사용된다는 것은 알겠는데 그럼 모든 과정에 적용하지 않는 이유는 무엇일까? 성능과 관련된 것일까? 아니면 정말로 필요가 없어서 인가? RDBMS와 SQL을 더 공부하고 이해하며 답을 찾아보자.
