[ 토스 기술 블로그 ] SLASH 21 - Day 2 Micro-frontend React, 점진적으로 도입하기

 

Micro-frontend React, 점진적으로 도입하기

 

Django MVC 프로젝트가 Micro-frontend React 프로젝트가 되는 이야기

 

웹 개발을 하다보니 한계를 느껴 React를 점차 도입하기로 했음

 

저희, CRA로 시작해볼까요 ?

 

하지만 Django에 조금씩 도입하는 과정에서 CRA로 하는 방법은 옳지 않았음

 

webpack 빌드의 결과물을 Django에 삽입하기 위해 ( Django는 템플릿 언어이다 )

 

webpack-bundle-tracker라는 webpack 플러그인과

 

django-webpack-loader라는 플러그인 이었음

 

결과적으로 잘 바꾸는데에 성공함 하지만 문제가 또다시 발생했음

 

의존성 문제

하나의 패키지에서 하나의 webpack 설정을 사용하다보니 다른 패키지에서 사용하는데 의존성 문제가 발생하기 시작했음

 

A,B서비스가 있을때 둘이 코드는 공유하지 않지만 X라는 의존성 패키지를 사용한다고 했을때 문제가 발생하게 됨

 

이는 flutter 했을때 많이 겪어봐서 알지만 정말 골이 아픈 문제임

 

또한 빌드 시간도 많이 느려지는 문제를 겪게 되었음

 

Micro frontend Architecture

이러한 문제를 해결하기 위해 마이크로 프론트엔드 아키텍쳐를 선택하게 되었음

 

3가지로 구분을 했는데

인프라 패키지

빌드 툴링을 공유하기 위한 인프라 패키지

 

라이브러리 패키지

공통 소스코드를 관리하기 위한 라이브러리 패키지

 

서비스 패키지

페이지에서 독립적으로 작동하는 서비스 패키지

 

구현 방법

최초구현 

Yarn Workspace + Lerna

 

현재구현

Yarn2 Workspace + Plugin

 

장점

패키지 별로 독립적으로 작동해서 의존성 문제를 해결할 수 있음

 

빌드 속도 또한 최적화 할 수 있음

 

-> 결과적으로 토스 사내 문화와 맞는 방법이 되었음

 

빌드 속도는 어떻게 최적화 했을까?

이 부분이 신선했는데 바로 Git의 hash값을 이용한 것이었음

 

 

빌드 속도를 줄이려면 빌드를 하지 않으면 된다

 

뭔소리야;

 

소스코드가 바뀐 패키지만 빌드를 하고 

 

나머지는 기존 빌드 결과물을 재사용하는 것이다.

 

이것을 활용하기 위해 Git의 hash값을 사용했는데

 

Git의 커밋 아이디는 그 커밋에 포함된 모든 파일의 해시를 누적시킨 결과와 동일하다는데

 

각각의 파일은 깃에서 blob으로 처리하고 각각의 blob에 대해 해시를 계산한다.

 

결국 tree가 변경되었는지 알고 싶다면

 

이전 커밋의 해시와 현재 커밋의 해시를 비교하면 된다고 한다.

 

이렇게하면 간단한 연산으로 비교할수 있다고 한다.

 

토스가 채용공고를 보면 Yarn 패키지에 대해서 우대사항이 있는데 왜 그런지 알 것 같다;;