В настоящее время мы сталкиваемся с некоторыми сложными архитектурными вопросами об интеграции нескольких веб-компонентов с отдельными серверными службами в составном веб-интерфейсе пользователя в одно гладкое веб-приложение.
Существуют некоторые ограничения (подлежащие обсуждению)) проектные решения:
- MicroService должен обслуживать свой собственный веб-интерфейс (WebComponent), мы хотели бы использовать импорт HTML, чтобы разрешить включение такого веб-компонента в составной пользовательский интерфейс
- Веб-компонент веб-компонентанеобходимо иметь возможность получать живые обновления / события из своего бэкэнда. MicroService
- Страница (сумма веб-компонентов, используемых в составном интерфейсе пользователя) должна использовать только одно соединение / постоянно занятый порт для связи с бэкэндом
Я сделал набросок, представляющий наши абстрактные / нетехнические требования для дальнейшего обсуждения: 
Насколько я понимаю, проблему можно перефразировать следующим образом:Должны ли мы
а) сосредоточить общение на поступлении
* 102?3 * b) Распределить связь при выходе
из одного транспортного пути на обоих концах.
Эти две задачи необходимо решить с обеих сторон транспортного пути, например.бэкэнд и внешний интерфейс.
Что касается внутреннего интерфейса , я очень надеюсь, что принятие шаблона BFF , описанного не только Сэмом Ньюманом , может удовлетворить наши потребности.Правая половина (внутренняя сторона) вышеприведенного эскиза может тогда выглядеть примерно так: 
Транспортный путь лучше всего обслуживать с использованием стандартизированных веб-технологийнапример https и websocket (wss) для наиболее необходимой двусторонней связи.Я стремлюсь узнать об альтернативах с эквивалентным высоким уровнем внедрения в секторе веб-технологий.
Для внешнего интерфейса в настоящее время нам не хватает идей и знаний о ранее описанных шаблонах или структурах.
Хитрость заключается в том, что для использования ОДНОГО центрального канала связи необходимо найти несколько практически независимых веб-компонентов.Если внешний интерфейс будет реализован, например, путем реализации одного (большого) приложения Angular, мы реализуем и внедряем «BackendConnectorService» (имя, которое будет обсуждаться) и внедряем его в наши различные компоненты.
Но так как мы будемКак и в случае использования разделенных веб-компонентов, такого фонового слоя для совместной бизнес-логики и внедрения зависимостей не существует.Должны ли мы написать проприетарную JS-библиотеку, которая будет загружена в контекст окна, если она еще не присутствует в каждом из наших компонентов, и будет использоваться (условно) для связи с бэкэндом?
Это будетпримерно интегрировать в скетч, как показано ниже: 
Неужели мы думаем / проектируем наше приложение неправильно?
Я благодарен за каждую разумную идею или подсказку дляпроверенный шаблон / фреймворк.
Также ваш взгляд на проблему и архитектуру может быть полезен для обсуждения проблем, с которыми мы сталкиваемся сейчас.