PrepBro
← Назад к вопросам

Какие знаешь подходы встраивания одного Frontend приложения в другое?

2.0 Middle🔥 151 комментариев
#Soft Skills и рабочие процессы

Комментарии (1)

🐱
deepseek-v3.2PrepBro AI4 апр. 2026 г.(ред.)

Ответ сгенерирован нейросетью и может содержать ошибки

Подходы к встраиванию Frontend-приложений: от Iframe до Module Federation

В современных микрофронтенд-архитектурах и комплексных платформах часто возникает необходимость встраивания одного веб-приложения в другое. Рассмотрим основные подходы с их преимуществами и ограничениями.

Iframe — классическая изоляция

Наиболее простой и давно существующий способ, обеспечивающий полную изоляцию контекстов.

<iframe 
  src="https://подвложение.example.com"
  width="100%"
  height="500"
  frameborder="0"
  allow="camera; microphone"
></iframe>

Преимущества:

  • Полная изоляция CSS, JavaScript и DOM
  • Безопасность через sandbox-атрибуты
  • Легкость реализации
  • Возможность загрузки кросс-доменных приложений

Недостатки:

  • Ограниченная коммуникация между контекстами (только через postMessage)
  • Сложности с адаптивностью высоты
  • Отдельная загрузка всех ресурсов (нет шаринга зависимостей)
  • SEO-проблемы

Web Components — нативная инкапсуляция

Стандарт W3C, позволяющий создать переиспользуемые кастомные элементы.

// Определение компонента
class EmbeddedApp extends HTMLElement {
  connectedCallback() {
    this.innerHTML = `
      <div class="embedded-app">
        <h3>Встроенное приложение</h3>
      </div>
    `;
  }
}

customElements.define('embedded-app', EmbeddedApp);

Преимущества:

  • Нативная поддержка браузерами
  • Shadow DOM для изоляции стилей
  • Естественная интеграция с любым фреймворком
  • Стандартизированный API

Недостатки:

  • Ограниченная поддержка в старых браузерах
  • Сложности с маршрутизацией и состоянием
  • Более сложная коммуникация между компонентами

Микрофронтенды через Module Federation

Современный подход, популяризированный Webpack 5, позволяющий динамически загружать код из других сборок.

// Конфигурация host-приложения
// webpack.config.js (host)
const ModuleFederationPlugin = require('webpack/lib/container/ModuleFederationPlugin');

module.exports = {
  plugins: [
    new ModuleFederationPlugin({
      name: 'host',
      remotes: {
        remoteApp: 'remoteApp@https://cdn.example.com/remoteEntry.js'
      },
      shared: ['react', 'react-dom']
    })
  ]
};

// Использование в коде
const RemoteComponent = React.lazy(() => import('remoteApp/Component'));

Преимущества:

  • Разделение зависимостей (shared libraries)
  • Независимое развертывание микрофронтендов
  • Высокая производительность за счет загрузки только необходимого кода
  • Полноценная интеграция в единый DOM

Недостатки:

  • Сложность настройки
  • Требуется совместимость версий общих зависимостей
  • Потенциальные проблемы с версионированием

Компонентный подход через NPM-пакеты

Создание UI-компонентов или целых виджетов как npm-пакетов.

// package.json хост-приложения
{
  "dependencies": {
    "@company/embedded-widget": "^1.2.0"
  }
}

// Использование в хост-приложении
import { PaymentWidget } from '@company/embedded-widget';

function App() {
  return (
    <div>
      <h1>Основное приложение</h1>
      <PaymentWidget config={widgetConfig} />
    </div>
  );
}

Преимущества:

  • Полный контроль над версиями
  • Статический анализ и tree-shaking
  • Интеграция в инструментальную цепочку

Недостатки:

  • Требуется пересборка при изменении встроенного приложения
  • Менее динамичное обновление
  • Версионные конфликты

Рендеринг на сервере (SSR Includes)

Серверный подход, когда фрагменты собираются на стороне сервера.

// Express.js пример
app.get('/page', async (req, res) => {
  const mainContent = await renderMainApp();
  const embeddedContent = await fetchEmbeddedApp();
  
  res.send(`
    <!DOCTYPE html>
    <html>
      <body>
        ${mainContent}
        <div class="embedded-section">
          ${embeddedContent}
        </div>
      </body>
    </html>
  `);
});

Преимущества:

  • Единый начальный HTML
  • Лучший SEO
  • Согласованный рендеринг

Недостатки:

  • Сложность реализации
  • Зависимость от серверной инфраструктуры
  • Меньшая динамичность

Сравнение подходов для разных сценариев

КритерийIframeWeb ComponentsModule FederationNPM-пакеты
ИзоляцияВысокаяСредняяНизкаяНизкая
ПроизводительностьНизкаяВысокаяВысокаяВысокая
ГибкостьНизкаяСредняяВысокаяСредняя
Сложность внедренияНизкаяСредняяВысокаяСредняя
Независимость деплояВысокаяВысокаяВысокаяНизкая

Рекомендации по выбору

  1. Для максимальной изоляции и безопасности — используйте iframe с sandbox-атрибутами, особенно для сторонних виджетов (платежные системы, карты).

  2. Для современных микрофронтенд-архитектур — Module Federation оптимален, когда нужны независимое развертывание и общие зависимости.

  3. Для кросс-фреймворковой совместимости — Web Components подходят для систем, где используются разные технологии.

  4. Для тесной интеграции и общего стейт-менеджмента — NPM-пакеты с единой кодо-базой, но с рисками связанности.

  5. Для SEO-критичных проектов — SSR Includes обеспечивают лучшую индексацию встроенного контента.

Критические аспекты реализации

При любом подходе необходимо учитывать:

  • Коммуникацию между приложениями (события, callbacks, глобальное состояние)
  • Стилизацию и CSS-конфликты (CSS-in-JS, CSS Modules, Shadow DOM)
  • Маршрутизацию (синхронизация URL, навигационные события)
  • Производительность (ленивая загрузка, кэширование, разделение кода)
  • Мониторинг и отладку (единая система логов, трейсинг ошибок)

Современные платформы часто комбинируют несколько подходов: например, используют Module Federation для основных компонентов и iframe для полностью изолированных сторонних сервисов. Выбор зависит от требований к изоляции, производительности и сложности интеграции.