Luca Mezzalira와 함께하는 스매싱 팟캐스트 에피소드 6: 마이크로 프론트엔드란?

올해는 또 다른 Smashing 팟캐스트로 마무리합니다! 이번에는 마이크로 프론트엔드에 대해 이야기하겠습니다. 마이크로 프론트엔드란 무엇입니까? 현재 우리가 취하고 있는 접근 방식과 어떻게 다릅니까? 마이크로 프론트엔드의 선구자인 Luca Mezzalira의 이야기를 들어보겠습니다.

메모 표시

주간 업데이트

• "JAMstack 사이트에 동적 및 비동기 기능 추가", Jason Lengstorf
• "UX 디자이너를 위한 양적 데이터 도구", Adonis Raduca
• "Google Assistant 및 Amazon Alexa를 위한 음성 기술 만들기", Tris Tolliday
• "스프린트 0 너머: 팀 통합을 위한 대안", Shamsi Brinn
• "CSS Contain 속성으로 브라우저 최적화 지원" Rachel Andrew

마이크로 프론트엔드

• Luca Mezzalira의 웹사이트
• 트위터의 루카
• "마이크로 프론트엔드, 프론트엔드 아키텍처의 미래" on Medium
• 마이크로 프론트엔드에 대한 Luca의 더 많은 글은 그의 Medium 계정에서 찾을 수 있습니다.
• Luca의 책 "프론트 엔드 리액티브 아키텍처"

성적 증명서

Drew McLellan: 그는 웹 기술에 대한 Google 개발자 전문가이자 London JavaScript 커뮤니티의 관리자입니다. 15년 이상의 경험을 보유한 그는 현재 실시간으로 시청하는 수백만 명의 사용자에게 주문형 스포츠 콘텐츠를 제공하는 스포츠 비디오 플랫폼 DAZN을 설계하는 아키텍처 부사장으로 일하고 있습니다. 그는 Apress를 위한 Front-End Reactive Architectures라는 책의 저자이자 Apress, Packt Publishing, Pragmatic Bookshelf, O'Reilly의 기술 평론가이자 전 세계 기술 컨퍼런스에서 경험 많은 대중 연설가이기도 합니다. 그는 이탈리아인이고 잘생긴 수염을 자랑하며 웹 플랫폼에 대한 깊은 지식을 가지고 있습니다. 그러나 그가 한때 타조를 타고 남아메리카를 횡단했다는 사실을 알고 계셨습니까? 내 스매싱 친구, Luca Mezzalira를 환영하십시오. 안녕, 루카. 잘 지내고 있나요?

Luca Mezzalira: 굉장 합니다.

Drew: 저는 오늘 마이크로 프론트엔드라는 주제에 대해 이야기하고 싶습니다. 이제 이것은 확실히 이름으로 나에게 완전히 새로운 개념이며 많은 청취자에게도 새롭기를 기대합니다. 마이크로 프론트엔드에 대해 알아보기 전에 해결하려는 문제를 이해해야 합니다. 따라서 좀 더 전통적인 방식으로 애플리케이션을 보는 방법과 마이크로 프론트엔드가 솔루션이 될 수 있는 이러한 문제가 어떤 종류의 문제에 부딪히는지 알려주실 수 있습니다.

Luca: 좋습니다. 제 생각에는 좋은 출발점입니다. 따라서 일반적으로 새로운 미개발 프로젝트를 구현하거나 설계하고 프런트 엔드 애플리케이션으로 작업하려는 경우 활용할 수 있는 몇 가지 아키텍처가 있습니다. 단일 페이지 응용 프로그램을 사용할 수도 있고, 서버 측 렌더링 응용 프로그램을 사용할 수도 있고, 단순한 HTML 페이지로 구성된 다중 페이지 응용 프로그램을 사용할 수도 있습니다. 분명히 그것들은 매우 유효한 옵션이며 많은 개발자들이 매우 많이 사용한다고 생각합니다. 우리가 여기서 해결하려고 하는 진짜 문제는 분산된 팀과 함께 이러한 개념을 동일한 코드베이스에서 작업하는 수백 명의 개발자로 확장하는 방법입니다. 왜냐하면 현실은 특히 이러한 플랫폼에서 작업할 때입니다. 예를 들어 SaaS 플랫폼의 경우 동일한 프로젝트에서 작업하는 여러 개발자와 여러 팀이 필요합니다. 그리고 예를 들어 획득 또는 유지를 수행하는 방법은 카탈로그를 노출하는 방법이나 플랫폼의 특정 부분을 표시하는 방법에 따라 완전히 다릅니다.

Luca: 이제 제 경험상 단일 페이지 응용 프로그램으로 많은 작업을 합니다. 저는 서버 측 렌더링 응용 프로그램으로 작업하지만 DAZN의 어느 시점에서 기술 팀을 확장하는 방법에 대해 생각하라는 요청을 받았습니다. 그리고 … 백엔드에 대해 마이크로서비스인 솔루션이 있는 경우 API를 독립적으로 확장할 수 있고 특정 API의 특정 처리량에 대한 규모와 볼륨을 고려해야 합니다. 프론트 엔드에서 생각해보면 예를 들어 단일 페이지 애플리케이션을 사용하는 경우 확장해야 할 때 해결할 기술적인 문제가 없기 때문에 실제로는 더 어렵습니다. 아마도 서버 측 렌더링의 경우 일부가 있지만 예를 들어 단일 페이지 응용 프로그램의 경우 클라이언트 측, 다른 클라이언트 측이기 때문에 본질적으로 배포됩니다.

