Cloudflare 플랫폼에서 버티컬 마이크로프론트엔드 구축

본 콘텐츠는 사용자의 편의를 고려해 자동 기계 번역 서비스를 사용하였습니다. 영어 원문과 다른 오류, 누락 또는 해석상의 미묘한 차이가 포함될 수 있습니다. 필요하시다면 영어 원문을 참조하시기를 바랍니다.

오전 6:55에 업데이트됨 PT

오늘 우리는 버티컬 마이크로프론트엔드(VMFE)를 위한 새로운 Worker 템플릿을 도입합니다. 이 템플릿 을 사용하면 여러 독립적인 Cloudflare Workers 를 단일 도메인에 매핑할 수 있습니다. 이를 통해 팀은 마케팅, 문서, 대시보드를 독립적으로 배포하는 등 완전히 분리된 환경에서 작업하면서도 사용자에게는 하나의 원활한 애플리케이션을 제공할 수 있습니다.

대부분의 마이크로프론트엔드 아키텍처는 "수평적"입니다. 이는 단일 페이지의 다른 부분 을 다른 서비스에서 가져옴을 의미합니다. 수직 마이크로프론트엔드는 URL 경로로 애플리케이션을 분할하여 다른 접근 방식을 취합니다. 이 모델에서 `/blog` 경로를 소유한 팀은 단순히 구성 요소만을 소유하는 것이 아닙니다. 프레임워크, 라이브러리 선택, CI/CD 등 해당 경로에 대한 전체 버티컬 스택을 소유합니다. 전체 경로 스택 또는 경로 집합을 소유하면 팀이 작업에 대한 진정한 소유권을 가지고 자신 있게 배포할 수 있습니다.

팀은 성장하면서 문제에 직면합니다. 여기에서 다양한 프레임워크가 다양한 사용 사례를 지원합니다. 예를 들어 마케팅 웹 사이트는 Astro로 더 잘 활용하고 대시보드는 React로 더 잘 활용할 수 있습니다. 또는 많은 팀이 공동으로 배포하는 단일 코드 베이스가 있다고 가정해 보겠습니다. 여러 팀에서 업데이트에 새로운 기능을 추가하려는 경우, 한 팀에서 회귀가 발생했다는 이유로 실망스러울 정도로 롤백될 수 있습니다. 이 문제를 어떻게 해결할 수 있을까요? 기술 구현 세부 정보를 사용자가 알지 못하게 하고 팀에서 완전한 자율성과 자체 도메인 제어로 일관된 사용자 경험을 제공할 수 있도록 해야 할까요?

수직형 마이크로프론트엔드가 해답이 될 수도 있습니다. 두 팀이 개발자의 고충 사항을 어떻게 해결하는지 함께 살펴보겠습니다.

버티컬 마이크로프론트엔드는 단일 독립 팀이 사용자 인터페이스부터 CI/CD 파이프라인에 이르기까지 애플리케이션 기능의 전체 조각을 소유하는 아키텍처 패턴입니다. 이러한 조각은 개별 Workers를 특정 경로와 연결할 수 있는 도메인의 경로로 정의됩니다.

/      = Marketing
/docs  = Documentation
/blog  = Blog
/dash  = Dashboard

여기에서 한 걸음 더 나아가 대시보드와 같은 보다 세분화된 하위 경로 Worker 연결에 집중할 수 있습니다. 대시보드 내에서는 URL 경로에 깊이를 추가하여 다양한 기능 또는 제품을 분류할 수 있습니다(예: /dash/product-a)를 사용하고 두 제품 간을 탐색하는 것은 두 개의 완전히 다른 코드 베이스를 의미할 수 있습니다. 

이제 수직형 마이크로프론트엔드를 통해 다음 사항도 수행할 수 있습니다.

/dash/product-a  = WorkerA
/dash/product-b  = WorkerB

위의 각각의 경로는 그들 사이에 공유 코드가 없는 자체 프런트엔드 프로젝트입니다. 제품 a 및 제품 b 경로는 자체 팀에서 정의하고 소유하는 자체 프레임워크, 라이브러리, CI/CD 파이프라인이 있는 별도로 배포된 프런트엔드 애플리케이션에 매핑됩니다. 마침내

