단일체 깨기: 코드 분할 기술에 대한 종합 가이드

지난 몇 년간 프론트엔드 커뮤니티에서는 '마이크로 프론트엔드'(이하 MF)라는 용어가 활발하게 논의되고 사용되어 왔습니다. 여러 회사가 이러한 아키텍처 솔루션을 구성하는 접근 방식을 공유하지만 지금까지 MF가 웹에서 해결하도록 설계된 문제, 적용 기준 및 사용 제한 사항에 대한 설명은 거의 없습니다.

이 기사에서는 MF를 구성하는 다양한 방법을 비교하고 어떤 접근 방식을 어디에 사용할지에 대한 권장 사항을 제시하려고 했습니다.

이 기사는 프로젝트의 아키텍처를 설계하고 프로세스를 레이아웃할 때 분석가와 개발 팀 모두에게 유용할 수 있으며, MF의 도입으로 보다 관리하기 쉬운 개발을 제공할 수 있으므로 제품 소유자에게도 유용할 수 있습니다.

마이크로프론트 접근 방식: 이것이 무엇이며 왜 필요한가요?

MF의 정의로 넘어가기 전에 프로젝트에서 발생할 수 있는 몇 가지 문제를 살펴보겠습니다.

1. 당신은 큰 프로젝트를 가지고 있습니다 . 프로젝트의 규모는 일반적으로 주관적이며 기능의 양과 개발자 수에 따라 경험적으로 결정될 수 있습니다. 1-2명의 프론트엔더를 퍼즐할 만큼 충분한 작업이 있고 동시에 그들이 "팔꿈치를 밀지" 않을 경우 - 이것은 작은 프로젝트이고, 3-6은 중간이고, 6-8 이상은 이미 큰 프로젝트입니다. .

   
   

2. 당신은 큰 팀을 가지고 있습니다 . 다시 말하지만, 경험적으로 볼 때 이는 10명이 넘는 프런트엔더이며 나머지 참가자는 포함되지 않습니다. 일반적으로 이 규모의 팀은 이미 지원을 위한 특정 기능을 담당하고 자체 분석가, 백엔더 및 QA를 확보하는 하위 팀으로 나눌 수 있습니다.

   
   

3. 당신은 훌륭한 기능을 가지고 있습니다. 한 명의 개발자는 자신의 하위 팀을 위한 코드 조각만 유지할 수 있습니다. 주제 영역에 대한 무지 또는 타사 논리 구현의 복잡성으로 인해 나머지 코드를 다듬는 데 비용이 많이 들 수 있습니다.

문제는 더욱 악화될 수 있습니다.

• 스택을 변경하려는 욕구;

• 일련의 관련 프로젝트를 지원하기 위한 회사 요구 사항입니다.

  
  

그렇게 많은 사람들 사이의 관계를 어떻게 정리할 수 있습니까? 이 규모의 프로젝트에서 어떻게 프로세스를 구축할 수 있습니까? 책임 영역을 어떻게 적절하게 설명할 수 있습니까? 더 많은 문제를 수집할수록 미시적 접근 방식의 도입을 고려해 볼 가치가 더 커집니다. 이는 코드와 프로젝트 팀의 분해를 향한 개발의 진화 추세가 자연스럽게 이어지는 것이기 때문입니다.

따라서 MF 접근 방식은 모놀리식 전선을 별도의 하위 팀이 액세스할 수 있는 별도의 저장소에 저장된 별도의 코드베이스로 분할하는 것입니다. 동시에 자체 데모 스탠드, 테스트 및 릴리스 주기를 가질 수 있고 가져야 합니다. 따라서 마이크로프런트는 인터페이스의 분리 가능한 부분입니다. 페이지별로 나눌 필요는 없으며, 기능은 엔드투엔드(예: 기업 ui-kit)일 수 있습니다.

이와 별도로, MF는 대규모 프로젝트에서 개발 복잡성을 관리하는 방법에 대한 조직적 결정 에 더 가깝다는 점을 강조할 가치가 있습니다. MF는 프런트엔드 속도를 높이는 데 도움이 되지 않으며, 반대로 일부 구현에서는 속도가 느려질 수도 있습니다. 그러나 이 접근 방식은 책임 영역 할당과 격리된 테스트로 인해 개발 자체의 속도를 높일 것입니다.

마이크로프런트엔드와 지연 로딩

