[으라챠피디아] 프로젝트 최종 회고(1)
- 목차
1. api path Query string / Path Variable 중 어떤 것을?
RESTful 한 api 를 만들고 싶었는데 Query string / Path Variable 방식의 정확한 차이를 알 지 못했다.
Query string 은 특정 값으로 데이터를 정렬하거나 필터링할 때 사용하고,
Path Variable 은 특정 인덱스에 대한 조회를 통해 특정 resource를 식별할 때 사용한다는 차이점을 알 게 되었다.
으랏챠 피디아에서 사용할 api는 주로 movieId, reviewId, starId를 통해 데이터를 가져올 용도로 사용될 것이기 때문에 Path Variable가 더 적합하다는 판단이 들어, 기존 Query string 방식에서 Path Variable 방식으로 수정하였다.
하지만 userEmail을 통해 검색하는 경우, Query string이 조금 더 적합해 보이기는 하나, 일관성을 유지하기 위해 userEmail 또한 Path Variable를 적용하였다.
애초에 데이터 설계를 user model에 userId를 추가하여 userEmail이 아닌 userId로 user를 식별했어야하는 아쉬움이 있다.
또한 “유저의 별점 조회”라는 api를 만들 때 /api/users/scores 로 할 것인가 /api/scores/users로 할것인가의 고민을 했는데, 처음에는 “별점”에 중점을 두었으나 사용 주체가 먼저 나오도록 바꾸는 것이 더 내 취향(?)인 것 같다. 어떤 것을 선행으로 두냐의 정답은 없고, 일관적이게 사용만 하면 될 것 같다.
2. try-catch문 내의 변수의 스코프
return 을 try에 넣느냐, try-catch가 끝난 뒤에 넣느냐의 고민을 했다.
return 문은 실패할 일이 없다(?)라고 판단했기 때문에 굳이 try-catch안에 넣어야 하나?라는 의문이 들었다.
만약 return문을 try-catch문 밖으로 넣는다면, response 변수의 스코프 차이 때문에 response를 const가 아닌 let으로 try-catch문 전에 미리 선언 후 재할당을 하는 방식을 썼어야만 했다.
let 변수는 값이 언제든 재할당 될 수 있기 때문에, 의도치 않게 값이 변경될 수 있고 이는 에러를 유발할 수 있기 때문에 최대한 사용을 자제하고 싶었다.
따라서 try-catch문 내에 return을 넣고 변수를 const로 사용하는 방법을 택했다.
번외 ( try-catch 함수의 호출자에게 에러를 던져주려면)
return Error가 아닌 throw Error를 해줘야 한다. > 에러 핸들링의 중요성
3. 협업을 시작할 때는 프로젝트 환경 세팅부터 하고 시작하자
다른 사람과 함께 작업을 할 때, 우린 모두 각자의 컴퓨터 세팅이 다르다.
이를 짚고 넘어가지 않으면 예상치 못한 에러에서 삽질할 가능성이 매우 크다.
웹팩 설정 과정에서, 한 팀원만 옵셔널 체이닝(?.)이 인식이 되지 않았고, 최신 문법이라서 웹팩 내의 바벨이 인식하지 못하나? 웹팩 바벨 패키지를 별도로 더 설치해야하나? 라는 생각에 이것 저것 찾아보았지만,
결국은 그 팀원분의 node버전이 낮아서 인식을 못했던 것이었다.
정말 간단한 문제였는데 온 팀원이 2시간동안 매달려서 해결하려고 애를 썼다. 😭
앞으로는 꼭! 협업 시작 전에는 프로젝트 환경 세팅 과정에서 버전까지 꼼꼼하게 체크하고 넘어가자.🤩
4. 노드에서 require / import 어떤 것을 이용하는 것이 좋을까?
브라우저 js는 기본적으로 Import를 지원하고, node는 require를 지원한다.
서버도 최근부터는 pakage에 type:modules 를 추가하면 import를 사용할 수 있게 됐다.
서버, 클라이언트를 동시 작업할 때 코드의 일관성을 위해 서버도 import를 사용하는 것이 바람직할까?
the movie api를 서버에서 fetch 해와야 할 일이 있어서, node에서 fetch를 사용해야 했다.
node-fetch 라이브러리를 사용하고자 했는데, 이건 import로만 받아올 수 가 있었다.
하지만 node 입장에서 아직 import는 반영된지 얼마 안됐고, 테스트를 통해 정착되어가는 단계에 있다는 생각이 들었다. 그래서 node-fetch의 다른 버전을 설치하여 require로 통일하도록 하였다.
(추후에 언급하겠지만 fetch가 아닌 axois를 사용하는 것이 더 바람직 했다고 생각한다.🤫)
5. 서버에서 response를 줄 때 처리 결과 message를 문자열로 주는 것이 좋을까 상태코드로만 주는 것이 좋을까?
현재 서버가 response해주는 json data의 format은 다음과 같다.
- success : boolean
- message : string
- resData : object
물론 status 코드로도 처리 결과를 응답해준다. (주로 200,400,500 사용)
내 의문점은 message라는 프로퍼티를 통해 문자열을 주는 것이 과연 바람직한 것인지.
status code로만 주는 것이 더 현명한 것은 아닌가 하는 고민이었다.
(http status code도 이미 충분히 구체화되어져 있기 떄문에)
하지만 나는 status code로만으로는 나타낼 수 없는 구체적인 처리의 결과도 알려주고 싶었다.
(로그인 실패의 이유가 1. 해당 이메일의 유저가 없어서 실패인지. 2. 비밀번호가 틀려서 실패인지)
때문에 message라는 문자열 프로퍼티를 넣어서 실패 이유를 자세히 설명해주고자 했던 것인데, 더 생각해보니 이 message를 유저들이 직접적으로 볼 것이 아닌데 이렇게 친절해야하나? 라는 생각이 들었고,
유저한테 이렇게 자세한 내용을 말하는 것은 보안 문제의 위험성(해킹)이 커진다는 생각이 들었다.
사실 unit test과정에서 내가 원인 파악을 쉽게 하기 위해 message를 사용한 점도 크기 때문에, 앞으로 message는 사용하되, 너무 구체적이지 않고 rough하게 사용하고 status code를 최대한 적극적으로 활용하는 방안으로 개발을 해야겠다고 생각한다.