Luca: 따라서 로드하는 것은 CSS, HTML 및 JavaScript와 같은 CDN에서 제공하는 정적 파일뿐이며, 이 경우 그에 따라 확장할 수 있으므로 큰 문제는 아닙니다. 그러나 실제 문제는 동일한 플랫폼에서 작업하는 팀을 확장하는 방법입니다. 한 팀이 직면한 문제가 다른 팀이 직면한 문제와 완전히 다를 수 있고 일반적으로 수행하는 작업은 물건 사이의 많은 절충안. 라고 생각하면 일반적인 사용 사례를 생각해 봅시다. 따라서 일반적으로 플랫폼을 시작할 때 작게 시작합니다. 따라서 빠른 단일 페이지 애플리케이션을 만들려고 하고 모놀리스가 있으므로 프런트 엔드 및 백 엔드에 대해 CICD의 모든 것을 한 번만 설정한 다음 논리를 반복하기 시작합니다. 그러나 현실은 성공할 때 이 부분을 발전시켜야 하며, 비즈니스에 이익을 줄 수 있는 동일한 아키텍처를 항상 유지하는 것은 아닙니다. 병목 현상을 찾을 수 있기 때문입니다.

Luca: 이제 단일 페이지 응용 프로그램 부분으로 돌아갑니다. 따라서 단일 페이지 응용 프로그램 부분을 확장하려는 경우 문제는 기술적인 것이 아니라 원하는 경우 사람과 관련된 것입니다. 동일한 애플리케이션에서 작업하는 팀을 확장하는 방법. 그래서 제가 몇 년 전에 한 것은 가능한 아키텍처와 프론트 엔드와 백엔드를 확장할 수 있는 원칙을 살펴보기 시작한 것입니다. 따라서 백엔드 원칙에 따라 마이크로서비스를 찾을 수 있습니다. 다른 솔루션을 살펴보기 시작했고 마이크로 프론트엔드가 나왔고 처음에는 그렇게 부르지도 않았습니다. 분명히 몇 년 전에는 특정 아키텍처에 대한 이름이 없었기 때문입니다. .

Luca: 하지만 현실은 모놀리스(monolith)를 사용하고 있으므로 단일 페이지 애플리케이션을 사용하고 이를 작은 문제에 집중할 수 있는 방식으로 슬라이싱해야 합니다. 따라서 전체 응용 프로그램보다 작은 문제이며 가능한 최선의 방법으로 해결하려고 합니다. 기술적으로 말하자면. 분명히 이는 다른 모든 것에 영향을 미치지 않고 프로덕션에 배포할 수 있는 프론트엔드 애플리케이션의 독립적인 부분을 갖게 합니다. 따라서 기본적으로 Micro-frontend의 ​​과제는 단일 페이지 응용 프로그램 또는 서버 측 렌더링 응용 프로그램을 사용하여 이들의 아티팩트를 만드는 방법을 파악하는 것입니다. .

Drew: 백 엔드에서 마이크로 서비스에 대해 언급한 것입니다. 따라서 개념적으로 이것은 문제에 대한 유사한 종류의 솔루션입니다. 마이크로 서비스는 백 엔드에서 제공되지만 프런트 엔드로 이식됩니다. 그것은 대략적인 동등성입니까 아니면 더 많이 관련되어 있습니까?

루카: 네. 아니요, 이번에는 백엔드가 아닌 프론트엔드에서 마이크로서비스를 풀려고 하는 것과 같은 문제를 해결하는 방법입니다. 보통 제가 처음에 이 여정을 시작했을 때 여러분은 그것에 대해 생각하기 시작했고 다양한 접근 방식을 평가하기 시작했습니다. 그리고 지난 몇 개월 동안 저는 마이크로 프론트엔드 결정 프레임워크라고 부르는 것을 생각해 냈습니다. 기본적으로 마이크로 프론트엔드에 대한 접근 방식을 식별하기 위해 사용하는 4단계입니다. 왜냐하면 지금까지 우리는 일반적으로 우리를 위해 아키텍처를 설계한 하나의 프레임워크를 선택하고 우리는 그들의 아키텍처 위에 구현합니다. Angular에 대해 생각하거나 React 또는 Redux에 대해 생각한다면. 필요한 모든 부분이 있지만 아키텍처에 대한 결정은 내리지 않습니다. 설계 결정을 내리거나 특정 아키텍처를 기반으로 구현하는 방법을 결정합니다.