반대로 MF와 비교하여 지연 로딩을 언급할 가치가 있습니다. 그들은 서로 다른 문제를 해결하지만 때로는 사람들이 모든 것이 한 가지에 관한 것이라고 생각합니다. 두 경우 모두 응용 프로그램을 "분할"하기 때문입니다.

지연 로딩은 성능 문제를 해결합니다. 사용자가 전체 프런트 엔드 번들을 로드하도록 강요하지 않는 방법, 필요 이상으로 오래 기다리지 않는 방법, 클라이언트에서 프런트 엔드를 더 빠르게 시작하고 더 빨리 상호 작용을 시작하는 방법입니다.

MF는 성능 문제를 해결하지 못하며 때로는 성능 문제를 악화시키기도 합니다. 그러나 특정 하위 팀에 더 편안한 방식으로 개발을 구성하여 위의 문제를 최소화하는 데 도움이 됩니다.

빌드타임과 런타임

이제 MF를 단일 애플리케이션으로 결합하는 접근 방식에 대해 이야기하겠습니다. 무엇을 선택하든 사용자에게는 단일 애플리케이션처럼 보여야 합니다. 사용자 측에서 코드를 실행하는 동안 어셈블리 단계와 동적으로 병합할 수 있습니다.

따라서 MF를 구성하는 모든 방법은 빌드 시간 또는 런타임에 기인할 수 있습니다. 각각에는 장단점이 있습니다.

유형 검사는 현대 개발에서 중요한 역할을 합니다. 별도의 독립된 하위 팀으로 운영되면 필수가 됩니다. MF의 일관성을 보장하는 방법, 올바른 형식으로 데이터를 정확하게 사용하고 전달하는 방법 등

빌드 시 마이크로프론트를 병합하면 유형을 확인할 수 있는 기회가 박탈되지 않습니다. 런타임 유니온의 경우 프로덕션에서 전면이 갑자기 "폭발"하지 않도록 통합 테스트를 작성해야 합니다.

버전 관리와 독립 배포 는 매우 모순적입니다.

• 버전 관리는 다른 팀의 MF의 모든 버전을 사용할 수 있음을 의미합니다. 이는 MF-a의 종속성을 다른 것으로부터 업그레이드하기 위해 추가 작업을 수행해야 하는 경우 특히 그렇습니다. 각 팀은 업그레이드하기에 더 좋은 시기를 선택합니다.

  
  

• 독립적인 배포는 팀에 더 많은 자율성과 독립성을 제공합니다. 항상 최신 버전의 MF를 사용하는 것이 중요합니다. 이를 위해서는 이전 버전과의 호환성이 필요합니다.

  
  

버전 관리는 런타임 병합을 통해 구현할 수도 있지만 이는 실용적이지 않습니다. 독립적인 배포를 위해서만 런타임에 접속하는 것이 합리적이며 후자는 버전 관리와 함께 존재할 수 없습니다.

다음으로 MF 결합에 대한 각 접근 방식의 구체적인 구현 예를 살펴보겠습니다.

마이크로프런트엔드 구성에 대한 접근 방식

아이프레임

MF를 구성하는 가장 오래된 방법입니다. iframe은 기본 사이트에 표시될 리소스의 주소를 전달하기 위한 특수 태그입니다. 결과는 사이트 내의 사이트입니다.

장점 중 구현의 용이성, 로직과 스타일의 완전한 분리, 독립적인 배포 기능, 프레임워크에 대한 바인딩이 없다는 점은 주목할 가치가 있습니다.

iframe을 삽입할 때마다 리소스 로드가 발생하므로 이러한 이점은 성능 저하로 인해 발생합니다. 이를 피할 수는 없습니다. DOM 노드를 디버깅하고 다시 연결하려고 하면 이전에 로드된 리소스가 저장되지 않으므로 다시 다운로드해야 합니다. 캐싱을 구성하면 성능 저하를 최소화할 수 있습니다.

이렇게 하려면 변경할 수 없는 리소스에 대해 시간 기반 캐시 무효화를 구성해야 합니다. 다행스럽게도 수집된 js 및 css 파일에 대한 모든 최신 cli는 이름에 작은 해시를 첨부합니다. 이 방법의 단점은 검색 로봇이 후속 색인 생성을 위해 iframe을 렌더링할 수 없다는 것입니다.

웹컴포넌트

