마이크로 프론트 엔드로 파이프에 전송 된 중복 코드

마이크로 프론트 엔드에 대한 나의 이해는 그들이 해결해야 할 주요 문제는 기업이 여러 개의 서로 다른 이종 팀을 구성하고 대규모 웹 애플리케이션을 구성하는 데 사용될 개별 구성 요소 / 작은 응용 프로그램에서 작업하도록 돕는 것입니다.

여기서 해결해야 할 주요 문제 는 여러 팀이 독립적으로 작업 하면서도 여전히 대규모 컴포지트를 구축 할 수 있는 능력입니다 . 문제는 최종 사용자를위한 린 릴리스 번들 이 아닙니다 . 이해가 정확합니까?

큰 웹 응용 프로그램을 작성하는 데 사용되는 여러 개의 작은 응용 프로그램이있는 경우 동일한 Javascript 라이브러리 ( 예 : Lodash )를 최종 사용자의 브라우저로 전달하는 여러 개의 작은 응용 프로그램이있을 수 있다는 사실이 사실입니까? 어느 정도의 중복 / 중복 코드가 사용자에게 전송되도록하는 개별 벤더 번들?

프론트 엔드 애플리케이션을 설계 할 때 걱정해야 할 문제가 아닌가?

여기에 관련된 상충 관계가 있다는 것이 옳습니다. 사용자 경험의 일부 측면에서 거래하여 더 나은 개발자 경험을 얻습니다 (다양한 방식으로 사용자 경험을 향상시킬 수 있음). 이것이 가치가 있습니까? 때에 따라 다르지.

예를 들어 Spotify는이 방법을 사용하여 UI를 격리 된 구성 요소 ( source ) 로 분할합니다 . 각 위젯은 iframe에 존재하므로 자체 라이브러리 세트 등을 가질 수 있습니다. 이들은 자율 분대 (교차 팀)가 수행하는 고유 한 조직적 제약 조건을 가지고 있습니다. 이로 인해 회사 전체 표준에 동의하고 나중에 이러한 표준을 변경하기가 더 어려워집니다. 따라서 마이크로 프런트 엔드는 유연성을 유지하는 데 도움이됩니다. 그러나이 방법이 없으면 데스크톱 앱의 메모리가 부족할 수 있습니다.

HTTP 캐싱은별로 도움이되지 않습니다. 각 마이크로 프론트 엔드가 서로 다른 프레임 워크 버전을 사용할 수 있습니다 . 또한 복제 비용은 데이터 전송뿐만 아니라 라이브러리를 다시 컴파일하고 중복 된 데이터 구조를 저장하는 클라이언트 측 비용입니다.

개인적으로, 그러한 마이크로 프론트 엔드는 유효한 아키텍처 일 수 있지만 아마도 바람직하지 않은 경우

• 자율적 인 팀이있는 매우 큰 조직으로, 모두 사용자 인터페이스에서 작업하며 매우 빈번한 릴리스 (예 : 매일)를 수행해야합니다.
• UX 성능 예산에 이러한 중복의 여지가 있거나 제품이 너무 좋아 UX가 중요하지 않습니다. 성능은 개발 시스템이 아닌 저가형 장치에서 테스트해야합니다.

조직 규모가 크지 않거나 팀이 좀 더 전문화 된 경우 관련된 모든 사람 (관리자, 개발자 및 최종 사용자)이 불필요한 복제를 피하는 공통 빌드 및 배포 프로세스를 갖는 것이 더 쉬울 수 있습니다. 예를 들어 UI에서 작업하는 팀이 4 명인 경우 공통 라이브러리 세트에 대해 합의하기 위해 서로 대화 할 수 있으며 작업을 응집력있는 아키텍처로 통합하는 방법에 대해 이야기 할 수 있습니다.

마이크로 프론트 엔드는 정말 멋지지만 규모에 맞게 운영 할 때까지 필요하지 않은 것 중 하나 인 것처럼 보입니다.