서버사이드 모놀리식 mvc 장고 템플릿
리액트 도입, 마이크로 프론트엔드 아키텍처 도입 이유, 후기,빌드시간 단축 방법
toss internal 사내 업무용 포탈 직접 개발, 부분적으로 react 적용. cra로 프론트엔드 빠르게 셋업. => 절대 하지 말자. 장고와 함께하는 상황에서는 cra가 제공하는 설정이 필요가 없었고, 그냥 처음부터 from scratch(하나부터)로 만드는 쪽이 나았음. 처음에는 적은 비용으로 시도를 위해서 cra.
webpack-bundle-tracker 웹팩 플러그인
웹팩 빌득 결과물의 청크 정보를 json에 추출
django-webpack-loader 장고 앱
적정한 script나, link를 json을 보고서 추가하는 방식으로 했음
webpack entrypoint로 구분 되지만, 하나의 웹팩 빌드로 묶였음
의존성 관리가 심각해짐
A,B서비스가 공유하는 의존성 X 패키지. X가 이론적으로 완벽하게 작동하지 않다면 버전만 바뀌면 터지는 상황같은 것들이 정말 어려워짐
긴 빌드시간 문제
개발 생산성의 문제가 정말 커다란 부분이 있었음
MFA를 선택 거대한 소스코드를 독립적인 패키지로 분리하고 각각을 빌드했음 패키지는 유지보수 단위로 구분
1. 빌드툴링을 공유하기 위한 인프라 패키지
2. 공통 소스코드를 관라하기 위한 라이브러리 패키지
3. 페이지에서 독립적으로 작동하는 서비스 패키지
Yarn workspace와 lerna로 작동
현재는 yarn2, workspace plugin
패키지별 독립적인 의존성. 패키지별로 영향 범위를 조절 가능했음
빌드 속도도 해결할 수 있었음
MFA가 도입되며 제품 전략면에서 독립된 제품들이 기술적으로도 독립됨
독립적으로 의존성을 결정하고, 독립적으로 작성할 수 있기에 더 빠른 생산성이 만들어졌음
빌드 시간을 줄이는 방법 대신 빌드를 안하는 방법도 고민
소스코드가 바뀐 패키지만 빌드. incremental build를 하는 것
monolith식으로 작동할 때는 너무너무 힘듦. MFA는 훨씬 편해짐 패키지 단위로 바뀐 부분만 빌드하는 법으로 충분히 가능해짐. 바뀌었다는 부분을 확인하는 방법은 git을 활용함.
git의 커밋 id는 커밋에 포함된 모든 파일의 해쉬를 누적시킨 값과 같음
각각의 파일은 git 내부에서 blob으로 처리되고, 각각의 blob에 대해서 해쉬 계산.
트리로 처리되고, 트리의 해쉬는 모든 원소에 대한 것들이 있음
기존 빌드 결과물은 그냥 git에다가 저장해버림. 개발자가 pull 받기만 하면, 이미 다운로드 되어버리는 상황. 압축해서 저장하는 방식
Yarn Zero-Installs 과 유사하게 작동한다고 봐도 됨. 속도가 최대 15배까지 줄어들었음
관리자 권한으로
corepack enable
터미널에서
yarn init -2
zero install version git ignore
.yarn/*
!.yarn/cache
!.yarn/patches
!.yarn/plugins
!.yarn/releases
!.yarn/sdks
!.yarn/versionsnot using zero install
.pnp.*
.yarn/*
!.yarn/patches
!.yarn/plugins
!.yarn/releases
!.yarn/sdks
!.yarn/versionsyarn 버전 관리 최신이 아닌 경우나, 가장 최신 버전
yarn set version from sources
yarn set version from sources --branch 1211- npmrc 파일을 yarn rc 파일로 변경
npm config edit으로 npmrc 찾기 가능
https://next.yarnpkg.com/getting-started/usage
yarn 에 대한 기본 커맨드들 보기
vscode 에다가 zipfs 설치
https://levelup.gitconnected.com/how-to-use-yarn-3-with-react-native-and-how-to-migrate-c5f108108533
rn이 섞여 있다면 제대로 zero install을 쓸 수는 없지만, 거의 대부분의 install 시간을 줄일 수 있을 정도까지는 만들 수 있다.
그래도 해결책이 nodelinker:nodemodules 가 있긴 하다 정도... 결국 완벽한 pnp를 쓸 수는 없다
이미 세팅이 되어 있는 환경이라는 부분을 간과했다.
migration 가이드를 보면 해결책이 나옴
