peer session week3

피어세션

Week3

client 상태 관리

• recoil(atom, selector)
  • 로그인된 유저의 상태 관리(유저 명, 프로필 이미지)
  • atom, recoilState

server 상태 관리

• react query
  • useQuery
  • useMutation
    • 서버의 데이터를 바꿀 수 있는 요청

인증 추상화(passport)

• jwt토큰 정책을 통해 사용자 인증

  • 회원가입까지 진행한 유저 인증 정책
  • 회원가입은 하지 않은 유저 인증 정책

• Oauth 를 통해 Socials 연동

  • Google
  • GitHub
  • Tistory
  • (Kakao)

mongoDB

• 데이터 모델링

  • 임베드 방식 관계를 갖는 데이터 집합을 단일 도큐먼트에 포함하여 저장하는 방식

  • 레퍼런스 방식 도큐먼트에 관계를 갖는 다른 도큐먼트의 식별자를 참조키

• Multi-Key index를 통한 태그 자동 완성

  • 초성 / 초성+중성+종성의 태그 기반 검색 효율 향상

    • 하나의 Query 에서 두개 이상의 Index 를 적용하는 방식 $or 사용

    $or Clauses and Indexes

    When evaluating the clauses in the $or expression, MongoDB either performs a collection scan or, if all the clauses are supported by indexes, MongoDB performs index scans. That is, for MongoDB to use indexes to evaluate an $or expression, all the clauses in the $or expression must be supported by indexes. Otherwise, MongoDB will perform a collection scan.

    • MongoDB Index 는 $regex(like) 연산 역시 index 가 적용

    Index Use

    For case sensitive regular expression queries, if an index exists for the field, then MongoDB matches the regular expression against the values in the index, which can be faster than a collection scan. Further optimization can occur if the regular expression is a "prefix expression", which means that all potential matches start with the same string. This allows MongoDB to construct a "range" from that prefix and only match against those values from the index that fall within that range.

• Validate

  • Reference Object ID 유효성 검사하는 Validator
  • 유효한 URL 을 검사하는 Validator
  • 유효한 Email 을 검사하는 Validator
  • 숫자의 자릿수를 검사하는 Validator
  • 문자열의 길이를 검사하는 Validator

결과

질문

• MySQL이 아닌 mongoDB를 선택한 이유 (update가 많다면 mysql이 낫지 않을까요?)

  • 프로젝트 확장을 고려했을 때, 확장성이 용이하다는 점
  • SNS 특성상 대용량 데이터를 다루어야 한다는 점
  • null system에 대응 가능
  • 대용량 데이터(지도 데이터)에 유리
  • Node는 MySQL과 잘 맞지 않고, MongoDB가 더 적합하다는 멘토님의 조언

• mongoDB의 장점(embedded, 중복)을 살리기 위해 저희는 link 최소를 목적으로 결국 쓰지 않는데, 여러 collection으로 나누고 link를 쓰신 이유 (말씀해주셨지만) 듣고 싶습니다.

  • (web26)embedded는 sync를 맞추기 위해 개발자 cost가 더 들고 힘들어짐
  • (web26)document가 늘어나는 것을 고려
  • (web11)update가 매우 적게 일어나서 sync가 힘들지는 않다고 고려함
  • (web11) embedded 할 시 document 탐색이 너무 쓸데없이 하는 것이 있어서 collection으로 나눈 부분도 있음

• 초성 다시 한 번만 설명해 주시면 감사하겠습니다. 저희 팀도 적용해 보고 싶어요!

  • 한글 태그 자동완성을 위해 원래 글자와, 초성, 모음 자음을 따로 저장

  • 자바스크립트 regex보다 mongodb regex가 훨씬 빠르다

  • mongodb regex는 이어진 것들을 찾기 때문에 초성이랑 풀네임 자음모음이랑 따로 저장해야 한다

• 서버 무중단 배포 어떻게 하셨나요..?

  • (web11)pm2 restart vs reload의 차이가 있는데, reload의 경우에는 process를 1개 초과로 사용 시 프로세스가 중단되지 않고 지원됨(process가 1개라면 의미 없음)

• TDD/test 하고 계시나요?

  • backend는 TDD이지만 frontend는 TDD 굳이..?
  • test가 함수단위로 이루어지는데 front에서는 컴포넌트 단위로 이루어지는데 컴포넌트 테스트는 단순한 UI test에 불과하다
  • backend는 상태가 똑같지만 frontend는 사용자에 따라 상태가 달라지기 때문에 test하기 힘들다

• Elastic Search는 고려해보셨는지?

  • 검색은 태그만 되는건가요?

• mysql, mongodb의 인덱스 다른 점 다시한번 설명해주세요ㅜ

  • 확실하지 않아서 다시 찾아보자!
  • mysql은 B+트리, mongodb는 B트리+ first, second? 더 공부해봐야한다!!

• mongoDB 모델링을 어떻게하고 고민했는지

  • 지역별로 평점과 지역 내 구, 동의 평점 data를 어떻게 설계하시고 관리하지는지 궁금합니다.
    • MapInfo 내부에 시, 구, 동 을 구분하지 않고 병렬적으로 작성(행정구역 code 값이 자체적으로 병렬적 구조임, 쿼리문을 짜는 것이 더 쉬움)

• 백엔드와 프론트엔드 작업이 피쳐단위로 나누어져있나요? 아님 백엔드 프론트엔드를 어느정도 나눠서 하고있나요?

  • (web26) 피처 단위에서 백,프론트 나누어서
  • (web11) 쿼드 프로그래밍에서 발생한 이슈/피처 단위로

• validator부분도 훅 지나가서 이해를 잘 못했네요ㅜ

  • 이해완료 pass~?

• 지리 데이터는 어떤 데이터를 활용하셨나요

  • 통계청 데이터 사용 (API)

• 크롤링이 왜 백엔드에서 되야하는지 한번더...

  • 클라이언트에게 buffer가 걸리는 작업은 절대 피하자! -> 클라이언트에서 하면 buffer다
  • 클라이언트 PC 성능, 네트워크 상태를 믿으면 안된다!
  • 따라서, 서버에서 하는게 좋은데... 서버가 또 터질 수 있으니까 어렵다!

• 우리 팀의 잘한 점 한 가지씩 말하면 좋을 것 같아요!

  • (web26) 서로에 대한 피드백이 굉장히 빠르다.
  • (web11) 아침, 저녁으로 스크럼/중간점검을 통해서 소통을 많이 한다.

• recoil에 어떤 값들을 저장했나요?

  • user 객체 : follow한 사람, follow 당한 사람, username 등 user에 관한 모든 정보
  • NextJS로 server에서 상당 부분 처리해서 page 컴포넌트의 props로 넘겨주기 때문에 상태관리의 필요성이 줄어듦

• NextJS를 선택하신 이유는 무엇인가요?

  • 찬양할만해서(대체 불가한 SSR Framework, SEO를 위한 것)
  • 프로젝트 구성이 아주 편리하다! -> 9.3 버전부터 찬양받아 마땅하다!