Module Federation의 공유 의존성 (Shared Dependency)

Module Federation 동작 방식

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

• 위의 과정에서 무조건 호스트앱의 의존성을 사용하리란 보장이 없다. 리모트앱이 먼저 로드되면 리모트앱에 있는 해당 의존성을 사용한다.

최적화가 가능하다.

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

특징

• 트리쉐이킹이 안된다. 각 마이크로앱들은 모듈 전체를 빌드 결과물에 가지고 있다.
• 개별 분리될 마이크로앱에서 사용할 모듈과, 모듈의 구현체가 뭔지 모르는데 어떻게 트리쉐이킹을 하냐! 라고 웹팩 메인테이너가 말함. 즉 앞으로도 될 일 없음.