대형 웹 애플리케이션 Micro Frontends 전환기

as-is

• 17개로 분리된 Next.js 앱
• 그것보다 많은 공용 패키지와 참조
• 200개 이상의 url
• 8.7gb의 전체 코드베이스
• 페이지별로 앱이 나누어져 있음

문제점

• 유저에게 하나의 앱을 쓰는 경험을 전달 할 수 없다.
• 스쿼드 독립적, 효율적인 개발이 힘들다.
• flex 앱에서 다른 앱으로 넘어가기만 해도 앱에 필요한 html 부터 모든 자원을 다시 가져와야하는 구조
  • 페이지간 공통 UI는 공유되지만, 유저는 다른 페이지로 넘어가면 로딩바를 다시 보거나 이미 이전앱에서 불러왔던 모든 기능들을 다시 불러내서 사용해야함.
• 또한 GNB (네비게이션바 - 공통UI)는 모든 앱에서 import 해서 사용하고 있었음 (빌드타임통합)
  • 이러다보니 GNB에 문제있을 경우 모든 앱을 다 롤백해줘야하는 문제

-> 해결방법은 모듈페더레이션 (런타임 통합)

Module Federation

• 런타임에 각각의 분리된 앱을 함침
• 분리된 앱들이 각각의 개발 프로세스를 거쳐서 자바스크립트 번들의 형태로 배포
• 각각의 마이크로앱들(호스트앱)에서 번들형태로 리모트앱을 불러와 각각따로 렌더링됨

MF를 통해 아래와 같이 문제해결함

• 런타임에 하나의 앱이 됨 (유저에게 하나의 앱을 쓰는 경험)
• 배포단위를 더 작게 쪼게서 런타임 통합 가능 (팀끼리 독립적으로 일할 수 있음)

마이그레이션 과정

• 달리는 차에서 다른 차로 폴짝 뛰는 경험이었음
• 기존 앱을 프로덕션으로 띄우고 마이그레이션 한 앱 유지
  • 프레임워크와 관련없는 부분은을 통해서 마이그레이션된 앱에서도 추가된 기능이 붙여짐

그러면 next.js에 종속적인 코드는?

• 빌드하는 시점에 바꿔줌
• 원래도 next.js에서 사용하는 기능들은 flex 내부 라이브러리로 한번 랩핑되어있었음
• 예를들어... @flexteam/next-router 를 @flex-mf/react-router로 대체하도록 웹팩 리졸브 alias 설정