2단계 회고
드디어 협업미션이 막을 내렸다 👏
여태껏 프론트끼리 기능을 구상하고 구현을 하는것에 그쳤었다. 그렇지만 이번에는 백엔드와의 협업을 통해서 만들어진 api를 연결한 실제 작동하는 페이지를 만들었다는 것에 성취감이 다른 미션 보다 컸었다.😎
처음에 백엔드가 구현해준 서버를 연결하였을 때는 긴장이 가득했다. 😱 혹시 나의 코드로 인해서 백엔드의 api 기능이 구현이 되었는지 제대로 테스트 하지 못하면 어떻게 하지? 라는 걱정으로 가득해서 더욱 긴장이 되었던 것 같다.
그리고 예상대로 초반에는 백엔드와 프론트 두 쪽 다 사소한 에러들이 있어서 한번에 연결이 되지 못하였다.🥲
그래도 시간이 얼마 걸리지 않아 구현한 기능들이 다 제대로 작동이 되어서 다행이였다.
이번에 api 명세를 정할 때에는, 그래도 1단계 때 조금은 해봤다고
1단계 때 보다는 더 활발하게 소통을 할 수 있었다.
로그인 기능 처럼 정해진 틀이 있는 것이 아니고, 장바구니 기능을 어떻게 구현할 것인지 정하는 것은 온전히 우리의 몫이였기 때문에 기능을 어떻게 구현할 것인지 정하는 것도 재미있었다. 그리고 팀마다 다르게 기능들을 구현하고 처리를 해주는 것을 구경하는 재미도 있었다.
예를 들어 장바구니에 이미 담긴 항목을 장바구니 담기버튼을 눌렀을 때에 어떻게 처리해주냐가 팀마다 이야기가 달랐다.
우리 팀의 경우, '장바구니에 이미 담긴 상품입니다' 라는 안내문구와 함께 장바구니 페이지로 이동하는 것으로 처리하였다.
그에 반해 다른 팀들은 장바구니 담기 버튼을 toggle 느낌으로 생각하여 장바구니에서 해당 상품을 삭제한다던가, 장바구니에 그대로 담아주거나 하는 등의 처리 방식들이 있었다.
어떻게 보면 사소한 기능인데도 처리 방법이 이렇게까지 다양해질 수 있구나를 느낄 수 있었다.
API 명세
| 기능 | 메서드 | url | request header | request body | response | error |
|---|---|---|---|---|---|---|
| 상품 목록 조회 | GET | /products | { products: [{id, name, price, thumbnail }]} | 상품 목록 조회에 실패하였습니다 500 | ||
| 상품 세부 정보 조회 | GET | /products/{productId} | {id,name, price, thumbnail} | 해당상품이 존재하지 않습니다 404, 500 | ||
| 장바구니에 상품 추가 | POST | /cart/{productId} | jwt | 201 | 이미 담긴 상품 - 303 see other | |
| 에러 상황일 때 - 400 | ||||||
| 장바구니 상품 목록 조회 | GET | /cart | jwt | {cartItems: [{product:{ id, name, price,thumbnail}, quantity }]} | ||
| 장바구니에 상품 수량 변경 | PUT | /cart/{productId}/quantity | jwt | quantity | 200 | |
| 장바구니 상품 제거 | DELETE | /cart/products | jwt | { productIds : [1,3,4,5]} | 204 | |
| 장바구니 비우기 | DELETE | /cart | jwt | 204 | ||
| 장바구니 상품 구매 | POST | /orders | jwt | { productIds : []} | 200 |
아쉬운 점들
리뷰어 분이 1단계 때에, 반영했으면 좋겠다는 점들이 있었는데 시간이 부족해서 다 반영하지 못해서 아쉬었다.
React Outlet
이번 미션의 경우, 모든 페이지에 들어가는 header footer가 고정되어 있어서 Outlet으로 처리하는 것이 좋았다.
리뷰어 분 그래서 이 부분을 적용하면 좋겠다고 하였는데, 이미 돌아가기에는 너무 멀리 돌아왔..
시간이 부족해서 적용하지 못하였다.
redux-persist
userId를 리덕스에서 관리하면서 새로고침해도 정보가 날아가지 않도록 하기 위해서는 redux-persist를 활용했어야 했다.
백엔드와 연결하기 전에는 redux-persist를 적용하였을 때 문제가 발생하지 않았었다. 하지만 백엔드와 연결하고 나니 redux-persist를 잘못 적용하고 있다는 것을 알게 되었다.
redux-persist를 통해서 userId만을 저장해야 하는데, redux에서 관리하는 모든 정보들이 저장되고 있었다. 그래서 백엔드와의 연동을 할 때에 userId가 필요한 요청들이 재대로 동작하지 못하게 되었다.
일단은 시간이 부족하였기 때문에, redux-persist를 빼고 sessionStorage에서 userId를 관리하게 되었다 😭
이번 미션에서 이 부분이 가장 아쉽다
로그인시 userId 받아오기
저번 미션 막바지에 accessToken으로 decode를 해서 userId를 알아내지 말고 userId를 서버에서 받아오자는 이야기가 나와서 일단은 로그인 성공시 userId를 응답으로 받아온다는 것으로 가정하고 기능을 구현하게 되었다.
그런데 백엔드와 이야기를 해보니, 해당 경우에는 순환참조가 발생할 수 있어서 2번 요청하는 방향이 더 적절하다고 하였다.
전 단계에서 백엔드와 충분히 이야기를 하고 우리 조가 아닌 다른 조들의 이야기도 들어보았다면 1단계에서 충분히 그렇게 api를 구현할 수 있었는데 하는 아쉬움이 있었다.
앞으로는 다른 크루들과 프로그래밍관련해서 이야기를 많이 나눠야 겠다는 다짐을 하게 되는 계기가 되었다.
