Вопрос проверяет понимание архитектурных подходов к построению фронтенд-приложений и умение выбирать подходящий подход в зависимости от контекста проекта.
Архитектура фронтенд-приложения определяет, как организован код, как команды работают над ним и как происходит его развёртывание. Два основных подхода — монолитный и микрофронтенды — предлагают разные компромиссы.
В монолитной архитектуре всё приложение (все страницы, компоненты, логика, стили) находится в одном репозитории, собирается одной сборкой и развёртывается как единое целое. Это классический подход, который десятилетиями использовался в веб-разработке.
Микрофронтенды — это архитектурный стиль, при котором большое приложение разбивается на независимые, автономные части (микрофронтенды), которые могут разрабатываться, собираться и развёртываться отдельными командами. Эти части затем интегрируются на уровне браузера или сервера.
Рассмотрим простой пример использования Module Federation в Webpack для загрузки удалённого микрофронтенда:
// Конфигурация хоста (host app)
// webpack.config.js
const ModuleFederationPlugin = require('webpack/lib/container/ModuleFederationPlugin');
module.exports = {
plugins: [
new ModuleFederationPlugin({
name: 'host',
remotes: {
mf_products: 'products@http://localhost:3001/remoteEntry.js',
},
shared: ['react', 'react-dom'], // Общие зависимости
}),
],
};
// Код в приложении-хосте для динамической загрузки
const ProductsApp = React.lazy(() => import('mf_products/ProductsPage'));
function App() {
return (
Главное приложение
);
}В этом примере приложение-хост динамически загружает микрофронтенд "products" с другого домена. Это позволяет команде "products" разрабатывать и развёртывать свою часть совершенно независимо.
Вывод: Монолитный фронтенд стоит выбирать для небольших проектов или стартапов, где важна скорость выхода на рынок и простота поддержки. Микрофронтенды становятся оправданными для крупных, долгоживущих проектов с несколькими автономными командами, где критически важны независимость разработки и частота обновлений.