← Cloudflare Workers / workers / framework-guides / web-apps

Микрофронтенды

Микрофронтенды позволяют разделить единое приложение на более мелкие независимо развёртываемые модули, которые вместе отображаются как одно целостное приложение. Разные команды, использующие разные технологии, могут разрабатывать, тестировать и развёртывать каждый микрофронтенд отдельно.

Используйте микрофронтенды, если вы хотите:

• Позволяет нескольким командам развертывать код независимо, без согласования релизов
• Постепенная миграция с монолита на распределённую архитектуру
• Создавайте мультифреймворковые приложения (например, Astro, Remix и Next.js в одном приложении)

Создайте проект микрофронтенда:

Этот шаблон автоматически создает router worker с готовой логикой маршрутизации и позволяет настроить Service bindings к Workers, которые вы уже развернули в своём аккаунте Cloudflare. Код или этот шаблон доступен на GitHub по адресу cloudflare/templates ↗.

graph LR
    A[Browser Request] --> B[Router Worker]
    B -->|Service Binding| C[Microfrontend A]
    B -->|Service Binding| D[Microfrontend B]
    B -->|Service Binding| E[Microfrontend C]

Worker-маршрутизатор:

1. Анализирует путь входящего запроса
2. Сопоставляет его с настроенными маршрутами
3. Перенаправляет запрос в соответствующий микрофронтенд через service binding
4. Переписывает HTML, CSS и заголовки, чтобы обеспечить корректную загрузку ресурсов
5. Возвращает ответ браузеру

Каждый микрофронтенд может быть:

• Полноценное приложение на фреймворке (Next.js, SvelteKit, Astro и т. д.)
• Статический сайт с Workers Static Assets
• Создано с использованием разных фреймворков и технологий

Worker-маршрутизатор использует ROUTES переменная окружения чтобы определить, какой микрофронтенд обрабатывает каждый путь. Маршруты сопоставляются по специфичности, при этом более длинные пути имеют приоритет.

Пример ROUTES конфигурация:

{
	"routes": [
		{ "path": "/app-a", "binding": "MICROFRONTEND_A", "preload": true },
		{ "path": "/app-b", "binding": "MICROFRONTEND_B", "preload": true },
		{ "path": "/", "binding": "MICROFRONTEND_HOME" }
	],
	"smoothTransitions": true
}

Для каждого маршрута требуется:

• path: Путь монтирования для микрофронтенда (должен отличаться от других маршрутов)
• binding: Имя привязки службы в вашем конфигурационный файл Wrangler
• preload (необязательно): следует ли предварительно загружать этот микрофронтенд для более быстрой навигации

Когда поступает запрос на /app-a/dashboard, роутер:

1. Сопоставляет его с /app-a маршрут
2. Перенаправляет запрос в MICROFRONTEND_A
3. Удаляет /app-a префикс, поэтому микрофронтенд получает /dashboard

Маршрутизатор включает логику сопоставления путей, которая поддерживает:

// Static paths
{ "path": "/dashboard" }

// Dynamic parameters
{ "path": "/users/:id" }

// Wildcard matching (zero or more segments)
{ "path": "/docs/:path*" }

// Required segments (one or more segments)
{ "path": "/api/:path+" }

Worker-маршрутизатор использует HTMLRewriter чтобы автоматически переписывать атрибуты HTML, добавляя к ним префикс пути монтирования, благодаря чему ресурсы загружаются из нужного места.

Когда микрофронтенд, смонтированный по адресу /app-a возвращает HTML:

<link rel="stylesheet" href="/assets/styles.css" />
<script src="/assets/app.js"></script>
<img src="/static/logo.png" />

Маршрутизатор переписывает его в:

<link rel="stylesheet" href="/app-a/assets/styles.css" />
<script src="/app-a/assets/app.js"></script>
<img src="/app-a/static/logo.png" />

Переписчик обрабатывает следующие атрибуты во всех элементах HTML:

• href, src, poster, action, srcset
• data-* атрибуты, такие как data-src, data-href, data-background
• Атрибуты, специфичные для фреймворка, такие как astro-component-url

Маршрутизатор переписывает только пути, начинающиеся с настроенных префиксов ресурсов, чтобы не нарушать работу внешних URL:

// Default asset prefixes
const DEFAULT_ASSET_PREFIXES = [
	"/assets/",
	"/static/",
	"/build/",
	"/_astro/",
	"/fonts/",
];

Большинство фреймворков работают со стандартными префиксами. Для фреймворков с другими путями сборки (например, Next.js, который использует /_next/), можно настроить пользовательские префиксы с помощью ASSET_PREFIXES переменная окружения:

["/_next/", "/public/"]

Маршрутизатор также переписывает файлы CSS, чтобы обеспечить url() ссылки работали корректно. Когда микрофронтенд, смонтированный по адресу /app-a возвращает CSS:

.hero {
	background: url(/assets/hero.jpg);
}

.icon {
	background: url("/static/icon.svg");
}

