[회고] Ticket Want It(티켓원잇)

📝프로젝트 소개

 

 

프로젝트 이름 : Ticket want It (티켓원잇)

제작 기간 : 2023.04.17 ~ 2023.05.22

팀 구성 : 6명 (프론트엔드 3명 , 백엔드 3명)

담당 포지션 : 백엔드(팀원)

 

 

구조

 

 

 

기술 스택

 

 

 

스키마

 

 

 

 

 

📌전체 기능

	일반 사용자	관리자
유저 관련 기능	로그인, 회원가입, 회원정보 CRUD, 이메일 인증, 임시 패스워드 발급	유저조회 및 수정, 검색
상품 관련 기능	상품 목록 및 상품 상세 정보 조회	상품CRUD,카테고리CRUD
주문 관련 기능	장바구니에 상품 추가, 장바구니 목록 및 개별 또는 전체 상품 구매	주문정보 조회 및 상태 관리

 

📌내가 구현한 기능 설명

 

라우터 

POST : /api/user → 회원가입

GET : /api/user→ 회원정보 상세보기

PUT: /api/user→ 회원정보 수정

DELETE: /api/user→ 회원탈퇴

POST: /api/user/reset-password →비밀번호 초기화

POST: /api/user/change-password → 새로운 비밀번호로 변경

POST: /api/auth → 로그인

GET: /api/auth/logout → 로그아웃

GET: /api/auth → 새로운 access 토큰 발급

POST: /api/user/emailAuth → 이메일 본인인증

POST: /api/user/profileImage → 프로필 사진 설정

DELETE: /api/user/profileImage → 프로필 사진 삭제

GET: /api/adminUser?page=N→ N번째 페이지 리스트 조회

GET: /api/adminUser/이름 → 이름 유저 검색

PUT: /api/adminUser/유저의ID → 해당 유저의 정보 수정

DELETE: /api/adminUser/유저의ID → 해당 유저 비활성화

 

구현한 기능

• 유저는 회원가입 및 자신의 정보를 조회, 수정, 탈퇴 가능
• 프로필 사진 등록 가능
• 관리자는 유저를 검색, 페이지별 조회, 수정, 탈퇴 가능
• 로그인 성공시, refresh토큰과 access토큰 발급
• 회원가입 완료시, 자동으로 로그인
• 유저의 비밀번호를 해쉬화해서 저장
• access 토큰 만료시, refresh토큰을 사용해서 access 토큰 재발급
• 비밀번호 분실시, 해당 이메일에 임시패스워드를 발급
• 회원가입시, 해당 이메일에 인증번호를 전송
• 배송완료후, 일정기간동안 구매자가 구매확정을 누르지 않을시, 자동으로 구매확정
• aws의 ec2인스턴스, nginx, PM2를 사용해서 서버 배포 및 관리
• SSL프로토콜을 사용해서 http 요청 암호화 (https 사용)

 

 

💻소감

프로젝트를 하면서 겪은 어려운 일 + 해결방법

nginx를 사용해서 정적콘텐츠를 연결하고 서버를 열었는데 서버를 계속 열어둬야하는 문제발생

→ pm2를 사용해서 해결

검증이 필요없는 API에도 토큰을 포함한 쿠키가 전송돼서 성능이 떨어질 수 있는 문제 발생

→ localStorage를 사용하는 방식으로 해결

(참고한 자료:https://developer.mozilla.org/ko/docs/Web/HTTP/Cookies)

JWT토큰이 탈취당해서 악용될수 있는 가능성 우려

→ access 만료시간을 1시간으로 줄이고, refresh토큰을 추가하고, https를 사용해서 가능성 최소화

유저가 탈퇴해서 DB를 삭제하면 OrderAPI에 영향을 주는 문제 발생

→ DB에서 삭제하는것이 아닌 state변수를 false로 만들어서 비활성화 설정으로 해결

 

프로젝트를 하면서 느낀점

api를 공개한 이후부터는 api를 수정하기 어렵다는 말을 들었었는데 실제로 해보니 정말 중요한 말이였다는것을 깨달았다. api를 만들어서 프론트에 전달한 이후부터는 이미 사용중이기 때문에 그들에게 영향을 줄 수 있다는 점을 생각하느라 버그 수정도 조심스럽게 해야했고, 기존의 기능은 편하게 수정할 수 있는 부분이 거의 없었다. 예를 들어, 리팩토링 할때 overfatching의 문제점을 발견했지만 이 문제점을 발견했을때는 이미 해당 api를 프론트의 여러곳에서 사용중이여서 쉽게 수정할수 없었다. 결국 if문을 사용해서 overfatching을 최소화했지만 코드의 가독성이 떨어진 느낌이 들었고, 이 경험을 통해서 왜그렇게 많은 기업들이 REST API를 배포할때 버전을 달아서 배포하는지, 테스트가 얼마나 중요한지 깨닫게 되었다.

---