스타일링과 CSS

CSS (Cascading Style Sheets) 는 텍스트와 개체의 서식을 하드 코딩하는 대신 문서의 표시 방식을 중앙에서 결정하기 위한 언어입니다. 이 언어의 계단식 기능은 상속을 사용하여 스타일 간의 우선 순위를 제어하도록 설계되었습니다. 마이크로 프론트엔드에서 작업하고 종속성을 관리하기 위한 전략을 세울 때 언어의 계단식 기능을 구현하는 것이 어려울 수 있습니다.

예를 들어, 동일한 페이지에 두 개의 마이크로 프론트엔드가 공존하며, 각 마이크로 프론트엔드는 HTML 요소의 고유한 스타일을 정의합니다. body 각 파일이 고유한 CSS 파일을 가져와서 style 태그를 사용하여 DOM에 연결하는 경우 두 파일에 공통 HTML 요소, 클래스 이름 또는 요소 ID에 대한 정의가 있는 경우 CSS 파일이 첫 번째 파일을 대체합니다. 스타일 관리를 위해 선택한 종속성 전략에 따라 이러한 문제를 해결하는 다양한 전략이 있습니다.

현재 성능, 일관성 및 개발자 경험의 균형을 맞추기 위해 가장 많이 사용되는 접근 방식은 디자인 시스템을 개발하고 유지 관리하는 것입니다.

디자인 시스템 ‒ 무언가를 공유하는 접근법

이 접근 방식은 시스템을 사용하여 적절한 경우 스타일을 공유하는 동시에 일관성, 성능 및 개발자 경험의 균형을 맞추기 위해 가끔 발생하는 차이를 지원합니다. 디자인 시스템은 명확한 표준을 따르는 재사용 가능한 구성 요소의 집합입니다. 설계 시스템 개발은 일반적으로 여러 팀의 의견과 기여를 받아 한 팀이 주도합니다. 실제로 디자인 시스템은 JavaScript 라이브러리로 내보낼 수 있는 저수준 요소를 공유하는 방법입니다. 마이크로 프론트엔드 개발자는 라이브러리를 종속 요소로 사용하여 미리 만들어진 사용 가능한 리소스를 구성하여 간단한 인터페이스를 구축하고 새로운 인터페이스를 만들기 위한 출발점으로 사용할 수 있습니다.

양식이 필요한 마이크로 프론트엔드를 예로 들어 보겠습니다. 일반적인 개발자 환경은 디자인 시스템에서 사용할 수 있는 미리 만들어진 구성 요소를 사용하여 텍스트 상자, 버튼, 드롭다운 목록 및 기타 UI 요소를 구성하는 것으로 구성됩니다. 개발자는 실제 구성 요소의 스타일을 따로 작성할 필요가 없으며 구성 요소가 어떻게 보이는지에 대한 스타일만 작성할 수 있습니다. 빌드하고 릴리스할 시스템은 webpack Module Federation 또는 유사한 접근 방식을 사용하여 디자인 시스템을 외부 종속성으로 선언할 수 있습니다. 이렇게 하면 디자인 시스템을 포함하지 않고 양식의 로직을 패키징할 수 있습니다.

그러면 여러 마이크로 프론트엔드가 동일한 작업을 수행하여 공유된 문제를 해결할 수 있습니다. 팀이 여러 마이크로 프론트엔드 간에 공유할 수 있는 새 구성 요소를 개발하는 경우 해당 구성 요소는 완성도에 도달한 후 설계 시스템에 추가됩니다.

설계 시스템 접근 방식의 주요 장점은 높은 수준의 일관성입니다. 마이크로 프론트엔드는 스타일을 작성하고 때로는 디자인 시스템의 스타일을 재정의할 수 있지만 그럴 필요는 거의 없습니다. 주요 하위 수준 요소는 자주 변경되지 않으며 기본적으로 확장 가능한 기본 기능을 제공합니다. 또 다른 장점은 성능입니다. 빌드 및 릴리스 전략을 잘 세우면 애플리케이션 셸에서 인스트루먼트되는 최소한의 공유 번들을 생성할 수 있습니다. 네트워크 대역폭 측면에서 풋프린트를 최소화하면서 필요에 따라 여러 개의 마이크로 프런트엔드 전용 번들을 비동기적으로 로드하면 훨씬 더 개선할 수 있습니다. 마지막으로, 개발자 경험이 이상적이라는 것은 사용자들이 처음부터 다시 개발하지 않고도 (예: 페이지에 버튼을 추가해야 할 때마다 작성하거나 CSS를 작성하는 JavaScript 등) 풍부한 인터페이스를 구축하는 데 집중할 수 있다는 점입니다.

단점은 어떤 종류의 디자인 시스템이든 종속되어 있기 때문에 유지 관리해야 하고 때로는 업데이트해야 한다는 것입니다. 여러 마이크로 프론트엔드에 새 버전의 공유 종속성이 필요한 경우 다음 중 하나를 사용할 수 있습니다.

• 경우에 따라 충돌 없이 공유 종속성의 여러 버전을 가져올 수 있는 오케스트레이션 메커니즘

• 모든 종속 항목을 새 버전을 사용하도록 이동시키는 공유 전략

예를 들어 모든 마이크로 프론트엔드가 디자인 시스템의 버전 3.0을 사용하는데 3.1이라는 새 버전을 공유 방식으로 사용할 경우 모든 마이크로 프론트엔드에 기능 플래그를 구현하여 위험을 최소화하면서 마이그레이션할 수 있습니다. 자세한 내용은 기능 플래그 섹션을 참조하십시오. 또 다른 잠재적인 단점은 디자인 시스템이 일반적으로 스타일 지정 이상의 문제를 해결한다는 것입니다. 여기에는 JavaScript 관행과 도구도 포함됩니다. 이러한 측면에서는 토론과 협업을 통해 합의에 도달해야 합니다.