이제 여러분은 처음부터 끝까지 여러분의 코드를 소유할 수 있습니다. 하지만 이제 우리는 이러한 개별 프로젝트를 하나로 연결하고, 심지어 통합 경험인 것처럼 느낄 수 있는 방법을 찾아야 합니다.

대시보드에는 자체 제품을 소유한 많은 개별 팀이 있기 때문에 Cloudflare도 이러한 어려움을 경험합니다. 팀에서는 자신의 통제 범위 밖의 변경 사항이 사용자의 제품 경험에 영향을 미친다는 사실을 인지해야 합니다. 

내부적으로는 현재 저희 자체 대시보드에도 비슷한 전략을 사용하고 있습니다. 사용자가 코어 대시보드에서 ZeroTrust 제품으로 이동할 때, 실제로는 완전히 별개의 두 프로젝트이며 사용자는 /:accountId/one 경로를 통해 해당 프로젝트로 라우팅되는 것입니다.

이러한 개별 프로젝트를 짜깁기하여 통합된 경험처럼 느껴지도록 하는 것은 생각만큼 어렵지 않습니다. 몇 줄의 CSS 마법만 수행하면 됩니다. 저희가 절대 원하지 않는 일은 구현 세부 정보와 내부 결정이 사용자에게 유출되는 것입니다. 이 사용자 경험을 하나의 응집력 있는 프런트엔드처럼 느끼게 하지 못한다면 사용자에게 심각한 부당한 조치를 취한 것입니다. 

이러한 교묘한 기능을 수행하기 위해 보기 전환과 문서 프리로드가 어떻게 작용하는지 이해하는 과정을 잠시 살펴보겠습니다.

최종 사용자에게는 매끄럽게 느껴지도록 하면서도 서로 다른 두 페이지 사이를 원활하게 탐색하고 싶은 경우 보기 전환 이 아주 유용합니다. 해당 페이지에 특정 문서 개체 모델 요소 를 정의하여 다음 페이지가 표시될 때까지 유지하고 변경 사항이 처리되는 방식을 정의하면, 멀티 페이지 애플리케이션에 매우 강력한 quilt-stitching 도구가 됩니다.

그러나 다양한 버티컬 마이크로프론트엔드를 다르게 느껴지도록 하는 것이 허용 범위 이상인 경우도 있을 수 있습니다. 예를 들어 마케팅 웹 사이트, 문서, 대시보드가 각각 고유하게 정의되어 있을 수도 있습니다. 사용자는 세 부분 사이를 탐색할 때 이 세 가지 요소가 모두 응집력을 느끼기를 기대하지는 않을 것입니다. 하지만... 대시보드와 같은 개별 경험에 버티컬 조각을 도입하기로 결정했다면(예: /dash/product-a & /dash/product-b)에 저장되어 있는 경우 사용자는 자신이 그 아래에 있는 두 개의 서로 다른 리포지터리/workers/projects라는 사실을 절대 알지 못해야 합니다.

자, 대화는 충분합니다. 일을 시작하겠습니다. 사용자에게는 두 개의 개별 프로젝트를 하나인 것처럼 느끼게 하는 작업이 힘들 것이라고 언급했지만,CSS 보기 전환에 대해 아직 소식을 못 읽으신 분을 위해 말씀을 드리겠습니다.

단일 페이지 앱(SPA) 또는 다중 페이지 앱(MPA)과 같은 다양한 보기 간을 애니메이션으로 전환할 수 있으며, 이를 마치 하나인 것처럼 느낄 수 있다면 어떨까요? 보기 전환을 추가하기 전에 두 개의 서로 다른 Workers가 소유한 페이지 간을 탐색하는 경우 전체 다음 페이지 렌더링이 시작될 때까지 중간 로딩 상태는 브라우저에 수백 밀리초 동안 흰색 흰색 화면이 됩니다. Pages는 응집력이 없다고 느껴지며, 단일 페이지 애플리케이션처럼 느껴지지 않을 것입니다.

