Why micro-frontends?

서문에

전편 Micro Frontends 에서 개념 정의 및 구현 사고로부터마이크로 프런트엔드란 무엇인가를 탐구했지만, 마이크로 프런트엔드를 완전히 이해하려면, 이러한 문제들을 명확히 할 필요가 있습니다:

왜 마이크로 프런트엔드가 필요한가?
마이크로 프런트엔드는 무엇을 해결할 수 있는가? 컴포넌트화로는 해결할 수 없는가?
마이크로 프런트엔드는 도대체 무엇을 가져왔는가? 다기술 스택 병존? 통일된 기술 스택은 안 되는가?

一.배경: 왜 마이크로 프런트엔드가 필요한가?

최��의 HTML 인라인 스크립트에서, 9102 년의 수십만 행의 JavaScript 코드까지, 프런트엔드는 점점 더 무거워졌습니다:

수 G 의 프런트엔드 코드 라이브러리
수백 명의 프런트엔드 개발자
수 MB 의 Bundle Size

점점 더 복잡해졌습니다:

계속적으로 나타나는 프레임워크, 라이브러리
다양한 공업화 체계
특색있는 크로스엔드 실천

따라서복잡도를 분해하고, 협업 효율을 향상시키고, 유연한 확장을 지원하는 아키텍처 패턴이 필요하게 되었고, 그래서, 마이크로 프런트엔드 가 무대에 등장했습니다

二.적용 시나리오: 마이크로 프런트엔드는 무엇을 해결할 수 있는가?

마이크로 프런트엔드의 이념은 마이크로 서비스와 유사하여, 방대한 전체를 제어 가능한 작은 블록으로 분해하고, 그들 간의 의존 관계를 명확히 합니다.

분할 자치, 다기술 스택 병존을 지원하는 방식을 통해, 프런트엔드 애플리케이션이 직면한 다양한 문제를 해결합니다:

업무 모듈 간에 날로 격화되는 결합을 어떻게 관리하는가?
개발 팀을 어떻게 분할, 해체하여, 병행 개발의 목적을 달성하는가?
새로운 프레임워크, 새로운 방안을 어떻게 기존의 공업 환경 (구축 도구 등) 에 적응시키는가?
오래된 프레임워크 라이브러리를 어떻게 평온하게 업그레이드하는가?

업무 기능에 따라 한 덩어리의 프런트엔드 애플리케이션을 일련의 더 작고, 더 응집된 마이크로 프런트엔드 애플리케이션으로 분해하고, 동시에 명확한 교호 프로토콜을 통해 이러한 애플리케이션 간의 의존 관계를 관리하여, 다른 업무 모듈의 해체를 실현합니다. 그리고 각 마이크로 프런트엔드 애플리케이션을 독립 팀에 맡겨, 각각 독립적으로 개발하고 독립적으로 배포하며, 병행성을 충분히 이용합니다

한편, 다기술 스택 병존 능력의 가피 하에서, 저비용으로 새로운 기술 실천을 도입할 수 있을 뿐만 아니라, 저위험으로 제품의 국부 기능을 치환하는 것을 허용하며, 의존항 업그레이드, 아키텍처 교체, UI 개판 등의 중대한 결정都能以 점진적인 방식으로 평온하게 착지할 수 있음을 의미합니다:

분해: 애플리케이션을 일련의 소형 애플리케이션 (자 애플리케이션) 으로 구성되는 애플리케이션으로 분할
치환: 자 애플리케이션을 치환
조합: 치환한 것이 화합하여 작업할 수 있음을 보증

마이크로 프런트엔드 프레임워크를 통해 애플리케이션 간의 주종 관계를 확립하고 (1 개의 컨테이너 애플리케이션 + n 개의 자 애플리케이션), 다음에 국부 치환을 수행하여, 모두 완료될 때까지 수행합니다. 그러나, 실천에서는 통상 리팩토링과 동시에 신특성의 지속적인 이터레이션을 보증할 필요가 있으므로, 실제 플로우는 다음과 같을 수 있습니다:

