22.11.02.

프로젝트 방향성

• 라이브러리 최소화 → 경험 쌓기
• 라이브러리 최대화 → 완성도

기술적인 욕심도 밸런스 잘 맞춰야함

• 로드맵에서 보라색 표시된 것들은 다 아는 것이 좋다.
• 장단점
• 써본 이유
• 진입 장벽이 있으니 새로운 기술을 써보다가 시간을 뺏길 수 있으니 유의.
• ex. yarn. pnpm

ESLint 적용 → 코딩 컨벤션 적용 → 시간 많이 듬

• 사용하게 된다면 standard with TypeScript 추천 → 대신 적용하는데 시간 많이 듬

DB/배포서버로써 파이어베이스 추천

• 단점은 Cold Start → 프론트에서 인디케이터 활용을 잘 해야한다.
• Toy project로 많이 쓰임

라이브러리를 사용할 때 왜 이 라이브러리를 사용하는지 알아야함

Nest JS

• 스프링과 유사한 프레임 워크라 괜찮을 것 같다.
• 다만 직접 구성하는 express를 사용하지 않은 이유를 면접에서 설명가능하다면 좋을 것 같다.
• 새로나온 library이기 때문에 네이버에서 이미 안정적인 구조에서 변화하기엔 무리가 있어서 쓰는 팀은 거의 없다,
• 그러나 면접관이 흥미있게 들어줄 것이다.

모노레포

인터페이스를 통일하는게 프론트, 백 모두 JS를 사용할 때 장점으로 작용한다.

Typescript strict을 켜고 null이 들어갈 수 있는 경우를 다 막을 것.

프론트엔드에 유용한 사이트 (적용 가능한 브라우저 정보)

(https://caniuse.com/)

MySQL ORM vs 순수 쿼리

• 부서별로 다르다.
• 정합성이 중요한가에 따라서 달라진다.
• 정합성이 최대면 성능이 좋지 않음
• Database 담당자가 따로 있기 때문에 실무에서는 Query 검수 요청을 따로한다.

데이터베이스 선택 (RDB VS. NoSQL)

• 정합성이 필요할까?를 고민
  • ex. 웹툰 서비스에서 쿠키 결제 시, 쿠키 갯수를 가져오는 부분에서 동시에 쿠키 갯수에 접근할 경우
  • 문제가 생기기 때문에 락을 걸어야 한다
• NoSQL 추천
  • 동시성 해결 잘 못하지만 성능은 좋음
  • 하나의 document를 어떻게 나누는가가 핵심
    • DB 설계가 중요
• 쿼리 개수가 많아지면 (Deep Query)
  • RDB든 NoSQL이든 문제 발생하는건 똑같다.
  • 설계가 중요하다

배포할 클라우드 상의

• nCloud

• Firebase

• 포트폴리오 용으로 시연 영상을 다찍어두자.