이커머스 프로젝트로 PC방을 관리하는 사이트를 만들어봤다!
중요 기능
장바구니
요번 프로젝트의 중요 기능인 하나는 장바구니 기능이다.
장바구니는 Session Storage를 썼다. 원래 쿠팡 같은 서비스를 만들었다면 로그아웃 또는 다른 창으로 로그인 할 때 장바구니 내용이 유지되야해서 장바구니를 DB로 저장해야한다. 하지만 PC방 서비스의 특정상 장바구니 내용이 유지될 필요가 없다고 생각해서 Session Storage를 썼다.
우리가 만든 서비스는 로그아웃이나 다른 창으로 로그인하면 장바구니 내용이 없어진다.
인터넷에 자료를 살펴본 결과 장바구니는 쿠키를와 DB를 둘 다 쓴다는 내용이 있었다. Cookie를 안 쓴 이유는 쿠키 하나에 4096바이트의 데이터만 저장 가능해서 안 썼다.
시간 부족으로 적용을 못 한 기능
상품 수정
관리자 페이지에서 상품 내용을 수정하는 API는 만들어졌지만 프론트엔드에서 적용을 못 했다. 상품 수정을 하고 싶으면 상품을 삭제 후 재등록이 가능하다.
고객 비밀번호 재설정
비밀번호 재설정 페이지는 만들어졌지만 API는 안 만들어졌다. 클라이언트가 이름, ID, 핸드폰를 입력하면 정보에 해당되는 유저가 존재하는지 찾고, 있다면 클라이언트가 새 비밀번호를 입력하고 패스워드를 bcrypt로 암호화한 뒤 검색된 userId의 패스워드를 업데이트하면 된다.
관리자와 고객의 채팅 기능
Socket.io를 이용해 고객이 무엇을 결제하면 관리자 페이지에 이벤트 로그를 업데이트 했지만, Socket.io를 이용해서 채팅 기능은 만들지 못했다. 채팅은 채팅하기 버튼을 눌렀을 때 새 websocket 이벤트가 일어나고, 고객은 해당 PC 번호의 socket 방으로 입장해서 각 채팅방을 구분 할 수 있을 것 같다.
소셜 로그인 API
소셜 로그인 API는 국내 서비스 쪽에서는 Kakao 또는 Naver이 있다. 국외 서비스로 Google도 있지만, Google은 도메인이 등록되었을 때 사용 가능한 API인 것 같다. 다음에 이 외부 API를 사용하면 도메인 등록이 필수인지 알아보고 기능을 추가하는 것이 좋겠다.
다시 살펴볼만 한 부분
페이지네이션과 화면이 새로고침되는 현상
현재는 페이지네이션를 누를 때마다 그 페이지에 해당되는 정보를 요청하고 자동으로 새로고침된 후 정보가 뜬다. 페이지 번호를 누를 때마다 클라이언트가 요청을 보내니 비효율적인 구조인 것 같다. 개선을 하자면 1~5페이지의 정보를 한 번 보내고 프론트엔드에 저장해야한다. 6~10페이지를 누를 시 클라이언트가 다시 요청하면 요청 빈도를 줄일 수 있을 것 같다.
관리자 페이지에 Socket.io를 사용한 이벤트 로그가 있어서 새로고침을 하면 이벤트 로그에 있는 내용이 모두 사라진다. 따라서 관리자 페이지에 페이지네이션를 적용을 못했지만 새로고침도 막고 페이지네이션을 적용할 수 있는 방법이 있는지 알고싶다.
API를 합칠 수 있는지
클라이언트가 보내는 정보에 따라 Users 테이블에 유저 정보가 존재하는지 검색하는 API가 많다. 예를 들면 로그인 할 때 아이디와 비밀번호에 해당되는 유저를 찾고, 아이디 찾기 기능할 사용할 때 이름과 핸드폰 번호에 해당되는 유저를 찾는다.
이 때 각각 다른 API를 쓰는데, 같은 API를 사용해서 보내진 정보만 사용해서 해당 유저가 있는지 찾으면 겹치는 API를 합칠 수 있을 것 같다.
PUT과 PATCH의 차이
참고자료: https://www.geeksforgeeks.org/difference-between-put-and-patch-request/
PUT과 PATCH는 둘 다 정보를 업데이트할 때 사용되는 HTTP 요청이다.
PUT: 리소스가 존재하면 전체를 업데이트하거나 없으면 새로운 리소스를 만든다. PUT를 사용하고 싶으면 요청 body에 해당 리소스의 전체 정보를 보내줘야한다.
PATCH: PUT과 다르가 일부만 업데이트하고 그 리소르의 다른 정보는 수정이 단 된다. 요청 body에 업데이트될 정보만 보내준다.
이에 따라서 우리 프로젝트의 PUT 요청들은 모두 일부만 수정되는 기능이라서 PUT보다 PATCH 요청으로 보내는 것이 올바르다.
HTTP Status
참고 자료: https://umbraco.com/knowledge-base/http-status-codes/
HTTP Status를 잘 못 쓴 부분도 있는 것 같아서 다시 살펴보는 것이 좋겠다. 다음 부분은 수정할 만한 HTTP Status들이다.
200: 요청이 성공적이고 POST과 PUT인 경우 결과 정보가 message body에 있을 때.
201: 요청이 성공적이고 하나 또는 여러 개의 리소스가 만들어졌을 때.
404: 서버가 요청된 리소스를 못 찾을 때. 프로젝트에 받은 리소스 따라서 DB에 해당되는 리소스가 없을 때 이 status를 썼지만 엄밀히 따지면 API 주소는 존재하니 404는 알맞은 status가 아닌 것 같다. 따라서 전달할 데이터가 없어도 status 200으로 보내야 할 것 같다. 참고자료
프로젝트 진행하면서 느꼈던 점
매일 회의하는 점은 소규모 프로젝트에 꼭 필요한 부분이라고 다시 느꼈다. 이래서 개발자는 코딩보다 미팅하는 시간이 더 많다 라는 말이 있나 싶다.
새 코밋이 푸쉬될 때마다 공유하고 미리 풀을 받는 것을 강요했다. 이번에는 팀 멤버가 다른 브랜치에 작업하되, 한 기능이 완료되면 commit하고 브랜치를 원격으로 push한 뒤 PR을 통해서 main 브랜치에 바로 merge 시켰다.
사실 기능이 완료 안 되도 하루가 끝나면 서로 진도체크를 위해서 PR만 올렸으면 좋을 것 같았지만, 아무래도 나 포함 미완성 코드를 보여주기 꺼려해서 이 부분은 자연스럽게 생략이 되었다. 그래도 우리 팀은 회의가 아니라도 자주 진도를 공유해서 생략할 수 있는 부분이라고 생각하지만, 팀이 더 커지거나 진도를 공유하기 싫어하는 멤버들이 있으면 도입할만한 룰인 것 같다.
이런 Github convention을 trunk-based development이라고 배웠는데, 서로 무엇을 어디까지 했는지 바로 확인할 수 있어서 좋았다.
초기 세팅을 하면서 Prettier 설정까지 고려하지 못한 것이 아쉬웠다. Prettier 때문에 충돌도 나고, 그 중에 진짜로 바뀐 코드가 묻혀가지고 지워지는 경우도 있었던 것 같다.
그 외에 프로젝트 결과는 전반적으로 만족스럽다! 프로젝트를 오랜 기간 동안 보고 있으니 개선할 부분도 보이지만 기본적인 부분은 잘 작동된다 :)