추상: 일층의 주종 관계를 추가, 예를 들어 프런트엔드 루트를 통해 제어
확장: 신규 자 애플리케이션
조합: 원래 애플리케이션을 직접 한 덩어리의 자 애플리케이션으로, 신특성 (신규의 자 애플리케이션) 을 가지고 온라인
리팩토링: (시간상으로 확장과 병진 가능) 원래 애플리케이션을 분해, 치환

리팩토링 등의 작업을 비교적 긴 시간 폭도 하에서 제어 가능한 점진적으로 완료시키고, 일도절의 리소스 요구와 변경 리스크를 부담할 필요는 없습니다

컴포넌트화로는 해결할 수 없는가?

The problems they're supposed to solve sound to me like they're already solved by a good component model. So is this solving an organizational issue rather than technical one? Such as if two teams can't agree on anything, even shared infra.

(I don't understand micro-frontends. 에서 인용)

확실히, 컴포넌트화でも 분할 자치를 실현할 수 있습니다. 예를 들어 React 에서는 React.lazy + Suspense 의 방식으로 우아하게 코드 분할을 완료할 수 있습니다

하지만 이는 컴포넌트 모델이 통일 (또는 기술 스택이 일치) 하고 있는 전제 하에서 성립하며, 마이크로 프런트엔드의 절반의 또 하나의 우세는단일 기술 스택의 제한을 타파할 수 있는 것입니다:

They are microservices in the browser. Meaning separately built and deployed frontend apps that can choose their own framework and libs. The purpose is organizational scaling and avoiding framework lock-in.

이는 컴포넌트화, 모듈화 등의 방안으로는 만족할 수 없습니다. 마찬가지로, git submodule, npm module 등의 분할 방안도 직접 다기술 스택 병존의 능력을 제공할 수 없습니다

三.의의: 마이크로 프런트엔드는 도대체 무엇을 가져왔는가?

공업 가치

절반은 모듈화가 가져오는 이점에서, 예를 들어:

개발 효율의 향상: 다업무선의 병행 개발, 팀 자치, 독립 이터레이션

-交付コスト의 저감: 애플리케이션 레벨의 기능复用

운용 리스크의 저감: 변경 범위의 축소

또 절반은 다기술 스택 병존 능력이 가져오는 이점에서:

기술 선택의 증가: 단일 기술 스택에 捆绑되지 않게 되어, 새로운 기술, 새로운 교호 모드의 실험적 시행착오에 도움
复用성의 강화: 기술 스택의 차이가 더 이상 기능 复用의 장벽이 아니며, 제 3 자 모듈에게 특히 중요
리팩토링 리스크의 저감: 저위험 국부 치환, 점진적으로 대규모 리팩토링을 완료

물론, 다기술 스택의 병존을 허가하는 것은, 가능한 한 많은 기술 스택을 도입하는 것을 장려하는 의미는 아닙니다. 더 적은 기술 스택이 통상 기초시설 건설, 리소스 复用과 경험 공유에 더욱 유리하기 때문입니다

상업 가치

마이크로 프런트엔드의 시각에서의 Web 애플리케이션은 일련의 독립 기능의 조합입니다:

The idea behind Micro Frontends is to think about a website or web app as a composition of features which are owned by independent teams.

(What are Micro Frontends? 에서 인용)

따라서, 마이크로 프런트엔드 애플리케이션은 클라우드 컴퓨팅의 배경하의 클라우드 서비스처럼 즉취즉용 할 수 있어, 애플리케이션 모듈 레벨 (제 3 자) 기능의接入/融合을 실현하며, 그 상업 가치는:

세밀한 입도, 조합 가능한 프런트엔드 제품 형태: 프런트엔드 제품/능력을 더욱 세밀한 입도, 더욱 유연한 형태로 출력 (클라우드 서비스처럼 필요에 따라 자유 조합)
마이크로 프런트엔드 애플리케이션 생태: 규범화된 마이크로 프런트엔드 애플리케이션은 생태를 형성할 수 있어, 더욱이 소프로그램에 유사한 플랫폼 체계를 발생

참고 자료

Micro Frontends
[I don't understand micro-frontends.](https://medium.com/ @lucamezzalira/i-dont-understand-micro-frontends-88f7304799a9)

서문에