Luca: 따라서 Micro-frontend에서는 뒤로 물러나기 시작해야 합니다. 따라서 먼저 애플리케이션을 슬라이스하는 방법에 대해 생각해야 합니다. 따라서 일반적으로 두 가지 옵션이 있습니다. 수평으로 슬라이싱할 수 있으므로 동일한 보기에 여러 개의 마이크로 프런트엔드를 포함하거나 수직으로 슬라이싱할 수 있습니다. 따라서 항상 시간당 하나의 마이크로 프론트엔드를 로드합니다. 그리고 그 결정은 초기 결정을 기반으로 한 다른 특정 옵션을 계단식으로 만들기 때문에 매우 중요합니다. 따라서 먼저 내가 말했듯이 애플리케이션을 슬라이스하는 방법을 결정합니다. 두 번째는 애플리케이션을 구성하려는 방법입니다. 예를 들어 동일한 보기에서 하나 또는 여러 개의 마이크로 프론트엔드를 로드하는 앱 셸을 원합니다. 당신은 응용 프로그램의 다른 조각을 구성하는 응용 프로그램 서버, 그래서 다른 마이크로 프론트엔드를 갖고 사용자에게 최종 보기를 제공하기를 원합니다. 또는 에지 사이드 포함을 사용하려는 경우 페이지를 구성하고 해당 페이지에서 제공하기 위해 CDN 내부에 있는 표준입니다.

Luca: 이것이 당신이 가지고 있는 세 가지 옵션입니다. 그런 다음 작곡과 별개로 라우팅 방법을 생각해야 합니다. 그래서 /login 또는 /signin에서 카탈로그 부분이나 특정 세부 개체로 라우팅하는 방법을 모르겠습니다. 또한 여기에는 세 가지 옵션이 있습니다. 애플리케이션 서버에서 수행할 수 있으며, Lambda Edge 또는 CloudFlare의 다른 웹 작업자 또는 다른 모든 것을 사용하여 CDN 수준에서 수행할 수 있습니다. 또는 클라이언트 사이트를 할 수 있습니다. 따라서 앱 셸 내부에 논리가 있습니다. 이제 이 특정 URL에 대해 다른 보기 또는 다른 마이크로 프론트엔드를 로드해야 합니다. 그리고 마지막 비트는 Micro-frontend와 통신하는 방법입니다.

Luca: 일반적으로 동일한 페이지에 여러 개의 마이크로 프론트엔드가 있는 경우 이 통신을 관리하는 것이 더 복잡합니다. 다른 마이크로 프론트엔드를 독립적으로 유지해야 하기 때문입니다. 따라서 페이지 구성 방식에 대한 참조를 가질 수 없습니다. 따라서 일반적으로 각 단일 Micro-frontend 내부에 주입되는 사용자 지정 이벤트 또는 이벤트 측정기와 같은 항목을 사용할 수 있습니다. 그리고 마이크로 프론트엔드가 함께 통신합니다. 분명히 다른 경우에는 마이크로 프론트 엔드에서 수직 분할이 훨씬 더 쉽습니다. 수직 내부에서 기본적으로 수직 마이크로 프론트 엔드의 표현은 단일 페이지 응용 프로그램 또는 단일 페이지이기 때문입니다. 그리고 이 경우 전체 마이크로 프론트엔드에서 공유 상태를 만들고 공유하는 것이 더 쉽습니다.

Luca: 그렇다면 여러 개의 마이크로 프론트엔드를 모두 함께 사용하는 것에 대해 생각한다면 마이크로 프론트엔드 간에 상태를 공유하는 것을 피해야 합니다. 그렇지 않으면 사물을 결합하는 것이기 때문입니다. 여기에서 전체 개념 대신 분리하고 독립적으로 배포합니다. 따라서 첫 번째 결정인 수평 분할 또는 수직 분할의 문제가 완전히 다르며 어떤 것이 우리의 사용 사례에 맞는지 잘 알고 있어야 한다고 가정해 보겠습니다.

Drew: 따라서 마이크로 프론트엔드는 특정 기술 솔루션이라기보다 해결하려는 특정 문제에 적합한 기술이 무엇이든 구현하는 디자인 패턴과 매우 비슷합니다.

Luca: 예, 기술보다 더 중요한 것은 우리가 올바른 작업에 적합한 아키텍처를 선택하는 것이라고 생각합니다. 예를 들어 말씀드리자면... 유명한 프레임워크가 있습니다. 마이크로 프론트엔드에서는 상당히 새로운 것으로, SAP 오픈 소스에서 출시한 Luigi 프레임워크라고 합니다. 그들이 하는 일은 내부에 마이크로 프론트엔드를 래핑하는 일부 iframe을 만드는 것입니다. 이제 그것에 대해 생각한다면, 예를 들어 요즘 iframe을 사용하는 경우, SEO 또는 필수 기능인 다른 기능으로 공개 웹사이트에 있는 것이 문제가 될 수 있습니다.

