1. 개요

일시 및 장소 : 11.14.(월) 14:00 ~ 18:00, 게더타운
참여자 : 전원
목적 : 기능 구현 전 기술 스택 결정
회의 중요도 : 상

2. 고려 사항

2.1. 프론트엔드 스택

2.1.1 React.js vs 바닐라js → React.js

바닐라js 사용 시 상태 관리에서 어려움을 겪음
- 상태 변경 시 렌더링이 전체적으로 일어나 성능을 최적화 하지 못함
- 바닐라js 사용 시 비동기 처리가 불편했음
  - Class constructer에서 async, await를 사용하지 못함
바닐라js 사용 시 컴포넌트 재사용이 어려웠음
- 코드 중복이 많아 작업 시간이 길었음
React.js는 이미 사용해봤기 때문에 깊이 학습할 수 있음
- 4주차에서 배우지 못한 부분을 더 학습할 수 있음
매우 짧은 개발 기간(4주)
- 렌더링 성능 등을 알아서 챙겨주면 좋음

2.1.2. 전역 상태 관리 라이브러리 → jotai

상준
- Jotai(기술블로그): 링크
  - 리뷰어(이미림)분께서 추천해주신 라이브러리
  - Recoil에 비해서 단순하고 쉬움
  - Redux를 써본 경험이 있었는데, 상당히 복잡했음
  - 단점: 따로 배울 시간이 필요함, 참고 자료가 많이 부족함
- Recoil
  - 새로운 상태관리 라이브러리를 배울 수 있음
  - 메모리 누수 이슈가 있음
  - 아직도 0번대 버전으로 예상치 못한 문제점이 있을 수 있음
- Context API
  - 리액트 내장 상태 관리 라이브러리
  - Context API 단점 : 드릴링, 하지만 과연 이런 단점이 우리 프로젝트에서 크게 작용할까?
  - 우리 프로젝트에는 모달이 많음
    - 관리해야 될 상태가 많음
윤우
- 상준 의견에 깊이 동감
- React Query
  - 비동기 로직과 상태 관리 로직을 분리할 수 있음
    - 그러나 다른 상태 관리 라이브러리를 사용해도 크게 어려움은 없을 듯
    - 나중에 필요할 때 사용하면 되고, 우선은 recoil이나 jotai 선호
한빈
- Redux
  - 상태, 액션, 리듀서, 스토어 등의 개념을 통해 상태 관리가 이뤄지는 과정을 배울 수 있음
  - 불변성 유지 때문에 고차함수를 많이 사용해 볼 수 있어서 좋음
  - 리듀서를 짜기 위한 시간이 오래 걸림
  - 다만, 사용법대로 쓰면 잘 굴러감
- Recoil
  - 프로젝트 규모가 작아서 메모리 누수 이슈 등이 크게 문제되지 않을 것 같음
  - 사용법이 간단해서 짧은 기간에 적합할 것으로 보임
현정
- Redux
  - Redux는 사용을 위해 만들어야 하는 함수가 매우 많음
    - 보일러 플레이트를 사용하는데, 요즘 추세랑 맞지 않음
  - 비동기 처리 시 Saga나 Thunk를 사용해야 함
    - Mildo는 API 요청이 많은데 사용법이 복잡하고 코드량이 늘어남
  - 일반 프레임워크라 리액트와 궁합이 좋은지 모르겠음
- Context API
  - 사용법이 Redux와 거의 비슷하여 비교 우위가 없음
  - recoil 대비 장점을 모르겠음
- Recoil
  - 비동기 지원이 더 편할 것으로 보임
- Jotai
  - 한번도 안 써봐서 잘 모르겠음
최종 결정(블로그)
- jotai → 선정
  - TS로 만들어짐
  - 1번대 버전이 출시됨
  - jotai는 다운로드 수가 적고 참고 자료가 많이 없음
  - recoil보다도 간단한 사용법
  - 비동기 처리가 상대적으로 더 쉬워 보임
