대부분의 개발자들은 이미 마이크로서비스 아키텍처에 대해 들어본 적이 있지만 마이크로 프론트엔드는 훨씬 덜 알려진 용어입니다. 이름에서 알 수 있듯이 마이크로 프론트엔드는 마이크로서비스. 이는 모놀리식 애플리케이션이 가진 많은 동일한 문제들을 해결하려고 시도합니다. 너무 크고, 함께 일하기 어렵고, 변경하기 어렵습니다. 새로운 인재를 채용하는 것은 고통스러울 수 있습니다. 또한, 여러 팀이 애플리케이션의 여러 부분에서 작업하는 경우, 모든 변경 사항을 서로 조율해야 합니다.
마이크로서비스는 백엔드를 보다 독립적인 서비스로 분할하는 데 도움을 줍니다. 사용자가 여전히 SPA 동작을 경험할 수 있도록 서로 다른 부품을 다시 결합할 수 있는 “오케스트레이터”에 대한 추가적인 요구와 함께, 단일 페이지 애플리케이션(SPA)을 더 작은 앱으로 분할하는 데에도 동일한 접근 방식을 사용할 수 있습니다.
마이크로 프론트엔드 아키텍처의 대안은 무엇일까요?
물론, 코드의 일부를 자체 npm 패키지로 분리하는 등 대규모 애플리케이션의 바람직하지 않은 일부 측면을 처리하는 다른 방법도 있습니다. 이렇게 하면 리포지션이 너무 큰 것처럼 문제의 일부를 해결할 수 있습니다. 예를 들어, 각형에서는 코드를 느슨하게 로드할 수 있는 모듈로 분리할 수도 있습니다. 이를 통해 애플리케이션의 수직 분할을 어느 정도 허용할 수 있습니다. 그러나 종속성 중 하나가 업데이트될 때 최상위 프로젝트를 구축해야 하는 것과 같은 단점도 있습니다. 또한 개발자 경험도 그리 좋지 않습니다. 어떤 종류의 프레임워크를 사용할 때는 모든 것을 동일한 버전으로 업그레이드하는 것이 좋지만, 아무도 기대하지 않는 큰 약속입니다. iframe을 통해 여러 앱을 함께 가입할 수도 있습니다. 이는 이들을 독립하게 만들지만, 앱 간 통신이 문제이고 코드, 스타일 등을 공유하는 것이기 때문에 너무 독립적일 수 있다고 생각합니다.
마이크로 프론트엔드가 레스큐를 선도할까요?
마이크로 프론트엔드는 이러한 두 가지 접근 방식의 조합입니다. 각 마이크로 프론트엔드는 SPA와 비교되는 별도의 애플리케이션입니다. 링크된 스크립트 및 스타일 파일이 있는 index.html은 물론 JavaScript 모듈로 컴파일됩니다. “메인” 앱의 iframe 대신, 코드는 URL이 일부 패턴과 일치할 때 모듈이 느슨하게 로드되어 특정 지점에 배치되는 것을 정의합니다. 이를 통해 동일한 페이지에 여러 앱을 상호 연결할 수 있습니다.
따라서 마이크로 프론트엔드는 메인 앱에서만 처리할 수 있는 앱 레이아웃과 기본 CSS 규칙을 처리할 필요가 없습니다. 동일한 버전의 React를 사용하는 마이크로 프런트엔드가 여러 개 있는 경우, React 모듈을 공유하게 할 수 있다는 것도 마찬가지로 도움이 됩니다. 마이크로 프런트엔드마다 별도로 다운로드할 필요가 없습니다. 다른 버전의 JS 모듈도 문제가 되지 않습니다.
마이크로 프론트엔드의 주요 걱정은 애플리케이션의 다른 부분으로 넘치지 않도록 하는 것입니다. 다행히도, 가장 일반적으로 사용되는 UI 프레임워크에는 이를 쉽게 처리할 수 있는 도구가 있습니다.
마이크로 프론트엔드 아키텍처를 위한 툴링
마이크로 프론트엔드 애플리케이션을 로드하기 위해 자체 코드를 쓰는 것은 매우 어려운 일입니다. 다행히도, 오케스트레이션을 처리하고 가장 인기 있는 프레임워크에 작성된 앱을 마이크로 프론트엔드 형식으로 변환하는 툴링을 제공하는 여러 프레임워크가 있습니다.
퓨어스토리지는 단일 스파를 선택했습니다. 퓨어스토리지의 주요 장점은 이해하기 쉽고, JS 프레임워크에 대한 광범위한 지원을 제공하며, 상세한 문서를 제공한다는 점입니다. 또한, 단일 스파는 여러 유형의 마이크로 프론트엔드를 제공하며, 각각은 약간 다른 작업에 적합합니다.
현재는 “애플리케이션” 유형만 사용하고 있습니다. SPA에서 마이크로 프론트엔드로 이동하는 데 가장 사용하기 쉽기 때문입니다. 또한 다른 유형의 경우 보다 세부적인 마이크로 프론트엔드 아키텍처가 필요합니다. 또한, 단일 스파 저자들은 기본적으로 “애플리케이션”을 권장합니다.
