🔗 Youtube
🔗 Front-end
🔗 Back-end

👗 1. 프로젝트 소개

H&M 클론 프로젝트

H&M은 여성, 남성, 아동, 리빙 제품 그리고 심지어 강아지 옷도 파는 큰 규모의 해외 SPA 브랜드이다. 규모가 큰 만큼 필터링 할 것도, 카테고리도 무지막지하게 다양했다. 프로젝트 기한은 9일로 짧은 기간이기에 전부 구현할 수 없어 가지치기를 잘 해야했다.

프로젝트 기한

2021.10.05 - 2021.10.15

👯‍♀️ 팀원 (HandWash)

• Front-end : 박태양, 신혜리, 조윤희, 서동혁
• Back-end : 이다빈, 김민호

🛠 적용 기술

• Front-end : React, HTML5, CSS3
• Back-end : Python@3.8.11, Django@3.2.8, PostgreSQL@14.0, JWT, bcrypt

🛠 구현 기능 | Back-end

공통

• 데이터베이스 모델링
• django 모델링
• CSV 테스트 데이터 작성

이다빈

• 장바구니 제품 추가, 삭제, 업데이트, 조회
• 카테고리, 상품 필터링, 상품 상세페이지
• DB 백업용 db_uploader.py 작성

김민호

• 회원가입, 로그인, 로그인 데코레이터
• 즐겨찾기 제품 추가, 삭제

🛠 구현 기능 | Front-end

전태양

• 상품 상세 페이지 레이아웃 구현
• 조건부 렌더링을 사용해 버튼 클릭 시 모달 창 나오도록 구현
• 좋아요 기능 구현 및 즐겨찾기로 데이터 전송
• 즐겨찾기 페이지 레이아웃 구현
• 즐겨찾기에서 사이즈를 선택해 장바구니로 전송
• 쓰레기통 아이콘 클릭 시 즐겨찾기 데이터베이스에서 삭제

신혜리

• nav, main, footer 레이아웃 구현
• main 무한 스크롤 구현
• nav list를 동적 라우팅을 이용해 해당 제품 카테고리로 연결
• 로그인 / 쇼핑백 hover 구현

서동혁

• 로그인, 회원가입 페이지 레이아웃 구현
• 조건부 렌더링을 통해 회원정보 추가 창 구현
• 장바구니 페이지 레이아웃 구현
• 즐겨찾기에서 받은 제품을 리스트로 구현

조윤희

(작성 중)

📋 2. 프로젝트 진행 과정

프로젝트 시작

프로젝트 시작 전, 멘토님들의 피드백을 거쳐 다음과 같이 필수 구현사항과 추가 구현사항을 나누었습니다.

필수 구현사항
1. 회원가입, 로그인
2. 메인 페이지
3. 카테고리 목록
4. 상품 목록(filtering, sorting)
5. 상품 상세페이지
6. 장바구니 + 주문 API
7. 즐겨찾기

이 중 주문 API를 제외하고 모두 구현했다. 프론트와 계속 통신을 주고받으면서 확인하느라 새로운 브랜치를 파서 작업을 진행할 수 없었다. (앞 서 작성된 API들이 머지가 되기 전 이었으므로..) 혼자서 틈틈히 구현해 보려고 한다.

📝 ERD

마지막까지 수정에 수정을 거듭 한 ERD. 사실 이 ERD도 마음에 안드는 부분이 많다. 그 이유는 뒤에 후술..

🖋 내가 구현 한 기능

상품 필터링

Query String으로 들어온 필터링 조건을 dictionary를 사용해 filtering&sorting 하고 limit&offset으로 일정 양만 프론트에 전달한다.

이 필터링에는 눈물이 담겨있는데 distinct() 사용을 위해 마감 2일전에 database를 mysql->postgresql로 변경했다.

모델링을 새로 수정했으면 더 쉽게 해결 할 일이였지만 나 혼자 하는 개발도 아니고 수십개의 이미 만들어둔 샘플 데이터를 수정하는 것 보다는 원래 사용해봤던 postgresql을 쓰는 게 시간 절약면에서 훨 나을 것 같아 한 선택이였다.

전 글에 작성되어있는 내용을 요약하자면,
우리의 products 테이블은 같은 제품이지만 다른 색상일 경우 다른 아이디를 가지고 있다. 그렇게 되면 필터링 할 경우 id가 다르기때문에 다른 제품으로 인식해 각각 보내준다.

mysql의 distinct는 field name 사용이 불가능 하므로 postgresql로 변경 후 해당 기능을 구현했다.