- recoil
  - JS로 만들어짐
  - 아직도 0번대 버전
  - 캐싱이 가능함
  - 서버 요청 로직과 상태 관리 로직이 분리되지 않음
- 기타
  - jotai와 recoil은 문법이 비슷함
  - jotai와 zustand는 로 아무것도 감싸지 않아도 사용 가능
  - bundle 크기 : zustand < jotai < recoil
  - jotai에서 문제 생기면 recoil로 바로 넘어갈 수 있음(차선책이 마련되어 있음)
react-query (추후 논의)
- Mildo는 비동기 처리가 많음
- 서버 요청 로직을 분리할 수 있음
- 그러나 인기가 많다고 무조건 사용해보는 것이 맞는지?

2.1.3. 스타일 → Styled-Component

SASS/CSS
CSS in JS (Styled-Component, Emotion)
- 익숙함
- SSR에는 Emotion이 더 적합
CSS module (A.jsx, A.module.css)
- 클래스명이 기억이 안남
Tailwind CSS / Chakra UI
- 못생긴 코드

2.2. 백엔드

2.2.1. DB → MongoDB

테이블 간 관계가 느슨할 것 같아 NoSQL도 좋을 것 같음
- 도시 데이터 API는 데이터의 양이 많은데 RDBMS의 테이블보다 JSON 형식으로 관리하는 것이 편할 수 있음
- 또한, 도시 데이터를 수정하지 않기 때문에 단순 read 속도가 빠른 NoSQL이 나을 수 있음
SQL 사용 시 도시 데이터는 NoSQL, 사용자 정보나 장소 정보는 SQL로 관리하면 좋을 듯
MongoDB 사용 시 odm으로 mongoose 사용
MongoDB가 node.js와 궁합이 좋음
- 단순한 I/O 작업을 빨리 처리할 수 있음
- Non-Blocking + Async + 싱글 스레드 방식으로 처리할 경우 더 효율적
- I/O의 처리 순서가 중요하면 RDBMS를 사용
유저, 장소 → 북마크, 내일 갈 거야는 관계 설정이 필요할까?
- 일단 구현 과정에서 확인하자
- 관계 설정이 필요할 시 mongoose의 populate 메서드 사용 가능
  - 이 경우에는 하위 다큐먼트를 다 찾아야 해서 성능이 저하될 수 있음

2.2.2. Nginx, 로드밸런싱

보안성 측면에서 좋음
- https 사용
써서 나쁠 건 없음

2.2.3. 백엔드 라이브러리 → koa

koa
- 미들웨어 기능만 제공해서 가벼움
  - Mildo의 백엔드는 api 받아와서 serving만 함
  - ssr을 안하기 때문에 템플릿 기능 필요 없음
- req, res를 합쳐서 ctx로 사용하여 문법적으로 편함
- async-await을 공식적으로 지원함
  - Mildo는 api 요청이 많을 것으로 보임
  - 콜백 지옥 탈출 가능
- 다만, express 대비 참고 자료가 많이 없음
express
- 미들웨어, 라우팅만 필요한데 express는 다른 기능도 많음
- async-await 에러 처리에서 어려움이 있을 수 있음

2.3. 공통

2.3.1. CSR vs SSR → CSR

Mildo의 특징
- 웹 애플리케이션 느낌으로, 레이아웃이 고정되어 있음
- 하나의 페이지만 존재하고, 부가적인 기능은 모두 모달로 구현
  - 매번 html을 불러오는 것보다 csr로 해당 부분만 변경하는 것이 좋지 않을까?
- 보안 관련
  - 서울시 도시 데이터 API는 원래 공개되어 있음
  - 로그인은 네이버 Oauth로 구현하니까 별도의 보안이 필요하지 않음
