Консультация по микро-интерфейсной архитектуре

У нас есть несколько веб-приложений, которые мы хотим представить в одном приложении с одной страницей. Мы ищем архитектуру/инфраструктуру с микро-интерфейсом. Как мы видим, это наши варианты реализации:

Использование рамки с открытым исходным кодом с одним спамом: https://github.com/CanopyTax/single-spa
Использование iframes (дружественных iframes) хостинг-приложения (оболочки) и загрузка каждого приложения в соответствии с текущим URL-адресом.
Написание собственной структуры Javascript
Другой?

Текущее состояние - монолитное приложение FE, которое потребляет другое дочернее приложение как внутренние сторонние пакеты. Этот подход не масштабируется для нас, потому что приложение-хостинг создает все продукты вместе, и ничто действительно не разделяется.

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

Независимое развертывание. Каждое приложение может быть модернизировано в производстве без простоя и без вмешательства других приложений.
Общие компоненты. Мы используем Angular4 в наших приложениях, и у нас есть собственная сторонняя библиотека (разделяемые компоненты и логика), которые мы уже писали, которые должны быть разделены между всеми продуктами для аналогичного внешнего вида.
Мы хотели бы иметь возможность обновлять каждую инфраструктуру приложения (Angular, RXjs, TypScript и т.д., А также для нашей собственной библиотеки компонентов), не заботясь о других приложениях.

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

Проблемы, которые мы используем в одном спа-салоне, следующие: 1. Загрузка активов проблематична. (У нас должны быть файлы с ресурсами в корневой папке хостинг-приложения, и мы сталкиваемся с конфликтами активов при переключении на другое приложение). 2. Мы все еще не знаем, как справляться с глобальным стилем для всех приложений (мы используем sass для стилизации, и его нужно выполнять вместе с локальными стилями для каждого приложения). 3. Углеродная структура (или все другие рамки) невозможна для одного приложения это все или ничего (поскольку у нас есть один экземпляр углового). 4. Мы должны внедрить другую комплектацию для разработки другой стороны приложения-хостинга (оболочки).

Когда мы думаем о решении Iframe (с использованием дружественного iframe), мы визуализируем полное разделение между всем дочерним приложением и склонны полагать, что это более подходящий подход для нас.

Есть ли подводные камни для использования iframes?

Спасибо, Даниэль

Ответ 1

Я хотел бы добавить свой 2 ¢ к теме возможных архитектурных решений для микроконтроллеров frontend:

OpenComponents, используемые OpenTable - https://github.com/opentable/oc
Мозаика от Zalando - https://www.mosaic9.org/

Надеюсь, вы сочтете их полезными.

Ответ 2

Поскольку ваш вопрос несколько широк, я буду рассматривать ваши запросы об использовании iframes, так как консультирование по архитектуре бессмысленно, не зная обстоятельств (целевая группа?, мобильная?), Каковы KPIs (производительность, начальная загрузка, затраты на разработку, повторное использование,...)

Iframes хороши для "полной" изоляции (код + стиль), ни один другой подход не даст вам этого, однако из-за этого у них есть много недостатков:

обмен данными между iframe требует оркестровки во внешних и внутренних SPA, что предполагает настройку дополнительных мер безопасности (поскольку каждый SPA-центр подвергается воздействию)
стилизация ваших внутренних SPA-ов внешним, будет работать только тогда, когда они находятся в одном домене и нуждается в дополнительном JS-коде
совместное использование файлов cookie работает только в том случае, если внутренние SPA-объекты находятся в том же домене, что и внешние SPA
каждый из них должен загружать все по отдельности; повторное использование активов, библиотек и т.д. очень сложно и предполагает вмешательство с инструментами каждого SPA.

Обычно, если у вас есть все, что под вашим контролем, с использованием реального подхода к микро-интерфейсу, это лучшее решение, чем iframes.

Ответ 3

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

Он фактически охватывает почти все ваши требования.

Независимые развертывания
Независимый исходный код
Независимые технологии

И о решении iframe может быть сложно управлять такими вещами, как CORS и связь с другими iframe.

