Угловой подход к микро-интерфейсу

Насколько я могу судить, есть два популярных случая использования микроконтроллеров:

1) Одна страница с компонентами (каждая на своем сервисе) 2) Несколько страниц, доступных из приборной панели / навигационной панели (каждая часть на своем сервисе)

Я уже давно копаюсь, и, насколько я могу судить, случай 1 довольно прост при использовании пользовательских элементов Angular.

Проблема в том, что мне нужно решить случай 2. По дизайну у меня есть информационная панель (панель навигации сбоку страницы) со списком маршрутов для различных точек входа компонентов (отчеты, пользователи и т. Д.).

Я хочу, чтобы эта часть была контейнером, и каждый маршрут на навигационной панели контейнера приводил к отдельному микро-интерфейсу, который может жить сам по себе и как часть контейнера. Так что у меня будет, например, reportService, userService и т. Д. И основная / контейнерная служба, когда я создам полный сайт.

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

Есть ли для этого популярные и готовые к продвижению подходы?

РЕДАКТИРОВАТЬ: Идея, например, состоит в том, чтобы иметь возможность иметь две команды, каждая из которых работает над отдельной частью сайта (отдельный контекст), без какого-либо влияния друг на друга. Оба получили автономную часть сайта, и при развертывании изменения могут быть добавлены к основному содержащему сайту. Между этими двумя подсайтами существует минимальное (если оно есть) соединение, их можно запускать отдельно или внутри контейнера.

Я добавил ссылку на статью, которая объясняет мою проблему и многое другое, и делает ее намного лучше, чем я когда-либо мог сделать https://martinfowler.com/articles/micro-frontends.html


angular micro-frontend
person Ivgi    schedule 03.10.2019    source источник
comment
Я не хочу показаться грубым, но похоже, что вы используете слова, которые действительно не знаете, и это приводит к очень размытым предложениям ... В Angular каждая страница SPA имеет свои собственные компоненты, они обычно маршрутизируются, а службы - это просто классы, которые содержат всю вашу бизнес-логику. Я не знаю двух популярных случаев использования микро-интерфейсов, и распространение микро-аспекта на интерфейс может быть не очень хорошей идеей (поскольку Angular уже делает это внутри).   -  person    schedule 03.10.2019
comment
Я понимаю, что у меня есть разделение в самом проекте ... отдельные модули и другие стандартные подходы для разделения компонентов и логики внутри углового проекта. Но я тестирую возможность перенести его в отдельный проект. Есть несколько очень хороших преимуществ для этого и на стороне клиента.   -  person Ivgi    schedule 03.10.2019
comment
Итак, вы переходите от микросервисной архитектуры (например, API) к монолитной, а не наоборот?   -  person    schedule 03.10.2019
comment
Я видел ваш другой комментарий (к ответу): вам не нужно беспокоиться о конфликтах в Angular, каждый модуль отделен от своего брата. Как я уже сказал, все это делается под капотом, в отличие от API. Если бы я мог дать вам один жесткий совет, я бы не применял принципы back-end к front-end стороне вашего проекта. Они разделены по какой-то причине, и пробуя такие вещи, вы получите больше головной боли, чем результатов.   -  person    schedule 03.10.2019
comment
Действительно, выбор такого подхода - на стороне сервера или на стороне клиента - более сложен. Но именно здесь все, кажется, перемещается: меньшие компоненты, меньшие блоки, большее разделение и т. Д. Я хочу протестировать это на новом проекте. Потому что я видел много отрицательных эффектов от наличия клиентского монолита, независимо от того, насколько хорошо angular с этим справляется.   -  person Ivgi    schedule 03.10.2019
comment
Но опять же, меньшие компоненты / блоки / и т. Д. уже сделано в Angular. Я действительно пытаюсь вам это объяснить, это работает и ведет себя по-разному. Если вы следуете своему подходу к микросервисам, вы складываете приложения друг в друга (что означает, что они отображаются на вашей странице одно за другим!). Это портит вашу маршрутизацию, это портит вашу глобальную область видимости, это мешает вашему управлению состоянием в браузере, вы кешируете ... На самом деле, это два разных мира!   -  person    schedule 03.10.2019
comment
привет @Maryannah, вы говорите, что использование модулей во внешнем интерфейсе - плохая идея?   -  person anjnkmr    schedule 03.10.2019
comment
@rak Нет, это не так. Я говорю, что разделение одного приложения Angular на несколько (в отличие от разделения модулей, как это было задумано в Angular) - не лучшая идея.   -  person    schedule 03.10.2019
comment
Хорошо, на самом деле, я также работаю над большим проектом с разными модулями. Есть ли лучший способ заставить разные команды работать над таким проектом? вы можете предложить   -  person anjnkmr    schedule 03.10.2019
comment
@rak, если они работают отдельно над каждым модулем, то нет, лучшего подхода придумать не могу. Вот как можно использовать Angualr!   -  person    schedule 03.10.2019
comment
Но что, если, например, вы хотите полностью разделить два домена - пользователей и отчеты. Каждый домен технически представляет собой отдельный продукт - разные сервисы, клиентскую и серверную стороны, над каждым из которых работает разная команда. Тем не менее, в конце концов, вы действительно хотите развернуть / разместить их на одном и том же главном веб-сайте на вашем компьютере.   -  person Ivgi    schedule 03.10.2019

Ответы (2)


arrow_upward
0
arrow_downward

Я следовал этому подходу в своих проектах, надеюсь, он вам поможет.

Несколько страниц, доступных из панели инструментов / навигационной панели (каждая часть на своем сервисе)

Мы создали несколько модулей на основе таких функций, как UserModule, ReportsModule, InitialModule и т. Д., Чтобы мы могли лениво загружать разные модули в зависимости от маршрута.

Каждый модуль будет иметь свои собственные службы, компоненты, классы и активы, необходимые для модуля. Например, InitialModule будет иметь компоненты, связанные только с Login и Dashboard, и мы установили его как bootstrap module в main.ts, чтобы страница загружалась быстро, загружая js, CSS и HTML, которые требуются только для этих двух компонентов, вместо все активы

person anjnkmr    schedule 03.10.2019
comment
Но это все-таки единый проект? Я пытаюсь протестировать подход к фактическому разделению этих «модулей» на их собственные проекты, которые могут работать автономно без контейнера. Каждая команда может работать над своим собственным модулем, не беспокоясь о конфликтах или влияя на что-либо, выходящее за рамки их проекта. - person Ivgi; 03.10.2019
comment
да, это единый проект, чтобы сделать отдельные проекты с модулями, сначала нам нужно подготовить общие / общие модули, а затем импортировать их во все проекты - person anjnkmr; 03.10.2019
comment
На самом деле мы использовали аналогичный подход, но сейчас я очень хочу получить полное разделение в будущем по новым проектам. - person Ivgi; 03.10.2019

arrow_upward
0
arrow_downward

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

person Oriol_IL    schedule 23.10.2019