- 서버에서 API 요청이 많은 것으로 예상
  - 서버에서 crontab, node-cron 등을 사용해서 지속적으로 서울시 도시 데이터 API 요청
  - API 불러오는 시간에 ‘로딩 중’ 화면 보여줘서 사용자 경험 개선할 수 있음
CSR(SPA)
- 하나의 html 파일 사용
  - html을 클라이언트에서 조립
- 초기 렌더링 속도가 느릴 수 있음
- 부분 렌더링에 더 최적화
SSR
- CSR 대비 초기 렌더링이 빠르고 보편적으로 라이트하우스 스코어가 높을 가능성
- 검색 엔진 최적화(SEO)에 유리
  - CSR의 경우 검색 크롤러가 js를 동작시키지 않아 빈 페이지로 인식될 수 있음
  - 렌더링이 더 빠름
- CSR 대비 서버에서 더 많은 리소스를 사용
  - html을 서버에서 만들어서 보내줌
- 전체 페이지를 다시 렌더링
- Next.js 사용하려면 러닝커브 발생

2.3.2. JS vs TS → TS

TypeScript(상준, 현정, 윤우)
- 타입을 엄격하게 체크해서 협업 시 좋음
- Mildo에서 불러오는 API 데이터는(밀도, 인구수, 위도, 경도 등) 숫자 데이터가 많음
- 앱 자체가 데이터를 뿌려주는 것이 주 기능이기 때문에 필요할 것 같음

2.3.3. 테스트

단위 테스트
- 종류
  - Jest
  - Mocha
- 굳이 할 필요가 있을까..? 황준일 마스터님도 단위 테스트는 잘 안 한다는 듯이 말하셨음
- 필요한 경우에만 Jest + RTL
인수 테스트
- Cypress
  - 재밌을 것 같다.
UI 테스트
- storybook
인수 테스트, UI 테스트는 마지막 주에 몰아서 하자.

2.3.4. CI/CD

Github Actions
매번 배포할 때마다 코드 수정을 업데이트 하는 것이 불편하고 오래 걸리기 때문에 이런 부분에 대해 자동화하여 쉽고 빠르게 배포할 수 있음

2.3.5. Docker, k8s

Docker
- 컨테이너를 이용해서 개발환경, 배포환경을 통일성 있게 만들어줌
k8s
- 컨테이너를 자동화하는 도구
Docker는 분할해서 배포할 때 장점이 있을 것 같다.
수요일까지 공부하고 상의

2.3.6. 클라이언트 서버(WebServer) / API 서버 나누기(WAS)

서버 부하 방지 가능
- 정적 컨텐츠는 WS가 제공하고 동적 컨텐츠는 WAS가 제공
- 만약 정적 컨텐츠도 WAS가 제공한다면 동적 컨텐츠 처리가 지연됨에 따라 수행속도가 느려짐
WAS의 환경설정 파일을 외부에 노출시키지 않을 수 있음
- 클라이언트와 연결하는 포트가 직접 WAS에 연결되어 있다면 중요한 설정 파일들이 노출될 수 있음
- WS와 WAS를 분리하면 접근하는 포트가 다르기 때문에 방화벽을 쳐서 보안 강화 가능
여러 대의 WAS 연결 가능
- 로드밸런싱 가능 → 크롤링을 다른 서버로 판다면 로드밸런싱이 필요할 수도 있음
- 장애 극복 가능

2.3.7. 패키지 매니저(의존성 관리 툴) → Yarn classic

모노레포를 구현해야 할까? → 참고
만약에 모노레포가 필요한 경우에는 Lerna + Yarn이 어떨까..

