이번 프로젝트는 백엔드 개발자와 함께, 그리고 팀으로 진행한 첫 번째 프로젝트였다.
그만큼 어떤 목표를 가지고 나아갈지에 대해서도 고민이 되었는데, 내가 첫 번째 프로젝트로 얻고자 했던 것은 크게 2가지였다.
마켓 컬리를 클론코딩하기로 결정했던 이유
사실 4주동안 각기 다른 3개의 작은 프로젝트를 진행하면서 개인적으로 계속해서 고민하고 다르게 만들어봤던 기능이다. 좋은 UX를 위한 대중적으로 쓰이는 방법이기도 하고, 백엔드와 통신하는 데 있어 데이터를 효율적으로 받아오기 위한 방법이기도 했기 때문에 성능 최적화에 대해 고민할 수 있는 방향이라고 생각했기 때문이다.
마켓컬리의 메인페이지에는 MD의 추천이라는 영역이 있다.
각 카테고리 별로 MD가 추천하는 6개의 상품을 버튼을 클릭할 때마다 보여주는 영역이다.
연관이 없는 대 카테고리버튼별로 각기 다른 아이템을 받아오는 것이기 때문에
요청 response를 json형태로 변환하여 응답의 body내부의 값을 출력하면,
status code보다 백엔드에서 지정한 상세한 에러메시지를 확인해 통신에러를 더 빠르게 해결할 수 있다.
백엔드에 요청을 보내던 중 에러가 발생했다.
response를 출력해보니 400 Bad Request가 떴다.
fetch('url')
.then(res => console.log(res)) // "reponse...400...Bad Request.."
400이라면 요청이 뭔가 잘못되었다.
어떤 부분이 잘못된 거지?
아무리 살펴봐도 무엇이 잘못되었는지 보이지않는다...
급한 마음에 이렇게 시도했다.
1. 계속 살펴본다.
2. 프론트엔드 팀원들의 의견을 구한다.
3. 백엔드 팀원들의 의견을 구한다.
4. 이렇다 할 실마리가 없다. 다시 살펴본다.
효율적인 방식은 아니다. 이 때 어떻게 접근했다면 좋았을까?
fetch('url')
.then(res => res.json())
.then(data => console.log(data) // "NO_TOKEN"
단순히 응답자체를 출력하면 status code와 요청의 성공여부를 포함한 응답의 내용이 모두 출력된다.
하지만 이 응답을 json파일로 변환하여 body내부 값을 출력하면, 백엔드에서 케이스 별로 상세하게 작성한 에러메시지를 볼 수 있다.
이렇게 코드를 작성하자 "NO_TOKEN"이라는 메시지가 떴다.
그렇다. 토큰을 헤더에 넣어 요청하지 않은 것이다.
이제는 이 부분을 잘 지켜서 빠르게 요청의 어떤 부분이 문제가 있는지 확인하고 해결해볼 수 있다.
백엔드 팀원분이 분명 지정해놓은 에러메시지가 왜 확인이 되지 않는지, 어디서 확인할 수 있는지 의아해했다. 고민하고 찾아보다가 알게 되었는데, 이 에러메시지는 백엔드에서 확인할 수는 없다.
요청에 대한 응답을 보내주면 프론트엔드에서 확인하고 백엔드에 전달해주어 함께 문제를 해결해야 한다.
다른 몇몇 프론트엔드 분들이 프로젝트 중간 중간 나에게 질문했던 내용이 있었다.
...map is not a function 이라는데.. 왜 이런걸까요?
map을 할 데이터가 없기 때문이었는데, 목업데이터로 작업할 때까지는 문제가 없었으나 백엔드에서 요청을 보내 받아온 데이터를 사용하면서 이런 문제가 발생했다.
두 가지 방법으로 모두 해결이 되었는데, 2번의 경우 목업데이터와 달리
useEffect(() => {
const loadCartData = async () => {
const response = await fetch('url', {
method: 'GET',
headers: {
},
});
const data = await response.json().result.data; // 이 부분!
};
loadCartData();
}, []);
이렇게 써주어 result객체 안의 data에 접근해야 한다.
로컬 json파일과 실제 응답의 형태가 달라서 혼란스러웠던 분들이 있었던 것 같다.
이 부분은 콘솔에 출력해가면서 확인해서 적절하게 받아와주면 되지만, 한 번 더 나아가 생각해보자.
왜 이렇게 보내주는 걸까?
백엔드에서 보내는 모든 응답은 이렇게 자동으로 result에 쌓여서 전달되는 걸까?
내가 공부했던 http 통신에서는 이러한 내용은 없었다.
그렇다면, 백엔드에서 직접 이렇게 만들어 보내주는 걸까? 이유는 뭘까?
백엔드 팀원분에게 답을 들을 수 있었다.
프론트엔드에서 백엔드가 보내주는 데이터의 key값을 알지 못하더라도 받아온 데이터에 접근하기 용이하도록 하기 위함이라고 한다.
이 역시 백엔드에서 프론트엔드를 배려해 작성한 코드였던 것이다.
장바구니 페이지를 구현하면서 궁금증이 생겼다.
장바구니는 상품의 수량변경, 삭제, 선택 등등 잦은 상태변경이 이루어지는 페이지이다.
그렇다면 수많은 유저가 동시접속한 사이트에서, 장바구니의 모든 액션을 백엔드에서 요청을 보낸다면 서버에 부담이 갈 테니, 프론트엔드에서 상탯값으로 변화에 대한 업데이트를 관리해두다가, 선택한 상품에 대해 주문하기 버튼을 눌렀을 때에만 백엔드에게 최종적으로 주문한 정보를 보내주는 것이 최선이 아닐까, 라는 생각을 했다.
그런데 백엔드의 관점은 달랐다.
백엔드에서는 수량변경과 선택삭제,개별삭제 시 요청을 받고자 했는데, 가장 큰 이유는 데이터 정합성 때문이었다.
데이터 정합성?
현업에서는 빠르게 반복되는 잦은 요청 등과 같은 많은 변수들이 존재하는데 따로 값을 관리하게 된다면 실제 데이터 베이스와 유저가 업데이트한 데이터가 따로 움직이게 되고, 안정적이지 않게 된다. 따라서 백엔드에서 데이터를 관리하고 프론트에서는 이 액션을 요청해 응답받은 값으로 화면에 표시해주는 것이 안정적이라는 것이다.
그래서 처음에는 이미 장바구니 아이템과 선택한 아이템에 대한 상탯값을 통째로 관리하고 있었는데, 이 의견대로 이후에 수정했다.
물론, 정답은 없을테니 그 업계의 특성과 기업의 여건등을 고려했을 때 또다른 최선의 방법이 있을 것 같다. 나중에 현업에서 일하게 되면서 이 부분에 대해 많이 고민해보고 시도해볼 수 있는 기회가 있었으면 좋겠다.