설계 시스템을 구현하는 것은 좋은 장기 투자입니다. 이는 널리 사용되는 접근 방식이므로 복잡한 프론트엔드 아키텍처를 작업하는 사람이라면 누구나 고려해야 합니다. 일반적으로 프론트엔드 엔지니어와 제품 및 설계 팀이 협업하고 상호 작용하는 메커니즘을 정의해야 합니다. 원하는 상태에 도달할 시간을 계획하는 것이 중요합니다. 사람들이 신뢰할 수 있고, 잘 관리되고, 장기적으로 성능이 좋은 제품을 만들 수 있도록 지도부의 후원을 받는 것도 중요합니다.

완전히 캡슐화된 CSS ‒ 아무것도 공유하지 않는 접근법

각 마이크로 프론트엔드는 규칙과 도구를 사용하여 CSS의 캐스케이딩 기능을 극복합니다. 예를 들어 각 요소의 스타일이 항상 요소의 ID 대신 클래스 이름에 연결되도록 하고 클래스 이름은 항상 고유하도록 하는 것입니다. 이렇게 하면 모든 것이 개별 마이크로 프론트엔드로 한정되므로 원치 않는 충돌의 위험이 최소화됩니다. 응용 프로그램 셸은 일반적으로 마이크로 프론트엔드의 스타일을 DOM에 로드한 후 로드하는 역할을 담당하지만 일부 도구는 를 사용하여 스타일을 함께 묶습니다. JavaScript

아무것도 공유하지 않는 것의 주된 이점은 마이크로 프론트엔드 간에 충돌이 발생할 위험이 줄어든다는 것입니다. 또 다른 장점은 개발자의 경험입니다. 각 마이크로 프론트엔드는 다른 마이크로 프론트엔드와 아무 것도 공유하지 않습니다. 분리된 상태에서 릴리스하고 테스트하는 것이 더 간단하고 빠릅니다.

아무것도 공유하지 않는 방식의 주된 단점은 일관성이 결여될 수 있다는 점입니다. 일관성을 평가하는 시스템이 마련되어 있지 않습니다. 공유된 데이터를 복제하는 것이 목표라고 해도 출시 속도와 협업 속도 사이에서 균형을 맞추는 것은 쉽지 않습니다. 일반적인 완화 방법은 일관성을 측정하는 도구를 만드는 것입니다. 예를 들어 헤드리스 브라우저를 사용하여 페이지에 렌더링된 여러 마이크로 프론트엔드의 스크린샷을 자동으로 캡처하는 시스템을 만들 수 있습니다. 그런 다음 출시 전에 스크린샷을 수동으로 검토할 수 있습니다. 하지만 그러려면 규율과 거버넌스가 필요합니다. 자세한 내용은 자율성과 조정의 균형 섹션을 참조하십시오.

사용 사례에 따라 또 다른 잠재적인 단점은 성능입니다. 모든 마이크로 프론트엔드에서 많은 양의 스타일을 사용하는 경우 고객은 중복된 코드를 많이 다운로드해야 합니다. 이는 사용자 경험에 부정적인 영향을 미칩니다.

이러한 무공유 방식은 소수의 팀만 참여하는 마이크로 프론트엔드 아키텍처나 낮은 일관성을 견딜 수 있는 마이크로 프론트엔드에서만 고려해야 합니다. 또한 조직에서 설계 시스템을 개발하는 동안 이는 자연스러운 초기 단계일 수도 있습니다.

공유 글로벌 CSS ‒ 모두 공유 접근 방식

이 접근 방식을 사용하면 스타일 지정과 관련된 모든 코드가 중앙 저장소에 저장되며, 여기서 기여자는 CSS 파일을 작업하거나 Sass와 같은 전처리기를 사용하여 모든 마이크로 프론트엔드용 CSS를 작성할 수 있습니다. 변경 사항이 적용되면 빌드 시스템은 단일 CSS 번들을 생성합니다. 이 번들은 CDN에서 호스팅되고 애플리케이션 셸에서 각 마이크로 프론트엔드에 포함할 수 있습니다. 마이크로 프론트엔드 개발자는 로컬에서 호스팅되는 애플리케이션 셸을 통해 코드를 실행하여 애플리케이션을 설계하고 빌드할 수 있습니다.

마이크로 프론트엔드 간의 충돌 위험을 줄이는 명백한 이점 외에도 이 접근 방식의 장점은 일관성과 성능입니다. 그러나 마크업과 로직에서 스타일을 분리하면 개발자가 스타일이 사용되는 방식, 스타일이 어떻게 발전할 수 있는지, 더 이상 사용되지 않을 수 있는 방법을 이해하기가 더 어려워집니다. 예를 들어 기존 클래스와 해당 속성 편집의 결과에 대해 알아보는 것보다 새 클래스 이름을 도입하는 것이 더 빠를 수 있습니다. 새 클래스 이름을 만들면 번들 크기가 커져 성능에 영향을 미치고 사용자 경험에 불일치가 발생할 수 있다는 단점이 있습니다.

공유된 글로벌 CSS는 monolith-to-micro-frontends 마이그레이션의 출발점이 될 수 있지만 한두 팀 이상이 함께 협업해야 하는 마이크로 프론트엔드 아키텍처에서는 그다지 유용하지 않습니다. 가능한 한 빨리 디자인 시스템에 투자하고 디자인 시스템이 개발되는 동안 아무것도 공유하지 않는 방식을 구현하는 것이 좋습니다.