npm
- 우리 프로젝트 크기가 작으므로 npm도 나쁘지 않을 듯
yarn
- 보안, 일관성 이슈를 해결하기 위해 등장
- Native 모노레포 지원
- 새로운 lock 파일 형식
- 새로운 버전 yarn berry 등장
- 리액트 설치 시 npm은 3.5초, yarn은 1.4초
- npm과 비슷해서 러닝커브가 거의 없음
yarn berry
- 에러 많이 난다는 사람들의 의견
- Yarn classic에 호환되지 않음
- Plug n play & Zipfs를 이용한 의존성 관리
- 플러그인 친화적
- Monorepo를 위한 workspace 기능 강화
pnpm
- Performant npm의 줄임말
- 플랫하지 않은 node_modules 구조
- 하드링크를 사용해 하드디스크 용량 절약
- 심볼릭 링크를 통한 빠른 탐색

2.3.8. 번들링 도구 → ★비교를 위해 cra와 vite를 모두 사용해보면 좋을듯

거의 한 페이지 안에서 동작하므로 번들링 도구가 필요하다고 생각함
참고

Vite
- 빠르다
  - Go 언어 기반이기 때문에 CRA보다 빠르다.
  - CRA는 자바스크립트 기반이기 때문에 느리다.
- CRA에서 자동으로 해주는 설정을 별도로 해야함
  - 다만, 마이그레이션 가능(https://zih0.tistory.com/44)
  - 토이 프로젝트에서도 거의 2배가 빠른 성능을 보이므로, 규모가 작은 우리 프로젝트에 적용해도 괜찮을 것 같음
- CRA를 안 썼을 때 추가적으로 무엇을 깔아야 하는지 학습할 수 없으므로 먼저 CRA를 쓰고 Vite를 결합하자
CRA
- 프로젝트 규모가 커지면 빌드 시간이 오래 걸림
- 다만, 너무 편함

2.3.9. Prettier, esLint

esLint, prettier
- 네이버 컨벤션에서 필요한 것만 추가/변경 → 필요하지 않은 부분은 ‘삭제’

🏉기술 스택 회의 - boostcampwm-2022/web33-Mildo GitHub Wiki

1. 개요

2. 고려 사항

2.1. 프론트엔드 스택

2.1.1 React.js vs 바닐라js → React.js

2.1.2. 전역 상태 관리 라이브러리 → jotai

2.1.3. 스타일 → Styled-Component

2.2. 백엔드

2.2.1. DB → MongoDB

2.2.2. Nginx, 로드밸런싱

2.2.3. 백엔드 라이브러리 → koa

2.3. 공통

2.3.1. CSR vs SSR → CSR

2.3.2. JS vs TS → TS

2.3.3. 테스트

2.3.4. CI/CD

2.3.5. Docker, k8s

2.3.6. 클라이언트 서버(WebServer) / API 서버 나누기(WAS)

2.3.7. 패키지 매니저(의존성 관리 툴) → Yarn classic

2.3.8. 번들링 도구 → ★비교를 위해 cra와 vite를 모두 사용해보면 좋을듯

2.3.9. Prettier, esLint

⚠️ GitHub.com Fallback ⚠️

🏉기술 스택 회의 - boostcampwm-2022/web33-Mildo GitHub Wiki

1. 개요

2. 고려 사항

2.1. 프론트엔드 스택

2.1.1 React.js vs 바닐라js → React.js

2.1.2. 전역 상태 관리 라이브러리 → jotai

2.1.3. 스타일 → Styled-Component

2.2. 백엔드

2.2.1. DB → MongoDB

2.2.2. Nginx, 로드밸런싱

2.2.3. 백엔드 라이브러리 → koa

2.3. 공통

2.3.1. CSR vs SSR → CSR

2.3.2. JS vs TS → TS

2.3.3. 테스트

2.3.4. CI/CD

2.3.5. Docker, k8s

2.3.6. 클라이언트 서버(WebServer) / API 서버 나누기(WAS)

2.3.7. 패키지 매니저(의존성 관리 툴) → Yarn classic

2.3.8. 번들링 도구 → ★비교를 위해 cra와 vite를 모두 사용해보면 좋을듯

2.3.9. Prettier, esLint

⚠️ **GitHub.com Fallback** ⚠️

⚠️ GitHub.com Fallback ⚠️