^{각 사이트 간에 다중 탐색 요소로 나타납니다.}

요소가 흰색의 빈 페이지를 보는 대신 그 곳에 남아 있게 하려면 CSS 보기 전환을 정의하여 이를 달성할 수 있습니다. 아래 코드를 사용하여 보기 전환 이벤트가 발생하려고 할 때 nav 문서 개체 모델 요소를 화면에 표시하도록 현재 문서 페이지에 알리고, 기존 페이지와 대상 페이지 사이에 모양에 변화가 있다면,이제 들어오고 나가는 전환으로 활기를 불어넣겠습니다.

갑자기 두 개의 서로 다른 Workers가 하나처럼 느껴집니다.

@supports (view-transition-name: none) {
  ::view-transition-old(root),
  ::view-transition-new(root) {
    animation-duration: 0.3s;
    animation-timing-function: ease-in-out;
  }
  nav { view-transition-name: navigation; }
}

^{세 개의 서로 다른 사이트 사이에서 단일 탐색 요소로 나타납니다.}

두 페이지 간에 전환할 때 매끄럽게 보이면서 클라이언트 측 SPA처럼 즉각적으로 느껴지기를 원합니다. 현재 Firefox와 Safari는 Speculation Rules를 지원하지 않지만, Chrome/Edge/Opera는 최근에 등장한 기술을 지원합니다. Speculation Rules API는 향후 탐색 시, 특히 문서 URL의 성능을 개선하도록 설계되어, 다중 페이지 애플리케이션이 단일 페이지 애플리케이션처럼 느껴지도록 합니다.

이를 코드로 나눠보면, 지원하는 브라우저에 공유 탐색을 통해 연결되어 있는 웹 앱에 연결된 다른 버티컬 조각을 프리페치하는 방법을 알려주는 특정 형식의 스크립트 규칙을 정의해야 합니다.

<script type="speculationrules">
  {
    "prefetch": [
      {
        "urls": ["https://product-a.com", "https://product-b.com"],
        "requires": ["anonymous-client-ip-when-cross-origin"],
        "referrer_policy": "no-referrer"
      }
    ]
  }
</script>

그러면 응용 프로그램이 다른 마이크로프론트엔드를 프리페치하여 메모리 내 캐시에 저장하므로, 해당 페이지로 이동할 때 매우 즉각적이라고 느낄 수 있습니다.

사용자는 그들 사이에 약간의 부하를 예상할 수 있으므로 명확하게 식별 가능한 수직 조각(마케팅, 문서, 대시보드)의 경우 이를 요구하지 않을 가능성이 높습니다. 하지만, 특정 가시적 경험(예: 대시보드 페이지 내에서).

View Transitions 와 Speculation Rules 사이에서 완전히 다른 코드 저장소를 하나로 묶어 단일 페이지 애플리케이션에서 제공하는 것처럼 느낄 수 있습니다. 와일드라고 물으신다면요.

이제 우리는 여러 애플리케이션을 호스팅할 메커니즘과 요청이 스트리밍될 때 이들을 함께 연결할 수 있는 방법이 필요합니다. 단일 Cloudflare Worker를 "라우터"로 정의하면 에지의 단일 논리적 지점에서 네트워크 요청을 처리한 다음 해당 URL 경로를 담당하는 수직 마이크로프론트엔드로 전달할 수 있습니다. 단일 도메인을 해당 Worker 라우터에 매핑하고 나머지는 “그냥 작동”하는 것도 문제가 되지 않습니다.

Cloudflare Worker 서비스 바인딩을 아직 다루지 않았다면 잠시 시간을 내어 그렇게 할 가치가 있습니다.

서비스 바인딩을 사용하면 공개적으로 액세스 가능한 URL을 통과하지 않고도 한 Worker가 다른 Worker를 호출할 수 있습니다. 서비스 바인딩을 통해 Worker A는 Worker B의 메서드를 호출하거나 Worker A의 요청을 Worker로 전달할 수 있습니다. 더 세분화하면, 라우터 Worker는 정의된 각 버티컬 마이크로프론트엔드 Worker(예: 마케팅, 문서, 대시보드)에서 각각 Cloudflare Workers라고 가정했습니다.

