Три реализации, которые вы должны знать о микрофронтендах

Архитектура внешний интерфейс
Три реализации, которые вы должны знать о микрофронтендах

Истоки микрофронтендов

Концепция микро-фронтендов была впервые предложена Thoughtworks в 2016 году. Его основная идея состоит в том, чтобы изучить концепцию серверной микросервисной архитектуры и разделить одно огромное клиентское приложение на несколько простых и независимых внешних проектов. Каждый интерфейсный проект может быть независимо разработан, протестирован и развернут. Наконец, приложение-контейнер будет объединять разделенные проекты микроинтерфейса в единое целое для предоставления услуг пользователям.

微前端架构图

Преимущества архитектуры микро-фронтенда также очевидны:

  • Уменьшить связанность кода
  • Микрофронтенды можно развертывать независимо
  • Команды могут быть разделены по вертикали в соответствии с бизнесом, чтобы быть более эффективными

общая реализация

Концепция микро-интерфейса была очень популярна в последние год или два. Но следует отметить, что микрофронтенды — это не новая технология, а новый способ архитектуры. Разработчики сообщества в полной мере проявили свою изобретательность и предложили множество идей для реализации.

iframe

对于前端同学来讲，最容易想到的就是 iframe 了。iframe 天然具备微前端的基因。我们只需将单体的前端应用，按照业务模块进行拆分，分别部署。最后通过 iframe 进行动态加载即可。 Простая реализация выглядит следующим образом:

<html>
  <head>
    <title>微前端-ifame</title>
  </head>
  <body>
    <h1>我是容器</h1>
    <iframe id="mfeLoader"></iframe>
    <script type="text/javascript">
      const routes = {
        '/': 'https://app.com/index.html',
        '/app1': 'https://app1.com/index.html',
        '/app2': 'https://app2.com/index.html',
      };

      const iframe = document.querySelector('#mfeLoader');
      iframe.src = routes[window.location.pathname];
    </script>
  </body>
</html>

преимущество

  • Простота реализации
  • естественная изоляция

недостаток

  • Главная страница и iframe имеют максимально допустимое количество HTTP-ссылок.
  • iframe блокирует загрузку главной страницы.
  • Кнопка возврата в браузере не работает

Комбинация шаблонов на стороне сервера

Front-end программисты с чувством возраста должны быть знакомы с этим методом. Обычная реализация заключается в том, что сервер динамически отображает файл шаблона определенной страницы в соответствии с маршрутом. Схема архитектуры выглядит следующим образом:

服务端模板组合

Код шаблона контейнера выглядит следующим образом:

<html lang="en" dir="ltr">
  <head>
    <meta charset="utf-8">
    <title>微前端-服务端模板</title>
  </head>
  <body>
    <h1>容器应用</h1>
    <!--# include file="$PAGE.html" -->
  </body>
</html>

Динамически задайте загрузку шаблона на основе URL-адреса через сервер Nginx:

server {
    listen 8080;
    server_name localhost;

    root /usr/share/nginx/html;
    index index.html;
    ssi on;

    rewrite ^/$ http://localhost:8080/app redirect;

    location /app {
      set $PAGE 'app';
    }
    location /app1 {
      set $PAGE 'app1';
    }
    location /app2 {
      set $PAGE 'app2';
    }

    error_page 404 /index.html;
}

преимущество

  • Простота реализации
  • Независимость от стека технологий

недостаток

  • Требуется дополнительная настройка Nginx
  • Неполное разделение переднего и заднего концов

Фреймворк микро-интерфейса single-spa

Для фронтенд-программистов, всегда считающих своим девизом «то, что нельзя сделать без js», невозможно не строить колеса, и знаменитый single-spa был создан таким образом.

single-spa

С single-spa разработчики могут использовать разные технологические стеки для разных субприложений, например, субприложение A разработано с использованием vue, а субприложение B разработано с использованием реакции, без каких-либо исторических долгов.

Принцип реализации single-spa не сложен, с точки зрения архитектуры его можно разделить на две части: подприложение и приложение-контейнер.

Разница между подприложениями и традиционными одностраничными приложениями заключается в том, что

  • Не требуется файл ввода HTML,
  • Модуль, экспортируемый файлом ввода js, должен включать три метода: начальную загрузку, монтирование и размонтирование.

Приложение-контейнер в основном отвечает за регистрацию приложения, активацию и подключение дочернего приложения, когда URL-адрес попадает на маршрут дочернего приложения, или удаление и удаление подприложения со страницы, когда подприложение не активировано. Существует два основных метода:

  • registerApplicationЗарегистрируйтесь и загрузите дополнительные приложения
  • startЗапустите активное дочернее приложение.

Вот простой пример одного спа:

Код приложения контейнера

<html>
<body>
    <script src="single-spa-config.js"></script>
</body>
</html>

single-spa-config.jsкод показывает, как показано ниже:

import * as singleSpa from 'single-spa';
const appName = 'app1';
const app1Url = 'http://app1.com/app1.js'

singleSpa.registerApplication('app1',() => loadJS(app1Url), location => location.pathname.startsWith('/app1'))

singleSpa.start();

Метод loadJS — это псевдокод, который загружает app1.js. Разработчики должны реализовать его самостоятельно или использовать для этого systemJS.

Код дополнительного приложения:

//app1.js
let domEl;
export function bootstrap(props) {
    return Promise
        .resolve()
        .then(() => {
            domEl = document.createElement('div');
            domEl.id = 'app1';
            document.body.appendChild(domEl);
        });
}
export function mount(props) {
    return Promise
        .resolve()
        .then(() => {
            domEl.textContent = 'App 1 is mounted!'
        });
}
export function unmount(props) {
    return Promise
        .resolve()
        .then(() => {
            domEl.textContent = '';
        })
}

преимущество

  • Чистое внешнее решение
  • Может использовать несколько технологических стеков
  • Идеальная экология

недостаток

  • Высокая стоимость запуска
  • Существующие приложения нуждаются в доработке
  • Совместная отладка между приложениями усложняется

Применимая сцена

Выше были представлены три общие микроинтерфейсные архитектуры. Одноклассники фронтенда, которые от природы любят все новое, давно хотели попробовать. Итак, вот в чем проблема. Какие сценарии подходят для архитектуры микроинтерфейса? Какую реализацию микро-фронтенда использовать? Мой вывод прост:

  1. Сложные монолитные приложения с относительно независимыми бизнес-модулями
  2. Всесторонне учитывать технические возможности команды и текущую бизнес-ситуацию, чтобы выбрать подходящий метод.

Суммировать

Выше описаны три распространенные реализации микроинтерфейса:

  • Использовать композицию iframe
  • Комбинация рендеринга шаблонов на стороне сервера
  • Фреймворк микро-интерфейса single-spa

Далее мы продолжим рассказывать о применении микро-интерфейса в проектах, анализе принципа реализации микро-интерфейса, фреймворка single-spa и других сериях микро-интерфейса, так что следите за обновлениями. Вы также можете добавить меня в WeChat ljh5187, чтобы общаться и обсуждать вместе.

Подписывайтесь на нас

Категории