마이크로 프론트엔드의 환경
마이크로 프론트엔드의 단일 소프트웨어 디자인 패턴이아니라 구현에 대한 개발성을 통해 장점이 드러납니다. 이때 3가지 중요한 결정사항이 있는데, 사용의 동적 유형, 팀구성, 어디에 구성할 것인지가 중요합니다.
정적 vs 동적
정적
정적인 경우 최적화도 잘되고, 검사도 평하다는 장점이 있습니다. 간단한 보일러플레이트 코드만으로 프론트엔드를 생성할 수 있다는 장점이 있습니다. 하지만 사이트 수정이 발생할 때 애플리케이션이 재빌드 되어야합니다.
동적
동적은 접근 방식의 구현이 훨씬 어렵습니다.
•
소스에 마이크로 프론트엔드를 게시하는 방법
•
소스를 업데이트하는 방법
•
애플리케이션을 소스에 연결하는 방법
동적 접근 방식은 개발자가 요청별로 페이지를 구성할 수 있어 자유도가 높지만, 높은 복잡성과 느슨한 결합은 애플리케이션을 취약하게 만듭니다.
수평적 구성 vs 수직적 구성
수평적 접근
뷰별로 생성한다고 생각하면 됩니다. 서로 다른 도메인에서 온 사람들이 마이크로 프론트엔드를 개발합니다. 각각이 그 자체가 격리된 웹 애플리케이션이 됩니다. 하지만 이는 규모 변경이 어렵습니다. 대부분 일부 페이지에서 여러 도메인의 일부를 사용하지만 이는 지향하는 방법이 아닙니다.
수직적 접근
수직접 접근은 원하는 만큼 작게 분할해 마이크로 프론트엔드의 단일 하위 영역에 집중할 수 있습니다. 결과적으로 페이지는 여러 마이크로 프론트엔드로 구성됩니다. 하지만 개발이 잘못하면 복잡해질 수 있고, 디버깅이 어려워집니다.
백엔드 중심 vs 프론트엔드 중심
SSR과 CSR의 고민은 혼합하는 것이 최적의 선택이라고 봐야합니다.
백엔드 중심
백엔드 중심의 경우 마이크로 프론트엔드의 전달이 쉽습니다. 많은 내용을 이미 백엔드에서 포함시켰기 때문입니다. 하지만 규모 변경성과 신뢰성을 유지하기 위해 복잡한 인프라가 필요합니다.
프론트엔드 중심
유연하다는 것이 가장 큰 장점입니다. 하지만 설계 및 구성에 시간이 걸린다는 단점이 있습니다.