Fedration

마이크로 프론트엔드란?

• 이전에는 프론트엔드와 백엔드와 함께 작업하면서 어려움들이 있었음
  • 배포 합의 안되는 상황 발생
    • 프론트는 준비되어서 배포하려고 하지만 백엔들에서 준비가 안되는 경우
  • 각자의 프로덕트 환경으로 나뉘게 됨
  • 백엔드는 마이크로서비스를 통해서 발전하게됨
    • 조그만 서비스로 나뉘어서 개발
  • 프론트엔드의 발전
    • 컴포넌트를 도입하여 생산성, 가독성이 향상
    • 각자의 상태를 가지고 프로덕트를 개발하면서 발전
    • 프로덕트가 고도화되면서 복잡해짐
    • 사이드 이펙트, 의존성에 대한 어려움이 생김
    • -> 마이크로 서비스를 프론트엔드에 도입함
    • 각각의 서비스에 맞춰서 나뉨

왜 마이크로 프론트엔드인지

• 전시영역 : 배달 앱 내에서 사용자에게 보여지는 영역
  • 여러개의 어드민으로 나뉘어서 관리
  • 관리 측면에서 각각의 어드민에 접속
  • 인증/인가의 개별 관리
• 사업 영역이 확장된다면?
  • n 개의 도메인 확장
• 전시영역을 하나의 프로덕트로
  • 리모트 어플리케이션을 호스트 어플리케이션으로 통합(?)
• 마이크로 프론트엔드를 도입했을 때 발생하는 문제점
  • 한개의 프론트엔드 프로덕트를 여러개의 프로덕트로 나누었을 때 어떻게 관리할지
    • props 이용: 의존성, 커플링, 호스트랑 리모트가 동일란 브라우저를 사용해야 한다.
    • 스토리지 이용 : 의존성이 적고, 다양한 브라우저에서 지원하지만 확장 가능한 솔루션은 아니고, 보안에 취약
    • customEvent 이용: 비동기 이벤트 기반, 확장에 용이
    • custom MessageBus 이용:
  • 프론트엔드 상태 공유(리덕스, 리코일 등등)
    • 해결방법이 뭐야 그래서,,,

마이크로 프론트엔드 아키텍쳐

• 컴포넌트 도입을 외부에서

모듈 federation'

• 웹 어플리케이션 개발에서의 코드 공유
• 코드를 배포 가능한 작은 모듈 단위로 분리, 분리된 모듈을 동적으로 로드
  • expose option
  • remote option
• 장점
  • 유연성의 향상
    • 작고 관리하기 수운 모듈로 분할
    • 필요에 따라 모듈 교체
  • 확장성의 향상
    • 유지관리 용아
  • 협업 향상
• 단점
  • 복잡성 증가
    • 러닝 커브
    • 의존성, 버져닝 관리 필요
  • 보안 위험
    • 어플리케이션 간 코드 공유시 취약점 발생
    • 리모트에 있는 컴포넌트를 가져와서 보안 위험 있다
• 적용
  • 호스트 어플리케이션 : 기존 완성된 애플리케이션 코드 제공
    • 헤더, 사이드바,
    • 데이터 페칭
    • 인증 인가
  • 리모트 어플리케이션
    • 호스트의 컴포넌트 로직 재사용
    • 도메인/피쳐 별 타입 정의
    • api 래이어

msa를 도입하면서 겪었떤 문제점 및 해결방법

• 타입스크립트 적용 문제
  • type definition을 가져오기 -> 시간이 오래걸림
  • 페키지를 사용해서 해결 (module-federation/typescript)
    • 단방향 타입만을 제공(양방향 x)
    • 양방향을 제공하는 다른 페키지 사용
• 러닝커브
  • 다양한 프레임워크 각각의 configuration 을 정확히 알고있어야함
• 안정성 떨어짐
  • 많은 이슈로 인한 빈번한 패키지 업데이트
  • 이슈에 대한 해결방법이 버전별로 다르다
  • 레퍼런스 정보의 빈약함

도입 이후 얻은 것 & 잃은 것

• 얻은것
  • 공통화된 프로덕트
  • 명확한 책임의 경계
  • 예측 가능한 리스크 범위
  • 비즈니스 문제/ 기술적인 욕구 충족
• 잃은것
  • ...?