프론트엔드 커뮤니티는 오랫동안 네이티브 컴포넌트의 생성을 기다려왔지만 결국 많은 사람들이 기대했던 대중적 인기를 얻지 못했습니다. 가장 인기 있는 세 가지 프런트엔드 프레임워크(React, Vue, Angular)는 여전히 고유한 방식으로 구성 요소를 생성합니다.

웹 구성 요소에서 MF를 생성하는 기능에도 불구하고 실제로는 이것을 본 적이 없습니다. 그리고 이것은 우연이 아닙니다. 많은 차단제가 있습니다.

• libs Lit 또는 Stencil은 충분히 인기가 없고 일반적이지 않습니다. 게다가 시장에는 함께 일하는 방법을 알고 있거나 배울 준비가 된 전문가가 충분하지 않습니다.

  
  

• Angular 요소 또는 vue-custom-element는 여전히 이색적입니다. 기본 환경에서는 이를 사용하는 데 큰 의미가 없습니다. 이미 애플리케이션을 분할한 경우 일반 npm 패키지로 분할하여 나중에 원하는 대로 구성 요소를 연결할 수 있습니다. 다른 프레임워크와 함께 웹 구성 요소를 사용하는 것은 생성된 구성 요소와 함께 해당 구성 요소가 작성된 프레임워크의 미니 버전을 연결해야 하기 때문에 비합리적입니다.

  
  

• 복잡한 기능을 웹 구성 요소로 옮기는 데는 비용이 많이 들 수 있습니다. 애플리케이션의 나머지 부분과 구성 요소의 통신을 구성해야 하므로 별도의 사용자 정의 구성 요소에서 전체 페이지를 꺼내는 것은 타당하지 않을 수 있습니다.

  
  

• 검색 로봇은 웹 구성 요소를 생성할 수 없으며 이는 SEO 최적화에 영향을 미칩니다.

NPM

npm 패키지 로 개발하면 많은 이점이 있습니다. 개발자는 lib에서 필요한 구성 요소와 파일을 가져오기만 하면 됩니다. 동시에 프로젝트에 입력이 유지되고 버전 관리가 이루어집니다. 빌드가 최적입니다. 트리 쉐이킹 작업(빌드 중 사용하지 않는 코드 제거)이 수행되고 개발자는 지연 로딩을 쉽게 설정할 수 있습니다.

그러나 이 방법에는 단점도 있습니다. 이 경우 스택의 통일성을 유지하고 MF 버전과 전이적 종속성을 유지해야 합니다. 반면에 이는 장점이 될 수 있습니다. 패키지의 새 버전을 게시하면 다른 팀이 추가 기능을 도입해야 하는 경우 또는 반대로 필요한 경우 편리한 시간에 종속성 버전을 높이는 작업을 맡을 수 있습니다. , 무언가를 제거하세요.

git 하위 모듈(또는 Lerna와 같은 단일 저장소를 만드는 다른 방법)

npm 패키지의 MF 대신 git 하위 모듈을 고려해보세요. 실제로 이는 저장소 내의 저장소이며, 그 안에 저장소도 있을 수 있습니다. 하위 모듈에서 다른 분기를 설정할 수 있습니다. 예를 들어 기능 모듈에는 아무것도 없는 더미 분기가 있을 수 있습니다. 이는 어셈블리가 더 빠르게 진행되고 다른 모듈이 부작용을 일으키지 않도록 하기 위해 필요합니다. 더미 분기는 로컬 개발 및 테스트에 매우 편리할 수 있습니다.

장점과 단점 측면에서 이 접근 방식은 npm 패키지와 매우 유사합니다. 또한 패키지가 아닌 인접 폴더에서 무언가를 가져와서 사용합니다.

두 가지 방법의 차이점을 살펴보겠습니다.

• 실제로 NPM 패키지는 자체 릴리스와 버전이 있는 유한하고 적당히 격리된 마이크로 제품입니다. 모든 것은 재사용 가능한 기능을 만드는 데 중점을 두고 있습니다. 그러나 애플리케이션은 복잡하고 복잡하며 냄새가 날 수 있으므로 대규모 단일체를 패키징하는 데 비용이 상당히 많이 들 수 있습니다. 추가 준비 없이 폴더를 별도의 저장소로 이동할 때 저장소를 매우 대략적으로 잘라낼 수 있기 때문에 하위 모듈을 고려하는 것이 합리적입니다.

  
  