Luca: 하지만 SAP의 경우 생각해보면 사용자가 사용하는 브라우저를 제어할 수 있는 엔터프라이즈 애플리케이션과 같은 환경을 제어할 수 있으며 다중 또는 브라우저의 다른 버전. 그래서 그들에게 이러한 것들은 일정한 응용 프로그램의 특정 영역을 가질 수 있게 하고 아무런 문제 없이 독립적으로 변경되는 특정 영역을 가질 수 있도록 합니다. 그러나 분명히 iframe 솔루션은 다른 상황에서는 작동하지 않을 것입니다. Spotify라는 또 다른 예를 들자면 처음에는 iframe을 사용하고 있습니다. 사실, 탁상 출판물은 여전히 ​​여러 iframe으로 구성되어 있으며 각 단일 iframe은 음악 플레이어나 권장 사항 등을 수행하는 작은 응용 프로그램입니다. 그들은 웹에서 동일한 접근 방식을 시도했지만 단일 페이지 애플리케이션으로 다시 이동하기 위해 올해 그것을 기각했습니다.

Luca: 즉, 기술 블로그에서 동일한 공급업체가 파일을 제출할 때마다 로드해야 하는 iframe을 사용하는 수백만 명의 사용자에게 이를 적용하면 분명히 그렇게 말하는 이유를 설명합니다. 그러면 종속 항목이 많이 복제되고 페이지와 상호 작용하는 시간이 더 길어집니다. 따라서 실제로 이 접근 방식은 특정 사용 사례에 적합할 수 있지만 모든 사용 사례에 적합해서는 안 됩니다. 그렇기 때문에 이전에 설명했듯이 이러한 문제를 해결하는 데 도움이 되는 결정 프레임워크가 있고 다음과 같이 말할 수 있는 경우 다음과 같이 말합니다. 내가 작곡하고 싶을 때, 내가 라우팅하고 싶을 때, 내가 의사 소통하고 싶을 때 적시에 올바른 결정을 내릴 수 있도록 안내해야합니다.

Luca: 그렇다면 분명히 그 네 가지 결정 외에도 많은 다른 결정이 있습니다. 모든 마이크로 프론트엔드에 걸쳐 있는 디자인 시스템의 일관성을 만드는 방법과 같습니다. 아니면 어떻게 종속성을 관리하고 마이크로 프론트엔드 내부에서 종속성의 충돌을 피하는지 모르겠지만 현실은 앞에서 언급한 네 가지 결정을 통해 다른 모든 결정을 지나친 생각의 문제, 이미 초석인 4개의 기둥을 설정해 놓았기 때문에 최선의 해결책이 되는 문제, 다른 모든 결정을 내릴 수 있도록 하는... 쉬운 방법이 아니라 리뷰보다 빠른 방법으로 말씀드립니다. 또는 기회의 스펙트럼.

Drew: 이전에 마이크로 프론트엔드가 조직 내의 팀 구조와 같은 응용 프로그램에서 많은 사람들이 작업하는 데 도움이 될 수 있다고 언급했습니다. 그렇다면 어떤 의미가 있으며 팀이 분산되어 있거나 함께 배치되어 있거나 거기에 직면한 문제가 있는 경우 차이가 있습니까?

루카: 네. 그래서 DAZN의 스토리가 무엇인지 알려드릴 수 있습니다. 제가 일하고 있는 회사입니다. 현재 DAZN에서 우리는 멋진 도전을 했습니다. 그래서 현재 300명이 넘는 사람들이 플랫폼의 전면과 후면에서 일하고 있습니다. 전 세계 스포츠 이벤트를 생중계하는 OTT 플랫폼입니다. 그리고 흥미로운 점은 모든 마이크로서비스가 우리가 어느 정도 관리하는 방법을 알고 있고 분산된 팀이 있다는 것입니다. 그래서 우리는 4개의 개발 센터를 가지고 있습니다. 우리는 각 단일 개발 센터에 팀을 배치하고 싶었고 이 접근 방식을 시도했고 꽤 잘 작동했습니다. 따라서 Micro-frontend를 사용하여 서로 다른 위치에 서로 다른 비즈니스 도메인을 제공하고 특정 비즈니스 도메인 내에서 팀 간의 교차 커뮤니케이션을 허용할 수 있었습니다. 왜냐하면 동일한 비즈니스 도메인의 다른 팀과 대화해야 하는 최악의 시나리오 때문입니다. , 당신은 당신의 책상에서 도보 거리에 도달합니다. 대신 배급 팀에서 특정 사항에 대해 논의해야 하는 경우 암스테르담 대신 런던에 있거나 폴란드에 있는 회사 대신 누군가와 통화를 구성하면 됩니다.

루카: 하지만 그런 종류의 의사소통은 같은 장소 내에서 팀 간에 일어나는 것보다 더 드뭅니다. 이것이 우리가 작업을 시작한 이유입니다. 그래서 그들이 가장 먼저 한 일은 사용자들이 우리 웹사이트와 어떻게 상호작용하는지, 회사가 어떻게 구성되어 있는지 살펴보는 것이었습니다. 현재 우리가 작업하고 있는 4가지 핵심 영역인 획득 및 유지를 식별할 때 여러 TV 및 모바일에 핵심 애플리케이션을 이식하고 비디오 플레이어 및 검색 단계인 핵심 도메인이 있다고 가정해 보겠습니다. 우리의 콘텐츠. 마지막으로 모든 백오피스 요소입니다. 저는 이 네 가지 영역과 우리가 각 단일 개발 센터에 할당한 네 가지 영역을 식별할 수 있었습니다.

