11월 14일 회의록

오늘의 할 일

• 기술스택 결정 회의
  • 반드시 별도 문서 형태로 작성
  • 미리 조사해오면 베스트
  • 회의하며 같이 어떤 것이 있는지 공유하기
  • 예상 회의 시간: 2시간 (오전)
  • 결정해야 할 항목
    • 테스팅 라이브러리
    • 스타일링 라이브러리
    • 상태관리 라이브러리
• eslint, prettier 설정

회의록

깃 프로젝트 추가

• 배포 단위로 나눠보기

기술 스택 회의

FE

• Typescript

  • 한 번에 데이터 구조 볼 수 있다. (interface 정의)
  • 오류를 컴파일 단계에서 감지할 수 있다.
  • 생산성 향상

• React

  • 생산성 향상
    • custom Hooks
    • 풍부한 reference
  • props, state가 변경된 경우, 실제로 DOM을 변경해야 하는지 판별하여 반영하기 때문에 성능이 우수하다. (reconciliation process) - update가 필요한 최소한의 DOM만 조작

• Jotai

• Styled-component + tailwind css

• Jest

• Vite (No CRA)

• yarn

• Storybook(if possible..)

• React testing library

• CRA가 해주는 것?

  • 기본적인 structuring
  • bundling
  • web vital
  • eslint
  • test
  • webpack 설정

BE

• express.js
  • 프로젝트에서 서버 비중이 낮기때문에 프레임워크를 배워 학습시간을 늘릴 필요가 없음
• Typescript
• DB
  • rDB: MySQL
  • dDB: MongoDB
  • gDB: Neo4j
• ORM
  • 개발해보면서 결정하자. 지금은 어떻게 저장해야하는지 모르겠음..
  • ORM이 쉬운 건 허상이다
  • query는 파일럿에 따라 성능이 다르다
    • ORM은 파일럿이 달라도 성능이 똑같음
• package manager: FE와 동일하게 설정
• 로그인
  • 자체 로그인 x, oauth only
  • oauth: github, google
• https://github.com/typestack/class-validator
  • validation
  • 형 변환

테스팅 라이브러리

• 소셜 기능 이전에는 단위 테스트만 작성
• E2E를 한다면 어떻게 할지 고민
  • selenium
  • cypress
  • 유저의 입력, 출력이 알고리즘에 비해 단순해 테스트를 작성하는 의미가 떨어진다.
  • 소셜기능이 들어간다면 반대로 입력 단계에서 고려할 것이 많아져 이때는 고려해볼 가치가 있다.
• 단위 테스트 라이브러리
  • Jest: 러닝 커브가 쉽고 느리다. 커스터마이제이션이 어렵다. 커뮤니티가 좀 더 활성화되어 있다. 비동기 테스트(병렬 테스트)가 불가하다.
  • Mocha: 러닝 커브가 가파르지만 빠르다. Customization이 좀 더 자유롭다.
• 선택 기준
  • 애자일한 프로젝트 특성, 제한된 프로젝트 기간을 고려 했을 때, 러닝 커브가 낮은 라이브러리를 선택한다.
  • TDD는 프로젝트 전체에서 후순위 목표이므로, 일단 진입장벽이 낮고 사전작업이 별도로 필요하지 않은 라이브러리를 선택한다.
  • 1차 배포까지는 알고리즘 외에 단위 테스트가 필요한 피쳐가 없으므로, e2e나 확장성을 별도로 고려하지는 않는다.

스타일링 라이브러리

• Styled-component + tailwind css
  • atomic css - tailwind
    • 장점
      • atomic: property가 atomic하다
        • 중복되는 코드의 양이 줄어든다.
      • css 작성에 시간을 쏟지 않아도 된다. (개발자가 관심을 오로지 컴포넌트 파일에만 쏟을 수 있다. = 컨텍스트 스위칭이 없다)
      • 클래스 이름을 고민하지 않아도 된다
        • 협업을 진행할 때 네이밍 컨벤션을 덜 신경쓸 수 있다.
        • Designing with constraints, magic number
      • Responsive design
    • 단점
      • 필요없는 스타일까지 다 받게되므로 용량이 크다
      • 클래스명이 길어진다
      • 동적 스타일링
      • 디자인과 로직의 관심사 분리가 안 된다
  • emotion vs styled-component
    • 결국 css는 작성해야한다.
    • emotion은 자유도가 너무 높음
    • emotion은 기능이 다양하나 우리가 사용할 기능은 그렇게 많지 않음
    • 성능은 둘이 비슷함
  • 선택 기준
    • 협업시 네이밍이 공통된 기준이 명확하게 정해져있는게 좋겠음
    • 중복되는 코드의 양이 적었으면 좋겠다
    • 컨텍스트 스위칭이 없었음 좋겠다
    • 관심사 분리

상태관리 라이브러리

• Jotai
• Flux : redux, Zustand
• atom : jotai, recoil
• context API를 쓰면서 Provider 하위 컴포넌트들 중 context를 쓰는 컴포넌트들은 모두 리렌더링 되는 것이 불편했음
• 추후 스케쥴의 상태를 사용하는 별도의 UI를 추가할 수도 있기 때문에 확장 측면에서도 상태관리 라이브러리가 필요하다.
• bottom-up 방식은 단점이 있음 (추가 조사 필요)
  • Recoil, Jotai가 이에 해당됨

redux

recoil - atomic

• Flux : Redux, Zustand
  • React Suspense 지원 x
  • React Suspense가 필요한 이유?
    • fetch 등으로 데이터를 받아올 때 선언형으로 fallback 내의 요소를 보여줌으로써 UX 개선
    • 이전 fetch 요청에 대한 응답이 도착해야 다음 fetch 요청을 보낼 수 있는 구조에서 효과적으로 적용 가능
• Atomic : recoil, jotai
  • Recoil atoms are distinguished by string keys and jotai atoms are by object references. Jotai's implementation is based on WeakMap, and data is garbage collected by JS engine. This simplifies the implementation quite a bit. This will be a difference that lasts for a long time, maybe forever.
  • Jotai has a 90% smaller bundle size and is getting smaller over time ([Recoil for comparison](https://bundlephobia.com/result?p=recoil@0.2.0))

• 선택 기준
  • JS보다 TS로 작성된 라이브러리를 사용하고 싶다
  • 더 안정화된 라이브러리를 사용하고싶다
  • 번들 사이즈가 작으면 베스트
  • suspense를 사용하고 싶다 : flux 구조로는 불가능 : redux, zustand 제외
  • Atomic : recoil vs jotai
    • jotai가 업데이트가 더 잘되있고, 번들 사이즈가 작음
    • 둘다 러닝커브가 낮다

참고

• Type 관련 생각

• 언제 리코일을 사용하는게 좋을까?

• https://if1live.github.io/posts/escape-from-jest-jest-is-slow/

• https://www.browserstack.com/guide/jest-vs-mocha

• https://www.blog.duomly.com/mocha-vs-jest/

• https://github.com/pmndrs/jotai/discussions/849

• TDD

• https://itchallenger.tistory.com/569