У нас есть несколько веб-приложений (angular 7+), которые мы хотим представить в рамках одной одностраничной заявки. Мы ищем архитектуру / структуру микро-интерфейса. На наш взгляд, это наши варианты реализации:
Использование фреймворка с открытым исходным кодом для одного спа: https://github.com/CanopyTax/single-spa Использование Iframes (дружественных Iframes) хост-приложения (оболочки) и загрузка каждогоприложение в соответствии с текущим URL. Использование веб-компонентов. Другой? Текущее состояние - это монолитное приложение FE, которое использует другое дочернее приложение как внутренние приложения через IFRAME (этот подход не масштабируется для нас, потому что хост-приложение строит все продукты вместе, и на самом деле ничего не разделено.)
Наши требования - это обычные требования для микро-интерфейса: Независимая разработка - каждая команда может работать над собственным репо и создавать свои продукты независимо от других продуктов.
Независимое развертывание - Каждое приложение можно обновить впроизводство без простоев и без вмешательства в другие приложения.
Общие компоненты - Мы используем Angular7 в наших приложениях, и у нас есть собственная сторонняя библиотека (общие компоненты и логика), которую мы уже написалиэто должно быть общим для всех продуктов для одинакового внешнего вида.
Мы хотели бы иметь возможность обновлять структуру каждого приложения (Angular, RXjs, Typescript и т. д. и др.). o для нашей собственной библиотеки компонентов), не заботясь о других приложениях.
Мы пытались использовать фреймворк для одного спа, но у нас есть некоторые проблемы, и в настоящее время мы думаем, что это правильный подход длянам, или мы должны попробовать другой подход.
Проблемы, которые мы имеем при использовании single-spa :
- Загрузка активов является проблематичной. (У нас должны быть файлы ресурсов в корневой папке хост-приложения, и мы страдаем от конфликтов ресурсов при переключении на другое приложение.)
- Мы до сих пор не знаем, как обрабатывать глобальные стили для всех приложений (Мы используем sass для стилей, и он должен соответствовать местным стилям для каждого приложения)
- Обновление угловой структуры (или всех других структур) невозможно для одного приложения, это все или ничего (так как у нас есть однаэкземпляр угловой).
- Мы должны реализовать другой пакет для разработки другой стороны хостинг-приложения (оболочки).
Когда мы думаем о Iframe (используя дружественныйРешение iframe) мы визуализируем полное разделение между всеми дочерними приложениями. Общение происходит только через почтовое сообщение. При таком подходе мы можем отделить от этого код пользовательского интерфейса и заставить APIS работать только через IFRAME
Существуют ли подводные камни для использования Iframes?
Более общей реализацией было создание веб-компонент с пользовательским элементом, но нам нужно поддерживать IE11 и Edge, которые не поддерживают встроенную инкапсуляцию, поэтому нам необходимо протестировать наше приложение на каждом сайте, где оно используется, чтобы убедиться, что оно не нарушает наши стилиКроме того, я не знаю, может ли веб-компонент управлять дочерними маршрутами или нет.
Идеальное решение должно позволить нашему приложению PARENT запрашивать дочерние приложения через маршруты без какой-либо связи между ними. с точки зрения ресурсов и активов и должны быть независимыми в этих условиях. Еще одна важная функция, которая нам нужна, - эти приложения должны иметь механизм уведомления.
Заранее спасибо.