Но решение micro frontends еще не совершенно. Есть много сложностей, когда вы действительно погружаетесь глубоко в нее.

Некоторые активы будут пытаться объявить одну и ту же переменную в глобальной области действия, и иногда они будут иметь разные версии, которые вызовут ошибку. Таким образом, команды не будут полностью независимы друг от друга.

Ведение журнала и мониторинг становятся чрезвычайно трудными. Такие инструменты, как New Relic, помогут вам, но этого будет недостаточно. Вы должны внедрять специальные средства мониторинга и создания отчетов об ошибках.

Важное значение имеет поддержание приложений, закрепленных за док-станцией, и автоматическое масштабирование. С этой архитектурой, если у вас 4 шлюза и магазин, это может быть сложно.

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

Производительность - самое главное. Вы не хотите загружать реакции или другие библиотеки более одного раза, потому что их используют несколько команд. Вы должны реализовать DllPluginn для удаления дублированных кодов. И это сделает все сложнее.

И есть много других проблем, которые я не мог вспомнить. Если у вас не более 50 разработчиков, работающих с одним и тем же проектом витрины, микро-интерфейсы - это решение о переполнении.

Ответ 4

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

Мое предложение состояло в том, чтобы ждать угловых элементов, поскольку структура не предназначена для использования в стиле micro frontend.

Ответ 5

Вы можете выставлять веб-компоненты из каждого вашего приложения и сводить/использовать их в своем главном SPA. Веб-компоненты получают поддержку всех браузеров, а также все ведущие разработки SAP (например, угловые, угловые, реагирующие, vue) поддерживают веб-компонент. Таким образом, вы не привязаны к какой-либо отдельной инфраструктуре SPA и можете перенастраивать компоненты в любом месте.

Ответ 6

Вы можете посмотреть на ShadowDom v1.1 как альтернативу Iframe. Я недавно работаю и внедряю банковское приложение, используя эту технику, чтобы изолировать стилирование родительского приложения (которое представляет собой приложение с сохранением состояния с шаблоном на стороне сервера jsp), но это только дает вам изоляцию стиля.

Лучше иметь разную кодовую базу для каждого дочернего приложения. Таким образом, вы можете разрабатывать их независимо, переходить на другую версию Angular и развертывать отдельно. Общий компонент и проприетарная сторонняя библиотека могут быть опубликованы как node_module, где вы можете импортировать их в каждое дочернее приложение. (Я полагаю, что вы должны иметь частную/внутреннюю настройку хранилища артефактов)

Взаимодействие между дочерним приложением может быть выполнено с помощью localStorate/sessionStorage. Вы можете далее обернуть их как общий сервис и снова опубликовать как зависимость node_module.

** Настроить

yourcompany.com → родительское приложение

yourcompany.com/app1.html → дочернее приложение 1 - загрузочное приложение с вложенными js файлами и css yourcompany.com/app2.php → дочернее приложение 2 - загрузочное приложение с вложенными js файлами & css yourcompany.com/app3. jsp → дочернее приложение 3 - загрузочное приложение с js файлами в комплекте и css

** или используя поддомен

yourcompany.com → родительское приложение

app.yourcompany.com → дочернее приложение 1

blog.yourcompany.com → дочернее приложение 2

home.yourcompany.com → детское приложение 3

Ответ 7

Я считаю, что мой ответ на эту тему будет находчивым. Однако для уточнения

Учитывая, что основное приложение развернуто на сайте www.example.com, каждое дочернее приложение должно унаследовать глобальный стиль путем форсирования импорта, т.е.
```
@import url('https://www.example.com/path/to/global/style.css');
```
С помощью веб-компонентов стили отдельных подпрограмм не могут передаваться. Аналогично, наследование стиля от базового приложения должно быть принудительным, как показано выше.
Поскольку каждое вложенное приложение может быть создано независимо, оно делает его независимым от языка. Одно приложение может использовать Vue, а другое - Polymer.
Использование веб-компонентов аналогично использованию фреймов, за исключением того, что они легче и предназначены для подключения.

Надеюсь, поможет