Маршрутизатор переписывает его в:

.hero {
	background: url(/app-a/assets/hero.jpg);
}

.icon {
	background: url("/app-a/static/icon.svg");
}

Маршрутизатор также обрабатывает:

• Заголовки перенаправления: Переписывает Location заголовки, чтобы включить путь монтирования
• Пути cookie: Обновляет Set-Cookie заголовки, чтобы ограничить область действия cookie путём монтирования

Когда preload: true задан для статического маршрута монтирования, маршрутизатор автоматически предзагружает эти маршруты для более быстрой навигации. Маршрутизатор использует оптимизация для конкретного браузера чтобы обеспечить наилучшую производительность для каждого браузера:

Для браузеров на основе Chromium маршрутизатор использует Speculation Rules API - современный механизм предзагрузки, встроенный в браузер:

• Внедряет <script type="speculationrules"> в <head> элемент
• Браузер сам управляет предзагрузкой с оптимальным распределением приоритетов
• Учитывает настройки пользователя (режим экономии заряда батареи, режим экономии трафика)
• Использует кеш в памяти для каждого документа для более быстрого доступа
• Не блокируется заголовками Cache-Control
• Более эффективно, чем получение данных средствами JavaScript

Пример добавленных speculation rules:

{
	"prefetch": [
		{
			"urls": ["/app1", "/app2", "/dashboard"]
		}
	]
}

Плавные переходы между страницами микрофронтендов можно включить с помощью View Transitions API ↗.

Чтобы включить плавные переходы, задайте "smoothTransitions": true в вашем ROUTES конфигурация:

{
	"routes": [
		{ "path": "/app-a", "binding": "MICROFRONTEND_A" },
		{ "path": "/app-b", "binding": "MICROFRONTEND_B" }
	],
	"smoothTransitions": true
}

Маршрутизатор автоматически добавляет CSS в ответы HTML:

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

Эта функция работает только в браузерах, поддерживающих View Transitions API. В браузерах без поддержки переход между страницами будет обычным, без анимации.

Чтобы добавить новый микрофронтенд в приложение после первоначальной настройки:

1. Создание и развертывание нового microfrontend worker

   Разверните ваш новый микрофронтенд как отдельный Worker. Это может быть приложение на основе фреймворка (Next.js, Astro и т. д.) либо статический сайт с Workers Static Assets.

2. Добавьте привязка к сервису в конфигурационном файле Wrangler вашего маршрутизатора

   {
     "$schema": "./node_modules/wrangler/config-schema.json",
     "services": [
       {
         "binding": "MICROFRONTEND_C",
         "service": "my-new-microfrontend"
       }
     ]
   }

   [[services]]
   binding = "MICROFRONTEND_C"
   service = "my-new-microfrontend"

3. Обновите ROUTES переменная окружения

   Добавьте новый маршрут в ROUTES конфигурация:

   {
   	"routes": [
   		{ "path": "/app-a", "binding": "MICROFRONTEND_A", "preload": true },
   		{ "path": "/app-b", "binding": "MICROFRONTEND_B", "preload": true },
   		{ "path": "/app-c", "binding": "MICROFRONTEND_C", "preload": true },
   		{ "path": "/", "binding": "MICROFRONTEND_HOME" }
   	]
   }

4. Повторно разверните router worker

   npx wrangler deploy

Ваш новый микрофронтенд теперь доступен по настроенному пути (например, /app-c).

Во время разработки вы можете протестировать архитектуру микрофронтендов локально, используя поддержку service binding в Wrangler. Запустите router Worker локально с помощью wrangler dev, а затем в отдельных терминалах запустите каждый из микрофронтендов.

Если вам нужно работать только с одним из микрофронтендов, остальные можно запускать удалённо с помощью удаленные привязки, без необходимости иметь доступ к исходному коду или запускать локальный сервер разработки.

Для каждого микрофронтенда, который должен выполняться удалённо при локальной разработке, настройте для него service binding с флагом remote:

{
"services": [
	{
	"binding": "<BINDING_NAME>",
	"service": "<WORKER_NAME>",
	"remote": true
	}
]
}

[[services]]
binding = "<BINDING_NAME>"
service = "<WORKER_NAME>"
remote = true

Каждый микрофронтенд можно развёртывать независимо, без повторного развёртывания маршрутизатора или других микрофронтендов. Это позволяет командам:

• Развертывание обновлений по собственному графику
• Откатывайте отдельные микрофронтенды, не затрагивая остальные
• Тестируйте и выпускайте функции независимо друг от друга

Когда вы развёртываете microfrontend worker, маршрутизатор автоматически направляет запросы к последней версии через service binding. Изменения в маршрутизаторе не требуются, если только вы не добавляете новые маршруты или не обновляете ROUTES конфигурации.

Чтобы развернуть в продакшен, вы можете использовать пользовательские домены для вашего Worker-маршрутизатора и настройте Workers Builds для непрерывного развёртывания из вашего Git-репозитория.