Luca: 분명히 그 영역 사이에 몇 가지 접촉 지점이 있지만, 예를 들어 다른 위치에 있는 다른 팀과 초기 워크샵을 갖고 완화하고 동일한 API 계약을 위해 작업한다고 가정할 수 있는 방법이 있습니다. 개발 중에 몇 가지 체크포인트를 갖는 것과 동일한 목표입니다. 그러나 마이크로 프론트엔드로 접근할 수 있는 접근 방식의 좋은 점은 마침내 우리 시스템이 어떻게 작동하는지 깊이 이해했다는 사실입니다. 우리는 앉아서 우리가 어떻게 구성되어 있는지 분석하고 우리가 영향을 받는 방식뿐만 아니라 회사가 일하는 방식도 바꿨습니다. 그리고 그것은 그들이 지금까지 보아온 것과는 다른 접근 방식이었습니다. 그러나 각 단일 팀이 동일한 도메인의 동일한 위치에 있는 팀과 상호 작용할 수 있는 경우에는 꽤 잘 작동하고 있음을 증명하고 있습니다.

Luca: 도메인 기반 디자인에 대해 이야기한다면 그들은 정확히 같은 언어로 이야기하고 있습니다. 즉, 다른 팀과 상호 작용해야 하는 경우 말 그대로 워크샵을 공유하거나 다른 개발 센터로 날아갈 수 있으며 문제가 되지 않습니다. 그러나 이런 식으로 처리량을 늘리고 통신 오버헤드를 줄이고 작업 중인 다른 상황에서 발생하는 종속성 정도를 줄이도록 하겠습니다.

Drew: 그리고 이 모든 팀이 표준화된 JavaScript 프레임워크처럼 사용해야 합니까? 그것들은 모두 같은 것으로 코딩해야 합니까, 모두 React 또는 Angular여야 합니까, 아니면 그들 사이의 상호 운용성을 가능하게 해야 합니까, 아니면 사람들이 다른 마이크로 프론트엔드에 대해 다른 것을 사용할 수 있습니까?

루카: 네. 그래서 DAZN에서 우리는 마이크로 프론트엔드를 수직으로 자르기로 결정했고, 그것은 우리가 각각의 마이크로 프론트엔드에 필요한 기술을 자유롭게 선택할 수 있는 결정이었습니다. 시간당 하나의 마이크로 프론트엔드를 로드할 때마다 이는 예를 들어 방문 페이지가 있는 방식이 로그인/가입 여정과 다르다는 것을 의미합니다. 그래서 우리는 업데이트 할 수 있습니다 ... 우리는 현재 주로 React를 사용하고 있습니다. 그러나 예를 들어 React 16이 프로덕션 React 16에서 릴리스할 수 있었던 릴리스였을 때, 또한 랜딩 페이지에 대한 안정적인 버전이 아닌 경우 모든 영향 없이 작동하는지 확인합니다. 다른 팀.

루카: 그리고 그들만의 속도로, 그들만의 속도로, 그들은 자신들의 자료를 업데이트하고 있었습니다. 따라서 특정 사용자 수와 함께 기존 응용 프로그램에 대해 새로운 기술이나 새로운 가정을 시도한다고 가정해 보겠습니다. 프론트 엔드에 대한 후보 릴리스도 구현하기 때문입니다. 우리는 프로덕션에서 특정 시간을 시도하고 작동 방식을 확인할 수 있는 몇 가지 방법을 구현합니다.

Luca: 이러한 접근 방식의 장점은 전체 스택에서 공통 분모를 갖는 것보다 올바른 작업에 적합한 도구를 독립적으로 결정할 수 있다는 것입니다. 상상할 수 있듯이 프로젝트 작업을 시작했을 때 처음 몇 년 동안 내린 결정은 회사가 성장하고 비즈니스가 발전하고 성숙해진 궤적에서 내린 결정과 다를 수 있기 때문입니다. 그리고 도전은 완전히 다릅니다. 따라서 우리가 2년 전에 취한 것과 동일한 결정을 고수한다는 사실에 대해 생각해보면 충분히 유연하거나 민첩하지 않을 것입니다. 특히 DAZN과 같은 기관에서는 기본적으로 0명에서 3년 안에 3000명으로 직원을 이동합니다. 상상할 수 있듯이 엄청난 성장이었고 회사와 사용자 기반 모두에서 엄청난 성장이었습니다.

Drew: 서로 다른 마이크로 프론트엔드가 데이터를 공유하고 서로 통신할 수 있는 확립된 방법이 있습니까?