django의 distinct는 order_by에 사용한 field만 dinstinct에 적용할 수 있다. 그렇게 되면 프론트에서 들어온 sorting을 다시 적용하기 위해서는 order_by를 2번 적용해야한다. 그렇게 하기 위해 select_related로 관련된 필드를 가져와 color와 sub_category_id로 필터링 후(다른 카테고리에 같은 이름을 가진 제품이 있을 수 있으므로(실제로 샘플 데이터에도, H&M사이트에도 해당함을 확인 가능)) 프론트의 요청 Query String으로 들어온 필터링 조건으로 필터링 한다. 그리고 프론트가 요청한 정렬 조건에 따라 정렬 후 재 distinct를 해준다. 같은 조건으로 여러번 필터링 할 경우에도 조건에 맞다면 똑같은 제품의 데이터를 중복해서 보내주기 때문이다. ex) size=XL&size=XS

장바구니 제품 가져오기

나는 사실 프론트 관련한 지식이 거의 0에 수렴하므로 프로젝트 진행 전에는 데이터만 보내주면 프론트가 가공해서 사용할 수 있는 줄 알았다(가공해서 사용할 수 있긴 하다). 하지만 백엔드에서 가공해서 보내주는 편이 훨씬 가능하다는 것을 이번 프로젝트를 통해 알게 되었다.

그래서 장바구니 데이터를 보내줄때 총 세개의 가격을 보내주게 되었다.

실제 H&M사이트를 보면 상품 개별 가격, 상품 가격에 갯수를 곱한가격, 장바구니 제품의 총 가격까지 세개의 가격이 표시되어 있다.

상품 가격에 갯수를 곱하는 것은 그냥 곱하기로 되지만, total_price를 구하기 위해서 aggregate를 사용했다.

Django에서 aggregate는 보통 필드 전체의 합, 평균, 개수 등을 계산할때 사용한다. 엑셀에서 쭉 드래그해서 구하는 것 같은!

aggregate를 사용하면 dictionary 형태를 띄게 되는데

{
  "total_price" : "123,000"
}

이걸 product_list와 같이 보내주려면 다음과 같이 이상한 형태를 띈다

{
  "total_price" : {
    "total_price : "123,000
	}
}

딕셔너리 value로 또 dictionary를 갖기때문에 프론트에서 해당 데이터에 접근하기 굉장히 어려워진다.

딕셔너리니까 코드처럼 그냥 키값으로 접근하면 간단하긴 한데 뭔가 코드가 굉장히.. 예쁘지 않아서 다른 방법을 찾아보긴 했는데 stack overflow에서도 저 방법만 알려주는걸 봐서는 따로 방법이 없는 것 같다.

🎊 3. 첫 프로젝트를 마무리 하며

난생 처음 마무리? 해보는 프로젝트라서 그런지 감회가 달랐다. 팀원분들도 정말 마음에 들었다. 사실 욕심나는 부분이 많긴 했지만 나 혼자하는 프로젝트가 아니니 욕심을 많이 덜어냈다. 혼자 앞서간다고 좋은것은 아니니까 ㅎㅎ

브랜치도 날려먹고 잘못 머지된거 풀받아서 하루동안 서버를 못 돌리는 일도 있었지만 그래도 즐겁게(?) 마무리 할 수 있었다.

아쉬운 점이나 힘들었던 점을 꼽자면,

먼저 데이터 구축은 정말.. 힘들었다 의류 사진 구하는 것도 그렇고 유의미한 필터링 결과를 보내주려면 최소 수십개는 데이터가 필요했고 의류니까 상세페이지에 적어도 다섯장의 사진은 들어가야했다. 물론 그 상세한 사진들을 모두 구할수는 없으니 그냥 같은 사진을 반복해서 넣게 되었다.

두번째는 그 데이터 구축을 좀 더 일찍 했으면 기능 구현에 좀더 불을 붙일 수 있었을 것 같다. products같은 경우 데이터가 없으니 테스트를 못해서 만들어둔게 오류가 있는지 확인을 하지 못했다. 데이터구축을 아마 프로젝트 4일차에 했던 것 같은데..

세번째는 나는 정말 프론트에 대해 몰랐다. 처음부터 어떤 데이터가 필요한지 좀 더 잘 알았다면 또한 좀 더 속도를 붙일 수 있지 않았을까?

AWS배포도, 주문 관련 API도 해보고싶었는데 토요일에 2차 백신 맞은 이후로 열이 37.5도 - 38도를 왔다갔다 하고있어서 사실 컨디션이 그렇게 좋지 못해 하지는 못했다..(지금도 37.5도..)

그래도 하고싶은거는 해야 하는 성격이니, 지금 진행중인 2차 프로젝트 하면서 남는 시간 범위 안에서 차근차근 진행해보려고 한다.