Совет по архитектуре микро-интерфейса для создания портала со службами уведомлений, встроенными в систему - PullRequest
0 голосов
/ 23 декабря 2019

У нас есть несколько веб-приложений (angular 7+), которые мы хотим представить в рамках одной одностраничной заявки. Мы ищем архитектуру / структуру микро-интерфейса. На наш взгляд, это наши варианты реализации:

Использование фреймворка с открытым исходным кодом для одного спа: https://github.com/CanopyTax/single-spa Использование Iframes (дружественных Iframes) хост-приложения (оболочки) и загрузка каждогоприложение в соответствии с текущим URL. Использование веб-компонентов. Другой? Текущее состояние - это монолитное приложение FE, которое использует другое дочернее приложение как внутренние приложения через IFRAME (этот подход не масштабируется для нас, потому что хост-приложение строит все продукты вместе, и на самом деле ничего не разделено.)

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

Независимое развертывание - Каждое приложение можно обновить впроизводство без простоев и без вмешательства в другие приложения.

Общие компоненты - Мы используем Angular7 в наших приложениях, и у нас есть собственная сторонняя библиотека (общие компоненты и логика), которую мы уже написалиэто должно быть общим для всех продуктов для одинакового внешнего вида.

Мы хотели бы иметь возможность обновлять структуру каждого приложения (Angular, RXjs, Typescript и т. д. и др.). o для нашей собственной библиотеки компонентов), не заботясь о других приложениях.

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

Проблемы, которые мы имеем при использовании single-spa :

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

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

Существуют ли подводные камни для использования Iframes?

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

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

Заранее спасибо.

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