루카: 네, 있습니다. 어떤 결정 프레임워크, 어떤 경로를 택할지에 따라 다릅니다. 수직 슬라이스를 취하면 매우 쉬워지기 때문입니다. 따라서 Micro-frontend를 통해 통신하기 위해 우리가 가지고 있는 것은 자체 내부에 Micro-frontend에서 로드되는 앱 셸입니다. 그리고 그것이 하는 일은 다른 마이크로 프론트엔드나 웹 스토리지, 세션이나 로컬 스토리지 또는 메모리에 공유되어야 하는 모든 것을 저장하는 것입니다. 그런 다음 해당 정보를 기반으로 Micro-frontend가 로드되고 앱 셸에서 이 정보로 검색한 다음 이를 소비, 수정 또는 변경할 수 있습니다. 애플리케이션을 슬라이스하는 방법은 전적으로 사용자에게 달려 있지만 이 경우 예를 제공하기 위해 인증된 사용자이고 로그인 페이지로 이동해야 하는 경우, 사용자가 로그인하고 API를 사용하는 경우 그들은 JWT 토큰을 제공하고 있으며, Micro-frontend는 이를 앱 셸에 전달하고 앱 셸에서 시작하여 웹 저장소를 저장했습니다.

Luca: 그런 다음 앱 셸이 해당 특정 애플리케이션 및 인증된 영역에 대한 새 인증 영역을 로드한 후 앱 셸에서 JWT 토큰을 검색하고 새로 고침 액세스 토큰을 수행하거나 내부에서 시작하는 일부 데이터의 유효성을 검사합니다. JWT 토큰. 따라서 기본적으로 다른 Micro-frontend가 자체 휠에서 생성한 정보를 사용하고 있습니다.

Drew: 이것은 매우 흥미로운 개념처럼 들리고 저는 잠재적으로 이러한 방식으로 작업할 때 많은 큰 이점을 볼 수 있지만, 확실히 도전이 없이는 불가능합니다. 이런 식으로 물건을 설계할 때 처리하기 더 어려운 특정 사항이 있습니까?

Luca: 제가 생각하는 가장 중요한 문제는 사고방식의 전환입니다. 예를 들어, 우리가 사용하기 전에는 전체 애플리케이션에 대한 모든 것을 결정하는 기술 책임자 또는 수석 개발자가 모든 결정을 내리는 데 익숙했기 때문입니다. 이제 마지막으로 이 중앙 집중식 엔티티에서 각 주에 대해 로컬인 분산된 엔티티로 이동합니다. 상상할 수 있듯이, 이것은 경로를 추적하는 누군가가 있기 전에 우리가 도메인 내에서 올바른 경로를 정의하는 최상위에 있는 여러 사람이 있고 이것은 엄청난 변화이기 때문에 몇 가지 문제를 가져옵니다. 마음의.

Luca: 다른 한편으로는 복잡한 추상화를 수행하는 것이 코드를 복제하는 것보다 더 비용이 많이 들 수 있다는 사실을 때때로 받아들이고 있다고 생각합니다. 개발자가 "좋아, 이제 프로젝트 내에서 이 개체나 이 특정 라이브러리를 수백 번 재사용할 수 있다"고 생각하기 때문에 개발자를 관리하는 데 매우 어려운 문제가 있다는 것을 알고 있습니다. 하지만 현실은 매우 다릅니다. 나는 추상적인 구성 요소 라이브러리를 보았고 그들은 그것을 최고의 코드로 또는 완벽한 형태로 최고의 코드로 만드는 데 많은 시간을 할애했습니다. 그러나 현실은 단 두 번만 사용되었습니다. 그래서 그렇게 하려는 노력은, 꼭 그렇지는 않았습니다. 다른 쪽 라이브러리에서 특정 구성 요소에 대한 몇 가지 사용 사례로 시작하는 것을 보았습니다. 그런 다음 이러한 사용 사례는 10개가 되었고 코드를 유지 관리할 수 없게 되었습니다.

Luca: 따라서 동일한 구성 요소 내에 새로운 기능을 추가하는 것은 이점보다 위험할 수 있습니다. 그래서 마이크로 프론트엔드에서 우리가 이해해야 할 또 다른 것은 얼마나 공유하고 싶은지, 얼마나 복제하고 싶은지 입니다. 그리고 솔직히 복제하는 데 아무런 해가 없습니다. 예를 들어 우리의 경우 바닥글과 머리글이 중복되어 있는데, 이는 주로 4년 동안 머리글이 세 배나 변경되었기 때문에 그렇게 한 것입니다. 우리가 이들을 중앙 집중화하고 팀에 할당되고 모든 팀, 우리가 보유한 수백 명의 개발자에 대한 외부 종속성을 생성한다는 사실을 상상할 수 있듯이 더 많은 문제가 회사에 이익이 되기 때문에 우리는 엄청난 가치를 추가하지 않습니다.

Luca: 동시에 현재 우리는 지불 라이브러리가 될 공유 라이브러리를 리팩토링하고 있습니다. 분명히 지불에는 그 뒤에 약간의 논리가 있고 한 번 변경하려는 경우 여러 부분에 두 번 적용하고 싶지 않기 때문입니다. 암호. 우리는 진실의 근원이 되는 단 하나의 라이브러리를 갖고 싶지만 헤더와 푸터에 대해서도 불일치가 있거나 픽셀에 대해 또는 일주일 후에 배포되는 기능이 있는 경우에도 손상되지 않을 것입니다. 애플리케이션.

