Micro Frontends 번역글 3/5 요약

이 글에서는 Cam Jackson의 Micro Frontends 번역 글을 보고 내가 쉽게 보려고 요점만 정리해봤다.

 

스타일링

CSS는 모듈시스템, 네임스페이스 또는 캡슐화가 없는 본질적으로 전역적이고 상속되며 계단식이다.

예시: 두개의 마이크로 프론트엔드 앱에 스타일시트에 각 h2 { color: black; }, h2 { color: blue; }가 있다면 충돌

 

그래서 지금까지 개발된 CSS를 보다 쉽게 관리할 수 있는 접근법

• BEM: 엄격한 명명 규칙 사용
• SASS: 셀렉터를 감싸(nesting) 네임스페이스 같은 형태로 사용
• CSS 모듈: 모든 스타일을 프로그래밍 방식으로 적용
• CSS-in-JS 라이브러리: 모든 스타일을 프로그래밍 방식으로 적용
• shadow DOM: 좀더 플랫폼기반 접근 방식

서로 독립적으로 스타일을 작성할 수 있는 방법을 찾아 원하는 방식을 사용하자.

 

공유 컴포넌트 라이브러리

공유 UI Component 라이브러리 개발의 이점

• 코드 재사용
• 마이크로 프론트엔드 간 시각적 일관성
• 이를 통한 노동력 감소
• 스타일가이드 역할

초기에 공통 디자인을 가지고 기초 프레임워크를 만들기 보다는, 공통된 패턴이 자연스럽게 나타나고 컴포넌트의 API가 명확해지면 공유라이브러리에서 중복 코드를 추출해 확실히 입증된 것들로 진행하는 것이 좋다. 또한 공유 컴포넌트에는 비즈니스 로직이나 도메인 로직 없이 UI로직만 포함되도록 주의한다.

 

지향 모델

누구나 라이브러리에 기여할 수 있지만 기여의 품질, 일관성 및 유효성을 보장할 책임이 있는 관리인(개인 또는 팀)이 있는 모델을 지향하도록 한다.

 

어플리케이션 간 통신

종류

• Custom events: 마이크로 프론트엔드 앱이 간접적으로 통신하여 직접 연결을 최소화하지만 마이크로 프론트엔드 앱 간에 존재하는 규율을 결정하고 강요하는 것을 더 어렵게 함
• React모델: 콜백과 데이터를 컨데이너 앱에서 마이크로 앱으로 전달함. 전달 방식에 대한 규율을 보다 명확하게 만드는 좋은 솔루션이다.
• 주소 표시줄을 통신 매커니즘으로 사용

어떠한 방식을 선택하든 부적절한 커플링을 피하고자 가능한 한 적게 의사소통해야 한다.
어떤 종류의 결합을 도입할지, 그것을 어떻게 유지할 것인지에 대해 깊히 생각하는 게 중요하다.

 

백엔드 통신

BFF(Back-end for Front-end Pattern)패턴은 원래 각 프론트엔드 채널(웹, 모바일 등)에 대한 전용 백엔드를 의미했을 수도 있지만, 각 Micro Frontends Application에 대한 백엔드를 의미하도록 쉽게 확장 될 수 있다.

마이크로 프론트엔드 앱에 단 하나의 API만 가지고 있고, 그 API가 안정적이라면 BFF를 구축하는 큰 가치가 없을 수도 있지만, 여기서 지침 원칙은 다른 팀이 무엇을 만들 때까지 기다릴 필요가 없어야 한다.

 

강점

마이크로 프론트엔드 앱에 추가된 어떠한 새로운 기능이 백엔드 변경을 ㅍ

인증

고객이 한번만 인증하면 되므로 일반적으로 container 앱이 소유해야 한다. 컨테이너에 일종의 로그인 양식이 있고, 이를 통해 일종의 토큰을 얻는다. 이 토큰은 컨테이너가 소유하며 초기화 시 각 마이크로 프론트엔드 앱에 주입될 수 있다.

 

테스트

테스트에 있어서는 모놀리식 프론트엔드와 마이크로 프론트엔드는 별 차이가 없다. 즉, 각 마이크로 프론트엔트 앱에는 코드의 품질과 정확성을 보장하는 자체 자동화 테스트 세트가 있어야 한다.
차이점은 마이크로 프론트엔드를 컨테이너 앱과 통합 테스트 해야한다.

 

 

 

참고:
https://martinfowler.com/articles/micro-frontends.html
https://medium.com/@juyeon.kate/micro-frontends-%EB%B2%88%EC%97%AD%EA%B8%80-1-5-29c80baf5df