2022-03-19 Office Hour
스키마 변경 시 기존 DB 변경
Atlas에서 column 추가, updateMany 사용
기존 정보를 바꿔야 하는 경우
프로시저 실행, query 왕창 날리기
db에 변경사항 먼저 업뎃하고 배포
코드리뷰
- Model
- 명명법 통일 필요
- Router
- parameter 유무 파악하는 로직 필요
- res 전달하는 부분도 통일하는 게 좋음(aws 참고)
- errorMiddleware
- status code를 상황에 따라 나눠주는 것이 좋음
공통되는 부분 utils.js로 뽑아두는 것 추천
좋아요 기능
유저 스키마에 like field를 추가하고자 함
누가 누구에게 눌렀는지
유저 id 배열로 넣기
userAuthRouter.post('users/:id/likes'), async (req, res, next) => {
const {likedUserId} = req.body;
// …
}populate하면 너무 커져버리지 않을까? > 유저 ID만 배열로 주자!
아니면 populate를 필터링해서 가져오기
gitignore 쉽게하기
https://www.toptal.com/developers/gitignore
ESLint 참조
https://eslint.org/docs/user-guide/getting-started
node_modules
각 패키지마다 또 의존하는 애들이 있기 때문에 node_modules 안의 내용이 많아짐
이들의 정보는 package-lock.json에 존재함
ACID
https://ko.wikipedia.org/wiki/ACID
CAP
https://ko.wikipedia.org/wiki/CAP_%EC%A0%95%EB%A6%AC
http://eincs.com/2013/07/misleading-and-truth-of-cap-theorem/
react-virtualized
유저 정보 공개 범위 지정
middleware에서 처리하는가
스키마에서 공개 여부를 저장하는가
유지가 되어야 하니 스키마에서 저장되는 것이 맞음
전체에 대해 true/false를 지정한 다음 이 값을 FE에서 보고 결정 => 개발자도구로 까보는 사람도 있음
따라서 보여줄 부분만 백엔드에서 주는 것을 추천
지원 여부 확인
https://node.green/
https://caniuse.com/
📒 오피스아워 진행 후
: 확실히 현업자 코치님과 함께 이야기를 진행하고, 코드리뷰를 받으며 여러가지를 배울 수 있어서 오피스 아워 시간이 너무 좋았다.
체크해주신 사항으로는 들어오는 parameter를 체크해주는 middleware를 두기, res 데이터 구조 통일하기, errorMiddleware 만들기, Model 이름 통일화 하기가 있었다.
이때 Model명과 res 데이터 구조는 직접 프로그래밍 하면서도 느꼈던 부분이여서 확실히 빠르게 수정해야겠다고 느꼈다.
그리고 middleware로 체크하는 부분도 만들기 전에는 필요성을 높게 느끼지 않았지만 만들고 사용해보자 확실히 없을 때 보다 에러 체크 하기도 편하고 보낼 요청이 확 줄어들어 최적화에도 큰 도움이 된 것 같았다!