Drew: 사람들이 응용 프로그램을 평가하고 "아, 이것이 마이크로 프론트엔드 종류의 아키텍처로 이동하기에 좋은 후보가 될 것인가?"라고 생각할 때 찾아야 할 몇 가지 분명한 징후가 있습니까?

Luca: 예, 그래서 제 제안은 무엇보다도 Micro-frontend가 어떻게 구축되어야 하는지 정확히 알지 못한다면 Micro-frontend로 미개발 프로젝트를 시작하지 않을 것입니다. 그리고 일반적으로 이 정보가 있을 가능성은 매우 낮습니다. 특히 새 플랫폼이나 새 프로젝트가 있고 이 작업을 처음으로 수행하는 경우 이 정보를 찾는 것이 쉽지 않을 수 있기 때문입니다. 일반적으로 내가 제안하는 것은 단일 페이지 애플리케이션이 될 기존 아키텍처로 시작한 다음 이를 발전시키는 것입니다. 특히 예를 들어 레거시 응용 프로그램에 Micro-frontend를 사용하거나 응용 프로그램의 특정 부분을 교체하려는 경우 또는 여러 팀을 위해 발전 및 확장하려는 프로젝트가 있는 경우 이 세 가지 사용 사례가 있다고 생각합니다. 마이크로 프론트엔드 아키텍처에 매우 적합하다고 생각합니다. 분명히 그것이 지금부터 모든 것이 마이크로 프론트엔드로 만들어져야 한다는 것을 의미하지는 않습니다.

Luca: 이것이 바로 프런트 엔드 세계에서 활용할 수 있는 추가 아키텍처입니다. 그리고 지금까지 우리는 일정한 양의 아키텍처를 가지고 있었지만 이제는 추가로 하나 더 가지고 있습니다. 그러나 서버 측 렌더링이나 단일 페이지 애플리케이션 이전에 여러 프레임워크 등에 의해 탐색되고 구현된 명확한 패턴이 있는 경우 분명히 해야 하기 때문에 이는 많은 도전 과제입니다. 현재 마이크로 프론트엔드는 일을 하는 한 가지 방법입니다. 그러나 결정 프레임워크를 추가하면 사람들이 사용 사례에 맞는 올바른 결정을 내릴 수 있을 것입니다. 종종 마이크로 프론트엔드가 무엇이고 어떻게 사용해야 하는지에 대해 많은 오해가 있기 때문입니다. 그리고 많은 사람들은 한 가지 보기 또는 다른 것에서 너무 많은 라이브러리를 갖는 것이 나쁘다고 생각합니다.

Luca: 현실은 개념을 깊이 이해하고 이를 구현하는 방법을 이해한 다음 작업을 시작할 수 있어야 한다는 것입니다. 기술적인 문제가 있고 내려야 할 결정이 많다는 점에 전적으로 동의합니다. 그리고 코드를 작성하고 생각하는 편집기 앞에서 바로 시작할 수는 없습니다. 이제 마이크로 프론트엔드를 만들고 있습니다. 건축물. 개념을 이해하고 컨텍스트를 이해하고 생성하고 이에 대한 거버넌스를 해야 하기 때문에 복잡성은 코드를 작성하는 것뿐만 아니라 CICD 부분 SEO 부분 등에서 모든 조각이 어떻게 함께 맞춰지는지 이해해야 하기 때문입니다.

Luca: 따라서 마이크로 프론트엔드는 어느 정도의 유연성을 제공하고 거버넌스 권한을 정의하는 데 많은 노력이 필요합니다. 거버넌스 권한이 있으면 모든 것이 순조로울 것이기 때문입니다. 종종 그리고 불행하게도 나는 기업이 거버넌스 측면에서 충분한 시간을 보내지 않는 경우를 보았습니다. 예를 들어 CICD를 이해하는 것은 이것이 중요하지 않다고 생각하기 때문입니다. 그러나 마이크로 서비스와 같은 마이크로 프론트엔드의 경우 자동화 권한이 있으면 개발 속도를 높일 수 있습니다. 자동화 비트에 충분한 시간을 투자하지 않으면 이점보다 부담이 더 커질 위험이 있습니다.

Drew: 웹 개발 세계에서는 사람들이 문제를 진정으로 이해하기도 전에 기술적 솔루션에 뛰어들 위험에 처하는 것과 같습니다. 그리고 Micro-frontend를 사용하면 문제를 보고 해결하려는 문제가 무엇인지 알기 위해 솔루션을 구현해야 하는 경우가 많습니다. 마이크로 프론트엔드의 특성은 기존 애플리케이션에 통합을 시작하고 작은 문제를 발견하고 그 문제를 해결하기 위해 마이크로 프론트엔드로 교체하는 것을 매우 쉽게 만든다고 생각합니다. 합리적인 제안입니까?

