독립적으로 소유하고 배포 가능한 프론트엔드 애플리케이션으로 구성된 마이크로 프론트엔드의 개념과 작동 방식 2016, 그리고 하나의 2024 survey에서 23.6% respondents가 이전 년도에 마이크로 프론트엔드를 사용한 것으로 보고되었다. 75.4% in 2022. 이 문제를 이미 해결하고 계신가요? 세 개의 제품 팀이 하나의 프론트엔드 저장소에 공유하고 동일한 릴리즈 트레인에 기다리며, 하나의 팀이 체크아웃을 변경하고 다른 팀이 프로필을 업데이트하고 세 번째 팀이 마케팅 페이지를 조정하는 경우도 있습니다. 마이크로 프론트엔드 아키텍처는 제품 영역을 분리하여 팀이 독립적으로 소유, 테스트, 릴리즈할 수 있도록 사용자들은 여전히 하나의 애플리케이션을 경험할 수 있도록 합니다.
그 차이점은 중요합니다. 마이크로 프론트엔드는 작은 폴더, 컴포넌트, 또는 번들만이 아닙니다. 그들의 중심적인 목적은
소유권과 릴리즈 독립성 독립적인 조직 및 릴리스 independance목차
컨텍스트: Capgo 마케팅 웹사이트. 역할: 짧은 UI 레이블 또는 네비게이션 아이템. 위치: 페이지 blog/[slug].astro. 메시지 키 `table_of_contents` (목차)
- 마이크로 프론트엔드 개념 이해
- 마이크로 프론트엔드 아키텍처의 작동 방식
- 핵심 마이크로 프론트엔드 패턴 비교
- 혜택, 트레이드 오프 및 숨겨진 위험
- 테스트 배포 및 마이그레이션 연습
- Capacitor와 Electron에서 Micro Frontends 사용
- Micro Frontends를 선택하는 시점
Micro Frontend 개념 이해
한 frontend에서 여러 소유 애플리케이션으로
A 전통적인 frontend은 하나의 저장소, 하나의 빌드, 하나의 배포 경계를 가지고 있습니다. code이 기능 폴더로 분리되어도, 폴더를 관리하는 팀은 여전히 동일한 PIPELINE과 릴리즈 스케줄에 의존할 수 있습니다. 한 영역에서 작은 변경이 발생하면 전체 애플리케이션 빌드, 공유된 리그레션 테스트, 모든 팀의 협조가 필요합니다.
A micro frontend은 브라우저 애플리케이션을 기능별로 분할합니다. 사업 기능. 체크아웃 팀은 체크아웃을 관리하고, 프로필 팀은 계정 설정을 관리하며, 마케팅 팀은 프로모션 콘텐츠를 관리합니다. 각 슬라이스는 독립적인 코드베이스, 배포 프로세스, 릴리즈 캘린더를 가질 수 있으며, shell 또는 구성 레이어를 통해 더 큰 경험을 제공할 수 있습니다.
Martin Fowler는 패턴을 다음과 같이 정의합니다. “ Independently deliverable frontend applications은 더 큰 전체로 구성되는 아키텍처 스타일입니다.” 그의 기초적인 마이크로 프론트엔드 아키텍처 가이드에서 설명합니다.
frontend applications
상점을 생각해 보세요. 하나의 팀이 매장 전면부를 관리하고, 다른 팀이 체크아웃 카운터를 운영하고, 또 다른 팀이 반품을 처리합니다. 고객은 하나의 상점만 보지만 각 영역은 서로 다른 프로세스, 책임, 직원과 같습니다. 마이크로 프론트엔드는 브라우저가 하나의 제품 경험을 렌더링하는 동안 여러 팀이 뒤에서 각 인터페이스 영역을 운영하는 것과 유사하게 작동합니다.
앱 셸은 일반적으로 공유 프레임, 네비게이션, 인증 컨텍스트, 경로 결정과 같은 공유된 요소를 소유합니다. 마이크로 프론트엔드는 그 안에 있는 페이지 또는 기능을 소유합니다. 팀들은 그들 사이의 경계를 합의하지만, 그들은 모든 구현 세부 사항을 공유할 필요가 없습니다.
이 용어는 2016년 11월 Thoughtworks가 기술 라이다에서 이를 강조한 후에 브라우저에 대한 확장된 마이크로 서비스思 想을 연관시켰습니다. Fowler는 이후 Assess에서 Trial로, 그리고 Adopt로 문서화하여, 이 패턴의 진행을 Assess에서 Trial로, 그리고 Adopt로 문서화하여, 이 패턴의 진행을 설명했습니다. 이는 패턴이 emerging 기술에서 더 확립된 아키텍처 옵션으로 이동하는 것을 설명합니다. 웹 개발의 확장성plugin architecture guide에 대해 논의됩니다. 이 패턴은 plugin architecture와 같은 근접한 접근법과 비교하는 것이 도움이 됩니다..
마이크로 프론트엔드의 중요한 교훈은 모든 인터페이스에 대한 기본적인 업그레이드가 아니라는 것이다. 팀 경계와 릴리즈 경계가 실제로 고통을 일으키면 의미가 있다. 독립성을 관리하는 데 더 많은 계약, 자산, 런타임 실패 모드 및 운영 도구가 있기 때문에 비용이 정당화된다.
마이크로 프론트엔드 아키텍처의 작동 방식
쉘과 프래그먼트
작동하는 시스템은 일반적으로 앱 쉘또는 컨테이너 또는 오케스트레이터라고도 함. 쉘은 공통 레이아웃을 렌더링하고, 라우팅을establish, 인증 컨텍스트를 제공하고, 공유 인터페이스 요소인 네비게이션 또는 알림과 같은 요소를 제공한다. 또한 어떤 마이크로 프론트엔드를 로드하고 그 프래그먼트를 어디에 마운트할지 결정한다.
각 프래그먼트는独立적으로 관리되는 애플리케이션이다. 그것은 별도의 저장소에서 살 수 있고, 자신의 CI pipeline을 사용할 수 있고, 자신의 버전을 내릴 수 있고, 배ंडल, 프래그먼트, 웹 컴포넌트 또는 원격 모듈을 노출할 수 있다. 쉘은 브라우저에서 그 조각을 합성한다. 페이지가 로드될 때 또는 라우트가 그들을 필요로 할 때.
경계가 의미가 있다면 팀이 그것에 의존할 수 있어야 한다. 쉘과 각 프래그먼트는 마운트 동작, 라우트 소유권, 로딩 상태, 오류 처리, 디자인 토큰, 접근성 기대치 및 지원되는 의존성 버전에 대한 명시적인 계약이 필요하다.
실용적인 규칙: 공유 계약과 시각적 기본 요소를 의도적으로 공유하십시오. 단순히 두 팀이 동일한 프레임워크를 사용하고 있기 때문에 런타임 구현 세부 정보를 공유하지 마십시오.
모노리딕 재현 없이 의사소통하십시오.
프래그먼트가 때때로 서로에게 통신해야 합니다. 체크아웃 슬라이스가 사용자가 로그인한 것을 알 필요가 있을 수 있으면, 프로필 슬라이스가 계정 업데이트 이벤트를 게시해야 할 수도 있습니다. 팀은 사용자 정의 브라우저 이벤트, 공유 저장소, URL 매개 변수, 또는 주입 서비스를 사용할 수 있습니다.
모든 옵션은 다음과 같은 다른 결합 프로파일을 생성합니다:
- 사용자 정의 이벤트 소유권을 분리하지만 팀은 이벤트 이름, 데이터 형태, 및 타이밍을 문서화해야 합니다.
- 공유 저장소 협調된 상태를 단순화하지만, 중앙 의존성 그래프를 재현할 수 있습니다.
- URL 매개 변수 이동 및 공유 상태에 적합하지만, 모든 상호 작용에 적합하지는 않습니다.
- 주입 서비스 제어된 기능을 제공하지만, 쉘은 서비스 계약을 유지해야 합니다.
애플리케이션의 전체적인 부분에 속하는 것만 shell이 조정해야 한다. 만약 모든 프래그먼트의 상태와 비즈니스 규칙에 대한 책임이 있게 되면, 더 복잡한 배포 프로세스를 가진 분산된 모노리틱 애플리케이션으로 변하게 된다.
마이크로서비스와 마찬가지로, 마이크로 프론트엔드 패턴은 소유권과 배포를 분리하는 것을 설명하는 Fowler의 역사적 진보에 의해 설명된다. 두 접근법 모두 독립성을 브라우저 인터페이스에 적용한다. 현재 도구에서, 모듈 연합 사용 싱글 스파는 라이프 사이클 기반 애플리케이션 등록을 원하는 팀이 오케스트레이션 옵션으로 사용할 수 있다.
예를 들어, 체크아웃 팀은 결제 흐름을 수정할 수 있다. 카탈로그 팀은 계속해서 느린 릴리스 일정에 따라 진행할 수 있다. 왜냐하면 shell은 런타임 구성에 따라 승인된 슬라이스를 로드하기 때문이다. 독립적인 배포 경계, 즉 시각적 외관이 아닌 독립적인 구성 요소의 독립적인 배포 경계가 아키텍처의 주요 이점이다.
팀이 주변 플랫폼을 평가할 때도, 애플리케이션 인프라를 고려해야 한다.프론트엔드 시스템
리포지토리와 프레임워크만으로는 신뢰할 수 있는 구성이 제공되지 않는다.
마이크로 프론트엔드 패턴 비교
| Pattern | 패턴: 독립성 | 통합 모델 | 공유 의존성 | 성능 | 최적화 |
|---|---|---|---|---|---|
| 최적화 | 프레임 | 강력한 프로세스 및 문서 격리 | 프레임 간 메시징을 사용하는 문서에埋め込은 문서 | 기본적으로 없음 | 로딩 및 통신 오버헤드가 추가될 수 있습니다 |
| 신뢰할 수 없는, 레거시 또는 강하게 격리된 경험 | 웹 컴포넌트 | 쉘에 의해 마운트되는 커스텀 요소 | 공유된 디자인 토큰과 브라우저 API | 종종 예측할 수 있지만 컴포넌트의 무게에 따라 달라짐 | 프레임워크의 유연성을 필요로 하는 표준 지향 팀 |
| 모듈 연합 | 중간 수준의 런타임 격리 | 런타임에 로드되고 마운트되는远程 모듈 | 명시적으로 협상된 또는 묶인 의존성 | 로드 및 중복 제거가 제어되는 경우 효율적 | Independent release를 가진 독립된 애플리케이션 |
| single-spa | 오케스트레이션 경계 대신 완전한 격리 모델 | 애플리케이션 등록을 위한 라이프 사이클 훅 | 애플리케이션과 루트 구성에 따라 의존 | 로드 규칙과 프레임워크 구성에 따라 의존 | 라우트 기반 활성화와 함께 다중 프레임워크 오케스트레이션 |
iframe
iframe은 이 비교에서 가장 강력한 경계를 제공합니다. 임베디드 애플리케이션은 자신의 문서, 스타일, JavaScript 환경을 가지고 있기 때문에 주최 페이지의 DOM을 무작위로 변형하지 않습니다. 크로스-윈도우 메시징은 제어된 통신 경로를 생성할 수 있습니다.
이러한 격리로 iframe은 레거시 시스템, 파트너 경험, 또는 유지해야 하는 별도의 콘텐츠에 유용합니다. 그러나 반응형 레이아웃, 네비게이션, 접근성, 포커스 관리, 공유 인증에 대한 비용이 발생합니다. 체크아웃 iframe은 주최 애플리케이션과 임베디드 애플리케이션 간에 신중하게 협력하지 않으면 외래 표면처럼 느껴질 수 있습니다.
웹 컴포넌트
웹 컴포넌트는 브라우저 표준을 사용하여 동일한 프레임워크를 모든 팀이 채택할 필요가 없습니다. 커스텀 엘리먼트는 안정적인 마운팅 표면을 정의하고, Shadow DOM은 스타일 누출을 제한할 수 있습니다. 셸은 여전히 애플리케이션 라우팅, 로딩 상태, 오류 경계, 공유 디자인 토큰을 처리해야 합니다.
이 옵션은 팀이 브라우저가 모든 슬라이스에 대한 애플리케이션 런타임을 로드하지 않도록 프레임워크의 유연성을 원할 때 잘 작동합니다. 그러나 자동으로 의존성 크기, 상태 통신, 또는 관리를 해결하지는 않습니다. 커스텀 엘리먼트는 여전히 큰 애플리케이션을 포함할 수 있습니다.
모듈 연합
모듈 연합 (Module Federation), Webpack 5에서 소개되어 Vite 및 Rspack와 같은 도구에 의해 지원되는 기능은 런타임에远程 엔트리에서 컴파일된 모듈을 로드합니다. 그것은 iframe와 함께 공유된 컴포넌트와 조정된 네비게이션을 자연스럽게 느끼게하는 강력한 통합을 제공합니다.
그 conveniences는 responsibility를 창조합니다. 팀은 호환된 공개 인터페이스, 공유된 의존성의 규칙, remote 버전 관리, 그리고 remote가 로드되지 못할 때 복구 계획이 필요합니다. monolithic와 microservice 아키텍처의 차이 provides useful context for separating deployment independence from simple code decomposition.
single-spa
single-spa는 프레임워크에 독립적인 오케스트레이터입니다. 팀은 애플리케이션과 라이프 사이클 훅을 등록하고, 부트스트랩 구성이 루트를 활성화하여 경로나 다른 조건에 따라 애플리케이션을 활성화합니다. 그것은 다른 프레임워크로 빌드된 애플리케이션을 조정할 수 있지만, 계약, 의존성 정책, 성능 지출, 보안 제어를 제거하는 것은 아닙니다.
팀은 이러한 메커니즘을 combination할 수 있습니다. 예를 들어, single-spa 루트는 경로를 조정할 수 있고, 모듈 연합은 remote 모듈을 제공하고, 웹 컴포넌트는 공개 마운팅 표면을 정의할 수 있습니다. 그 combination은 강력할 수 있지만, 추가된 layer가 개발자들이 이해하고 테스트해야하는 행동의 수를 증가시킵니다.
장점, 트레이드 오프, 그리고 숨겨진 위험
Micro frontend은 경계를 넘어 결정들을 이동시킨다. 그들은 릴리스의 폭파 반경을 줄이고 팀들에게 더 많은 통제력을 줄 수 있지만 시스템은 더 많은 artifact, 계약, 런타임 조건을 관리해야 한다.
| Dimension | Benefit | Tradeoff / Hidden Risk |
|---|---|---|
| 팀 자율성 | 팀은 사업 단위의 모든 단계를 소유한다 | 팀은 별도의 pipeline, on-call 소유권, 릴리스 규율을 유지해야 한다 |
| 배포 | 프래그먼트는 전체 인터페이스를 재빌드하지 않고 배포할 수 있다 | 릴리스는 원자성이 아니기 때문에 호환되지 않는 버전이 프로덕션에서 만나게 된다 |
| 실패 분리 | 원격 실패는 fallback으로 포함될 수 있다 | 잘못된 오류 경계는 여전히 탐색 또는 중요한 여행을 사용할 수 없게 할 수 있습니다. |
| 성능 | 지연 로딩과 초기 패키지의 크기가 줄어들면 일반적인 흐름을 도와줍니다. | 더 많은 요청, 중복된 프레임워크 code, 및 원격 초기화는 런타임 성능을 손상시킬 수 있습니다. |
| 기술 선택 | 경계가 허용되는 경우 팀은 다른 프레임워크를 사용할 수 있습니다. | 디버깅, 접근성, 디자인 일관성 및 채용이 혼합 스택에서 더 어려워집니다. |
| 보안 | 경계는 직접 구현 공유를 제한할 수 있습니다. | 껍데기는 충분히 검증되지 않은 원격 code를 실행할 수 있습니다. |
| 통치 | 공유 표준은 일관된 제품을 보존할 수 있습니다. | 디자인 시스템, 의존성 규칙, 계약 및 플랫폼 지원을 위한 지속적인 협조가 필요합니다. |
성능 청구서
Independent 슬라이스는 일반적으로 별도로 빌드된 자산을 생성합니다. 신중한 로딩 규칙이 없으면 브라우저가 더 많은 파일을 요청하고 code을 초기화하거나 중복 프레임워크 의존성을 다운로드할 수 있습니다. 마이크로 프런트엔드의 성능 지침은 필요시 로딩, 신중한 의존성 공유, 모듈 수준 캐싱 및 실패 분리에 중점을 둡니다.
실용적인 디자인은 기존 애플리케이션의 기준선으로 시작합니다. 경로 시작 시간, 번들 구성, 원격 로딩, 초기화 및 사용자에게 표시되는 실패를 측정한 후 쉘과 각 트래픽이 많은 슬라이스에 대한 예산을 설정합니다. 느린 원격 모듈의 긴-chain에서 critical journey를 막지 않는다면 느긋한 로딩만이 도움이 됩니다.
보안의 틈새
원격 모듈은 자동으로 안전하지 않습니다. 별도의 저장소가 있기 때문입니다. 쉘은 code을 실행하지 않으면서도 인증을 API 또는 토큰 서비스에서 수행하지 않습니다. 보안에 중점을 둔 마이크로 프런트엔드 분석 trust, signing, integrity checks, 및 authorization이 디자인에 주목받아야 하는 이유를 강조합니다. runtime code을 분배하기 전에.
버전의 차이로 인한 또 다른 위험 클래스가 있습니다. 프래그먼트는 단독으로 작동하지만 다른 쉘 버전, 공유 라이브러리, 디자인 토큰 세트 또는 이벤트 페이로드와 만날 때 실패할 수 있습니다. Nx의 아키텍처 지침 identifies coordination, environment configuration, application efficiency, 및 재사용성 을 지속적인 문제로 간주한다.
Architecture 는 release meeting 에서의 coordination 을 삭제하지 않는다. Architecture 는 coordination 을 contracts, automation, observability, 및 governance 로 바꾸는 것이다.
팀도 공유 의존성, 접근성 검토, 인시던트 대응, 및 롤백 결정에 대한 명확한 소유권이 필요하다. 만약 nobody 가 플랫폼 layer 를 소유하지 않는다면, 각 제품 팀은 composition 을 다르게 해결하고, 사용자는 결과하는 불일치로 인해 하나의 깨진 애플리케이션을 경험하게 된다.
배포 및 마이그레이션 실습
Testing 은 애플리케이션의 실제 동작을 반영해야 한다. fragment 가 자신의 단위 테스트를 통과해도 shell 이 제공하는 변경된 경로, 예상치 못한 인증 상태, 또는 다른 공유 의존성으로 인해 실패할 수 있다.
테스트 시스템을 층별로 구축하십시오
각 fragment 에서 시작하여 isolated test 를 만든다. 이 테스트들은 렌더링, 비즈니스 규칙, 키보드 동작, 로딩 상태, 및 지역 오류 처리를 검증한다. 이 테스트들은 shell 을 필요로 하지 않는다.
Contract test 들은 그 위에 있다. 그들은 shell 과 fragment 간의 인터페이스를 검증한다. 이에는 mount input, 경로 패턴, emitted event, expected payload, 인증 가정, 및 fallback 동작이 포함된다. Contract test 는 프로덕션 전에 하나의 팀이 다른 팀이 소비하는 인터페이스를 변경하면 실패해야 한다.
쉘 통합 테스트는 실제 프래그먼트 아티팩트를 로드하는 대표적인 구성으로 진행됩니다. 이 테스트는 라우팅, 인증 전환, 공유 네비게이션, 로딩 실패, 버전 Combination을 포함한 모든 경로를 커버해야 합니다. 종단 간 테스트는 상위에 위치해야 하며, 사용자가 제품을 둘러보거나, 로그인하거나, 체크아웃을 완료하는 등 여러 독립적으로 전달된 슬라이스를 통해 완전한 여행을 확인할 수 있습니다.
릴리즈 표면을 제어하세요
버전 매니페스트를 사용하여 쉘은 로드하는 정확한 프래그먼트 아티팩트를 식별할 수 있습니다. 매니페스트는 또한 원격 릴리스가 오류를 일으킬 때 운영자에게 알려진 좋은 버전을 고정할 수 있는 장소를 제공합니다.
유용한 제어 요소는 다음과 같습니다:
- 기능 플래그: 내부 사용자 또는 선택된 경로에 새로운 프래그먼트를 활성화하여 광범위한 노출 전에 테스트합니다.
- 캐니 디리버리: 새로운 아티팩트를 사용하는 한정된 사용자에게 지시하고 브라우저 오류, 로딩 실패, 주요 비즈니스 액션을 모니터링합니다.
- 관찰 가능한 번들: 릴리즈 식별자를 로그, 트레이스, 클라이언트 오류에 추가하여 실패하는 프래그먼트를 식별할 수 있는 팀에게 알려줍니다.
- 롤백 경로: 이전 호환 가능한 아티팩트를 유지하고 재버전을 운영적인 동작으로 만들 수 있도록 하세요. 수동으로 다시 빌드하는 것이 아닌.
팀은 shell과 fragment를 함께 프로덕션 환경에서 테스트해야 합니다. 성공적인 로컬 실행은 사용자가 올바르게 동작하는지 확인하지 못합니다. 콘텐츠 전달 경로, 캐시, 인증 토큰, 또는 원격 매니페스트가 올바르게 동작하는지 확인하지 못합니다. 배포 자동화 관행 반복 가능한 승격 및 롤백 워크플로우를 지원할 수 있지만, 아키텍처는 명확한 소유권이 필요합니다.
한 도메인을 한 번에 이동하세요
스트랠러 마이그레이션은 하나의 기능을 모노리틱에서 새로운 프래그먼트로 이동시키는 반면 나머지 부분은 변경되지 않습니다. 기능 토글은 병렬 실행을 지원하여 팀이 새로운 경로와 기존 implementation을 비교할 수 있도록 합니다. 새로운 경로가 기본 경로가 되기 전에.
판매용 애플리케이션을 고려하세요. 카탈로그, 계정, 체크아웃 팀이 각각 별도의 팀입니다. shell은 네비게이션 및 인증을 소유하고 있으며, 카탈로그 팀은 제품 브라우징을 소유하고 있으며, 계정 팀은 프로필 설정을 소유하고 있으며, 체크아웃 팀은 장바구니 및 결제 흐름을 소유합니다. 각 팀은 자신의 아티팩트를 발행하며, 계약 테스트는 경로 및 이벤트 약속을 보호합니다.
낮은 위험 도메인부터 시작하세요. 플래그 뒤에 발행하고, 실제 여행을 통해 관찰하세요. 확장하기 전에 팀이 해당 슬라이스를 배포, 진단, 롤백할 수 있도록 하세요. 전체 조직이 릴리스를 조정하지 않고.
Capacitor와 Electron에서 Micro Frontends를 사용하세요
A Capacitor 또는 Electron 애플리케이션은 브라우저 셸에 또 다른 셸을 추가합니다. Capacitor은 웹 code을 네이티브 모바일 WebView 내에 배치합니다. 반면 Electron은 웹 code을 데스크톱 렌더러 프로세스 내에서 실행합니다. 두 경우 모두 앱은 런타임에 선택한 프론트엔드 아티팩트를 로드하는 데 사용할 수 있는 로컬 셸을 로드할 수 있습니다. 이 셸은 인터페이스 변경을 네이티브 바이너리 내에埋め込지 않고도 선택한 프론트엔드 아티팩트를 로드할 수 있습니다.
그런 구성은 유용한 릴리스 분할을 만듭니다. 네이티브 기능, 권한 및 브리지를 포함한 code은 설치된 애플리케이션과 함께 유지됩니다. 그러나 계정, 도움말, 카탈로그 또는 설정과 같은 웹 소유 표면은 별도의 배포 경로를 따를 수 있습니다. 셸은 여전히 프래그먼트의 원천을 결정하고, 승인된 버전을 결정하고, fetch 또는 verification 단계가 실패할 경우 애플리케이션이 수행해야 하는 작업을 결정해야 합니다.
실시간 업데이트 및 롤백
실시간 업데이트 시스템은 프론트엔드 아티팩트를 릴리스 가능한 소프트웨어로 다루어야 합니다. 그것은 서명된 번들을 전달해야 하며, 활성화 전에 그들을 확인하고, staged rollouts를 위한 릴리스 채널을 지원하고, 활성 세션을 중단하지 않고 업데이트를 적용하고, 자동 롤백 보호를 제공하며, 원자적 재귀를 사용하여 이전에 알려진 좋은 상태로 되돌아갈 수 있어야 합니다.
그것은 자연스럽게 마이크로 프론트엔드 전달에 해당합니다. 모바일 또는 데스크톱 셸은 매니페스트를 고정하고, 호환 가능한 프래그먼트를 가져와, 서명된 프래그먼트를 확인하고, 완전한 번들을 사용할 수 있을 때만 활성화할 수 있습니다. 다음 런칭에서 실패를 감지하면 업데이터는 이전에 알려진 좋은 상태로 되돌아가기보다는 사용자에게 부분적으로 업데이트된 인터페이스를 남기지 않고 원자적 재귀를 사용하여 이전 상태로 되돌아갈 수 있습니다.
Capgo는 이 배포 모델의 하나입니다. CapacitorJS 및 Electron 앱을 위한 Live Update 플랫폼은 서명된 웹 번들을 배포하고, 특정 채널을 지원하며, 다음 런칭 시 업데이트를 적용하고, 로그, 버전 기록, 채택 및 실패 메트릭, 롤백 보호, CI/CD 통합 및 API를 제공합니다. native bridge를 고려하는 팀은 native bridge의 동작을 이해해야 합니다. Capacitor는 웹과 native code를 연결하는 방법을 이해해야 합니다..
native shell에서 변경 사항
native wrapper는 브라우저만 사용하는 애플리케이션에遇할 수 없는 제약을 도입합니다:
- 연결성: 장치가 오프라인일 때, 프래그먼트가 사용할 수 없으므로 shell은 캐시된 아티팩트 또는 로컬 폴백이 필요합니다.
- 호환성: 웹 번들이 설치된 바이너리가 지원하지 않는 native bridge 동작에 의존할 수 있습니다.
- 보안: Remote code는 애플리케이션 컨텍스트에서 인증, 무결성 검사 및 권한 부여가 필요합니다.
- 복구: shell은 무효한 패키지를 거부하고 즉시 저장 배포를 요구하지 않고 작동하는 버전을 복원할 수 있어야 합니다.
- 세션 안전성: 결제나 양식 흐름 중 업데이트는 불일치된 상태를 만들 수 있으므로 다음 런칭 활성화가 작업을 중단하는 것보다 안전합니다.
이 모델은 배포 플랫폼이 원자적 활성화와 세부 릴리스 메트릭을 제공할 때 롤백 강화에 강화됩니다. 그러나 팀이 웹 독립성이 원본 호환성 계획을 배제한다고 가정하면 아키텍처가 복잡해집니다. 원본 shell은 계약 경계가 남아 있으며 모든 프래그먼트는 그것을 존중해야 합니다.
Micro Frontend를 선택할 때
Independent 배포가 실질적인 요구 사항일 때 독립적인 배포는 실제 요구 사항입니다.기술 다양성도 패턴을 정당화할 수 있습니다. 단일 빌드가 깨끗하게 수용할 수 없는 프레임워크 경계가 필요할 때입니다.
다음과 같은 경우 Micro Frontend를 피하세요:
작은 팀이 하나의 프론트엔드를 편안하게 소유할 수 있는 경우
- Ownership: 조직이 신뢰할 수 있는 CI, 관찰성, 계약 테스트, 롤백 프로세스가 없을 때
- 경계: 쉘과 슬라이스가 안정적인 계약을 통해 통신할 수 있나요?
- 릴리즈 필요: 팀이独立적으로 릴리즈해야 하는지 필요할까요?
- 운영 준비 상태: 프래그먼트를 모니터링, 테스트, 핑, 롤백할 수 있나요?
- 사용자 가치: 분할이 성능이나 일관성을 손상시키지 않고 배달을 개선할 수 있나요?
헬프 콘텐츠나 설정과 같은 낮은 위험 영역에서 시작하세요. 마운트 계약, 라우트 소유권, 이벤트, 디자인 토큰, 폴백 동작, 버전 정책을 정의하세요. 특징 플래그 뒤로 릴리즈하고, 추가된 번들 및 로딩 비용을 측정하고, 새로운 채널, 매니페스트, 의존성 규칙, 롤백 경로를 문서화하세요.
마이크로 프론트엔드는 조직 및 릴리즈 독립성을 위한 도구입니다. 릴리즈 문제가 작다면 모듈러 모노리식이 더 좋은 답변이 될 수 있습니다. 조정 문제가 크고 지속적이라면 신중하게 관리되는 마이크로 프론트엔드 아키텍처는 팀이 필요로하는 자율성을 제공할 수 있습니다.
Capacitor 제품이나 Electron 제품을 평가할 때 마이크로 프론트엔드를 고려하고 있다면 Capgo can help you deliver signed web bundles through controlled channels, activate updates on the next launch, and recover through rollback protection. Visit Capgo to review its delivery, observability, and API options before you design your fragment release process.