이것이 중요한 이유는 무엇일까요? 이것이 바로 이러한 수직 분할 영역을 '연결하는' 메커니즘입니다. 요청 라우팅이 트래픽 분할을 처리하는 방법은 다음 섹션에서 자세히 알아보겠습니다. 하지만 이러한 각각의 마이크로프론트엔드를 정의하려면 라우터 Worker의 wrangler 정의를 업데이트하여 호출이 허용된 프런트엔드를 알 수 있도록 해야 합니다.

{
  "$schema": "./node_modules/wrangler/config-schema.json",
  "name": "router",
  "main": "./src/router.js",
  "services": [
    {
      "binding": "HOME",
      "service": "worker_marketing"
    },
    {
      "binding": "DOCS",
      "service": "worker_docs"
    },
    {
      "binding": "DASH",
      "service": "worker_dash"
    },
  ]
}

위의 샘플 정의는 라우터 Worker에 정의되어 있으며, 요청을 세 개의 개별 추가 Workers(마케팅, 문서, 대시)로 만들 수 있음을 알려줍니다. 권한을 부여하는 것도 그렇게 간단하겠지만, 네트워크 응답을 라우팅하고 HTML을 재작성하는 좀 더 복잡한 로직을 알아보겠습니다.

필요할 때 호출할 수 있는 다양한 Workers에 대한 지식이 있으므로, 이제 네트워크 요청을 언제 어디로 보낼지 알 수 있는 로직을 마련해야 합니다. 라우터 Worker가 베니티 도메인에 할당되어 있으므로 모든 수신 요청이 네트워크 에지에서 먼저 도달합니다. 그런 다음 어떤 Worker가 요청을 처리해야 하는지 결정하고 결과 응답을 관리합니다. 

첫 번째 단계는 URL 경로를 연결된 Workers에 매핑하는 것입니다. 특정 요청 URL이 수신되면 우리는 이 요청을 어디로 전달해야 하는지 알아야 합니다. 저희는 규칙을 정의하여 이를 수행합니다. 와일드카드 라우팅, 동적 경로, 매개변수 제약은 지원하지만, 요점을 더 명확하게 보여주는 기본 사항(문자 그대로의 경로 접두사)에 계속 집중하려고 합니다. 

 이 예에는 세 개의 마이크로프론트엔드가 있습니다.

/      = Marketing
/docs  = Documentation
/dash  = Dashboard

위의 각 경로를 실제 Worker에 매핑해야 합니다(위 섹션의 서비스에 대한 Wrangler 정의 참조). 라우터 Worker의 경우 다음 데이터로 추가 변수를 정의하여 어떤 경로가 어떤 서비스 바인딩에 매핑되어야 하는지 알 수 있습니다. 이제 요청이 들어오면 사용자를 어디로 라우팅해야 할지 알 수 있습니다! ROUTES 이름과 다음 내용으로 Wrangler 변수를 정의합니다.

{
  "routes":[
    {"binding": "HOME", "path": "/"},
    {"binding": "DOCS", "path": "/docs"},
    {"binding": "DASH", "path": "/dash"}
  ]
}

사용자가 웹사이트 경로 /docs/installation를 방문한다고 가정해 보겠습니다. 내부에서는 요청이 어떤 URL 경로가 어떤 개별 Workers에 매핑되는지 이해하는 라우터 Worker에 먼저 도달합니다. 이는 /docs 경로 접두사가 DOCS 서비스 바인딩에 매핑되어 있음을 이해하며, 랭글러 파일을 참조하면 worker_docs 프로젝트를 가리킵니다. 라우터 Worker는 /docs 가 수직 마이크로프론트엔드 경로로 정의되었다는 것을 알고 경로에서 /docs 접두사를 제거하고 요청을 worker_docs Worker로 전달하여 요청을 처리한 다음 최종적으로 응답을 반환합니다.

