Skip to content

Latest commit

 

History

History
28 lines (22 loc) · 3.04 KB

모듈페러데이션-공유의존성.md

File metadata and controls

28 lines (22 loc) · 3.04 KB

모듈 페더레이션의 공유 의존성이란 뭘까?

  • 공유 의존성은 런타임에 로드되는 앱의 빌드타임에 공유 의존성에 정의된 모듈을 별도 청크로 분리하여 번들링함.
  • 런타임에서 앱이 로드 될 때, 해당 공유 의존성을 사용하면서 먼저 로드되는 앱의 런타임에 미리 분리된 청크를 로드하여 의존성을 사용함.
  • 무조건 호스트앱의 의존성 청크가 로드되리라는 법은 없고, 리모트앱이 먼저 로드된다면 리모트앱의 의존성 청크가 로드되기도 함.

순서

  1. 런타임에 로드되는 앱의 빌드타임에 공유 의존성에 정의된 모듈을 별도 청크로 분리하여 번들링함.
  2. 런타임에서 앱이 로드 될 때, 해당 공유 의존성을 사용하면서 먼저 로드되는 앱의 런타임에 미리 분리된 청크를 로드하여 의존성을 사용하게 함.
  3. 이어 로드되는, 해당 공유 의존성을 사용하는 앱의 먼저 불러온 공유의존성은 따로 로드하지 않고, 이미 로드된 청크에서 의존성을 사용할 수 있게함.
  4. 만약 먼저 불러온 공유 의존성이 로드된 마이크로앱에서 사용한다고 정의한 의존성과 버전이나 share scope이 맞지 않을 경우 해당 앱은 자신의 빌드 번들에서 공유 의존성에 대한 번들을 꺼내서 씀

장점

  1. 런타임에서 마이크로앱 간 많이 쓰이는 의존성에 대해 해당 의존성을 런타임에 딱 한번만 로드하면 됨. 따라서 모든 마이크로앱에서 해당 의존성을 가질 필요가 없다.
  2. 앱 전역에서 단일 인스턴스 보장가능
    • 런타임에서 앱이 합체되는 마이크로프론트엔드에서는 배포/개발은 결국 따로하지만 브라우저는 하나의 앱임. 백엔드의 마이크로서비스와 다르게 완전히 격리된 환경에서 각 마이크로앱이 구동되는게 아님!
    • 앱 최상위에서 Context Provider를 두고 같이 공유해야하는 경우 사용 가능
    • 하나의 앱의 모든 부분이 일관된 동작을 하도록 하려면 앱 전역에서 의존성 인스턴스를 딱 하나로만 맞춰줘야 하는 경우가 생김
    1. var, window와 같은 전역 변수를 사용하는 라이브러리
      • 라이브러리 내에서 런타임에 let으로 변수 재할당, var과 같은 전역변수를 사용하는 경우. 인스턴스가 2개 이상이면 동시성 이슈가 있을 수 있음
    2. 스타일과 관련된 라이브러리 일부
      • css-in-js 라이브러리의 인스턴스가 여러개라면, 같은 스타일이 두 번 적용된다거나 하는 문제 때문에 스타일링이 의도대로 되지 않을 수
      • 런타임에 문제가 없더라도, 앱의 일관된 동작을 보장하기 위해 스타일 관련한 라이브러리의 인스턴스를 앱 전체에서 하나로 맞춰야할 수 있음
    3. 앱 최상위에 Context Provider등을 두고 써야 하는 라이브러리

다만 공유 의존성 사용 시 트리쉐이킹 불가능