• NPM 패키지는 재귀적으로 중첩될 수 있습니다. 하위 모듈도 마찬가지지만, 하위 모듈 중 하나가 별도의 하위 모듈로 다른 폴더에 여러 번 포함되면 어셈블리 수준에서 기능 복제를 시작할 수 있습니다. 이 경우에는 더 평평한 모듈 구조를 사용하는 것이 좋습니다.

  
  

• 한 번에 모든 패키지의 기능을 신속하게 출시해야 하는 경우 패키지 간 개발이 매우 불편할 수 있습니다. 하위 모듈에서는 모든 것이 동일하게 유지되지만 다른 하위 모듈에 영향을 미치는 편집 작업을 수행할 수 있습니다. 이 경우 디버깅이 쉽습니다. 그러나 결국 변경 사항 자체를 병합하지는 않습니다. 병합 요청 수준에서 귀하가 터치한 모듈을 담당하는 제3자 팀이 규칙에 맞게 코드를 가져오도록 요구할 수 있습니다.

  
  

싱글 스파

Single-spa는 기본적으로 다른 프레임워크를 결합한 프레임워크입니다. 수많은 뉘앙스를 숨기는 믿을 수 없을 정도로 강력한 기술은 별도 기사의 주제입니다.

이 구성표는 iframe과 유사하지만 이제 MF 로딩은 기본 import + importmap을 통해 수행되거나 폴리필이 필요한 경우 Systemjs를 통해 수행됩니다.

MF를 구성하는 모든 방법과 달리 이 방법은 자체적으로 다양한 프레임워크를 결합하는 데 고도로 맞춤화되어 있습니다. 그러나 기술 자체를 위해 기술을 사용하는 것에 대해서는 경고할 가치가 있습니다. 하나의 스택으로 가능하다면 이를 사용해야 합니다. 개발은 기술적으로 복잡한 프로젝트를 유지하고 다양한 애플리케이션의 부작용으로 인한 버그를 수정하는 데 영원히 부담을 느낄 수 있습니다. 사용자가 불편함을 느낄 수 있기 때문입니다. 클라이언트에 다운로드하기 위한 코드의 양이 늘어납니다(다양한 기능에 대한 다양한 프레임워크의 코어 + 단일 스파 자체 및 해당 플러그인의 코어).

Webpack 5 모듈 연합

MF 생성을 위해 특별히 개발된 webpack 5 플러그인입니다. 유망한 기술: 보다 정확한 번들링과 런타임 시 동적 가져오기를 위한 작은 빌드 플러그인입니다.

거의 일대일 방식으로 싱글 스파를 반복하지만 이제는 동적 가져오기를 사용하여 MF를 로드합니다.

귀하의 경우에 무엇을 사용할지 선택하는 방법은 무엇입니까?

무엇을 적용할 수 있는지, 무엇을 위해 적용할 수 있는지 살펴보겠습니다.

• iframe - 부조화의 조합을 위한 단일 삽입

• 웹 구성 요소 - 기업 UI 키트와 같이 프레임워크에 얽매이지 않고 작은 엔드투엔드 기능이 필요한 경우

• npm 패키지 - 프로젝트 간 재사용성이 있거나 빌드 시 유형 확인이 필요한 경우

• git 하위 모듈 - 프로젝트를 대략적으로 자르고 책임 영역을 분배해야 할 때

• 단일 스파 - 가급적이면 SSR 없이 여러 프레임워크를 무기한 결합해야 하는 경우

• 모듈 연합 - 스택의 통일성에 따라 MF 사용에 대한 다른 모든 시나리오입니다.

  
  

각 접근 방식은 그 자체로 훌륭하며 모든 것이 그 자리를 차지해야 합니다. MF로 전환하기 전에 실제로 필요한지 생각해 보는 것이 좋습니다. 어떤 접근 방식을 선택하든 개발, CI/CD 또는 성능 수준에서 무언가가 필연적으로 복잡해집니다. 단일 스택과 모놀리식 애플리케이션을 유지할 기회가 있다면 이 기회를 기꺼이 받아들이십시오.

그리고 물론 사용자에 대해서도 잊지 마세요 . 궁극적으로 그들은 연결된 모든 프레임워크를 다운로드하고 다양한 기능에서 MF의 잘못된 통합으로 인해 발생할 수 있는 버그를 견뎌냅니다. 기업은 이 모든 것을 구현하고 지원하는 데 드는 비용을 지불해야 합니다.