하지만 /docs 경로는 누락되는 이유는 무엇일까요? 이는 라우터 Worker를 통해 Worker에 액세스할 때 URL을 정리하여 라우터 Worker 외부에서 호출된 것처럼 요청을 처리할 수 있도록 하기 위해 구현된 세부 사항을 선택했던 것입니다. 다른 Cloudflare Worker와 마찬가지로, 당사의 worker_docs 서비스에도 액세스할 수 있는 자체 개별 URL이 있을 수 있습니다. 우리는 해당 서비스 URL이 계속 독립적으로 작동하기를 원한다고 결정했습니다. Cloudflare의 새로운 Router Worker에 연결되면 접두사 제거를 자동으로 처리하므로 자체적으로 정의된 URL이나 당사의 Router Worker를 통해 서비스에 액세스할 수 있었습니다… 어느 위치든 중요하지 않습니다.

URL 경로에 따라 다양한 프런트엔드 서비스를 분할(예: /docs 또는 /dash)를 사용하면 요청을 쉽게 전달할 수 있지만, 응답에 경로 구성 요소를 통해 역방향 프록시 설정이라는 사실을 모르는 HTML이 포함된 경우 문제가 발생합니다. 

Cloudflare 문서 웹 사이트의 응답에 이미지 태그가 있다고 가정해 보겠습니다. 사용자가 https://website.com/docs/에서 이 페이지를 방문하고 있었다면 /docs 경로가 라우터 Worker에 의해서만 인위적으로 정의되었기 때문에 logo.png 파일을 로드하지 못할 가능성이 큽니다.

라우터 Worker를 통해 서비스에 액세스할 때만 반환된 브라우저 응답이 유효한 자산을 참조하도록 절대 경로에 대한 HTML 재작성을 수행해야 합니다. 실제로 요청이 라우터 Worker를 통과할 때 올바른 서비스 바인딩으로 요청이 전달되고, 여기에서 응답을 받게 됩니다. 이를 클라이언트에 다시 전달하기 전에 문서 개체 모델을 다시 작성할 수 있으므로 절대 경로가 표시되는 곳에 계속 진행하여 프록시된 경로를 앞에 추가합니다. 이전에는 HTML이 <img src="./logo.png" /> 가 있는 이미지 태그를 반환했던 곳에서 이제 클라이언트 브라우저로 반환되기 전에 <img src="./docs/logo.png" />로 수정합니다.

잠시 CSS 보기 전환과 문서 프리로드의 마법으로 돌아가 보겠습니다. 물론 해당 코드를 프로젝트에 수동으로 배치하고 작동시킬 수 있지만, 이 라우터 Worker는 자동으로 HTMLRewriter도 사용하여 해당 로직을 처리합니다. 

라우터 Worker ROUTES 변수에서, 루트 수준에서 smoothTransitions 를 true 로 설정하면, CSS 전환 보기 코드가 자동으로 추가됩니다. 또한 라우팅 내의 프리로드 키를 true로 설정하면 해당 라우팅에 대한 스크립트 코드 추측 규칙도 자동으로 추가됩니다. 

다음은 두 가지 모두의 예입니다.

{
  "smoothTransitions":true, 
  "routes":[
    {"binding": "APP1", "path": "/app1", "preload": true},
    {"binding": "APP2", "path": "/app2", "preload": true}
  ]
}

버티컬 마이크로프론트엔드 템플릿으로 지금 바로 구축을 시작할 수 있습니다.

Cloudflare 대시보드를 방문하거나 여기에서 딥링크 를 방문하거나 “Workers & Pages”로 이동하여 “애플리케이션 생성” 버튼을 클릭하여 시작하세요. 여기에서 “템플릿 선택”과 “마이크로프론트엔드 생성”을 클릭하면 설정 구성을 시작할 수 있습니다.

기존 Workers를 매핑하고 보기 전환을 활성화하는 방법을 알아보려면 문서 를 확인하세요. 여러 팀으로 구성된 복잡한 응용 프로그램이 여러분이 에지에 어떤 것을 구축하게 될지 정말 기대됩니다!