루카: 예, 그렇게 말하고 싶습니다. 이 경우 이 방법으로 시작하면 수평 슬라이싱보다 수직 슬라이싱을 더 많이 보는 것이 좋습니다. 그렇지 않으면 너무 많은 문제를 해결해야 하기 때문입니다. 예를 들어 Angular Angular의 새 버전으로 이동하려고 합니다. I-frame을 사용하지 않고 두 개의 Angular 버전을 함께 사용해야 하는 경우 복잡하거나 불가능할 수도 있습니다. 따라서 시작하면 기술적 관점이 아니라 비즈니스 관점에서 도전 과제를 확인하는 측면이 아닙니다. 예를 들어 다른 버전이나 같은 버전이지만 프레임워크의 더 많은 업데이트 버전으로 작성하고 싶은 로그인 부분을 취할 수 있으며 그것이 좋은 방법이 될 수 있습니다. 그런 다음 경로를 통해 라우팅합니다. 그것은 느리지만 꾸준히 특정 애플리케이션을 대체하는 좋은 방법이 될 수 있습니다.

Luca: 우리의 경우에 수행한 작업은 기본적으로 마이크로서비스에 대해 잘 알려진 패턴인 스트랭글러 패턴을 프런트 엔드에 적용하는 것입니다. 따라서 URL과 사용자의 브라우저 및 국가를 기반으로 합니다. 너무 느리지만 꾸준히, 기본적으로 우리는 단일 페이지 애플리케이션을 죽이고 있었습니다. 이 경우에는 새 애플리케이션을 더 자주 릴리스하고 사용자의 행동을 확인했습니다. 경험을 개선했다면 시스템에 문제를 일으키고 있었습니다. 아니면. 이를 통해 비즈니스에 즉각적인 가치를 제공할 수 있었지만 동시에 가정을 테스트하고 올바른 방향으로 가고 있는지 확인할 수 있었습니다.

Drew: 많은 사람들이 직면하고 있는 몇 가지 문제에 대한 매우 매력적인 솔루션처럼 들립니다. 내가 개발자로서 마이크로 프론트엔드에 대한 더 많은 조사를 시작하고 싶다면 어디에서 시작하는 것이 좋을까요?

Luca: 예, 현재 여가 시간을 많이 사용하여 이러한 아키텍처를 옹호하는 데 많은 시간을 할애하고 있습니다. 왜냐하면 많은 오해가 있다고 생각하기 때문입니다. 내 Medium 계정에서. 나는 거기에서 사용할 수 있는 여러 기사를 썼습니다. A는 유튜브에서 아무 문제 없이 찾아볼 수 있는 많은 회의 영상을 녹화했습니다. 일부 프레임워크에 대한 코드 예제를 찾고 있다면 제가 제안하고 싶은 다른 것은 단일 SPA입니다. 주로 수직 슬라이싱 접근 방식이 있기 때문에 선택하고 선택하는 것이 더 쉽습니다. 이 아키텍처의 이점을 이해하기 시작할 수 있습니다. 그런 다음 사용할 수 있는 다른 항목이 많이 있습니다. Before I mentioned Luigi framework, as well as many others that are currently out there that are allowing you to compose multiple Micro-frontends in the same view.

Luca: Like another one in my head is TailorJS is another interesting. But definitely there is open components that is one developed by Open Table. But in general there are plenty of opportunity if you start to search about Micro-frontend, they're out there.

Drew: That sounds great. Is there anything else that you wanted to talk about with regard to the Micro-frontends?

Luca: Yeah. Personally I would suggest to take an open mind approach on learning this architecture and this approach, technical approach, mainly because I believe that there is a lot of good, but we need to, let's say, invest a bit of time and spend a bit of time to deeply understand how the things are working. Because obviously there isn't, just one way to do things. We are used that we take a framework and immediately we start to work on it and it's super productive, if you think about that.

Luca: But in this case you need to spend a bit of more time understanding, as you said a couple of times, the problem. Understand which is the pattern that would allow you to express better not only from a technical point of view but those two from our organizational point of view, the solution that you have in mind.

Drew: So I've been learning all about Micro-frontend today. What have you been learning about lately?

Luca: Recently there are two things that I'm learning. So last week I was in Las Vegas during the AWS event and is obviously a cloud conference. Pretty amazing, 70,000 people, a lot of sessions that were spreading several hotels in Vegas. And there for me, a serverless is a paradigm that I'm studying the most because I truly believe that in the future that will be the way how we are going to design and implement software and obviously AWS is very prominent on this approach.

Luca: And the second topic is around management and how to be a leader of a tech team. Because obviously I'm SVP of architecture. I have a team of architects that I'm leading and you can never rest because you need to not only to be on top of the technical side, but you need also to understand the people problems, understand how you can make them successful. Because obviously if they are successful, you are successful. You are first a technical facilitator to a certain extent. So that for me, those for me are the two things that currently I'm studying on top of exploring the Micro-frontend world.

Drew: If you, dear listener, would like to hear more from Luca, you can follow him on Twitter where he's @LucaMezzalira or find his activities collected together at Lucamezzalira.com. Thanks for joining us today, Luca. Did you have any parting words?

Luca: No, but thank you very much for listening up to now.