Вопрос проверяет понимание классических подходов к микрофронтендам до появления Module Federation, чтобы оценить знание эволюции архитектуры и компромиссов.
Микрофронтенды — это архитектурный стиль, при котором большое веб-приложение разбивается на независимые, автономные части, разрабатываемые разными командами. До появления таких инструментов, как Webpack Module Federation, интеграция этих частей была более сложной и часто создавала точки трения.
В этом подходе "контейнерное" приложение отвечает за маршрутизацию. В зависимости от URL, оно динамически загружает и монтирует JavaScript-бандл нужного микрофронта. Это можно сделать с помощью систематической загрузки скриптов.
// Упрощенный пример: контейнер загружает скрипт микрофронта
const loadMicroFrontend = (name, scriptUrl) => {
return new Promise((resolve, reject) => {
const script = document.createElement('script');
script.src = scriptUrl;
script.onload = () => {
// Предполагается, что скрипт экспортирует глобальную функцию для рендеринга
window[`render${name}`](`${name}-container`);
resolve();
};
script.onerror = reject;
document.head.appendChild(script);
});
};
// При переходе на маршрут '/app1'
loadMicroFrontend('App1', 'http://cdn.example.com/app1.bundle.js');Этот метод сохраняет независимость развертывания, но требует тщательного управления глобальным пространством имен, версиями библиотек (проблема duplicate dependencies) и сложной координацией загрузки.
Вывод: Классические подходы к микрофронтендам позволяют достичь организационной декомпозиции и независимости команд, но часто жертвуют технической эффективностью, производительностью или простотой интеграции. Они полезны в сценариях, где критически важна серверная сборка для SEO или где команды работают над полностью изолированными частями приложения с минимальным взаимодействием.