Составление большого приложения Angular 2 с несколькими небольшими приложениями внутри


17

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

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

Учитывая природу нашего продукта, он огромен, и в нем есть модули, которые сами по себе являются другим доменом и могут быть созданы как отдельное приложение, но сам продукт живет по одному URL.

Пример;

Давайте назовем мой продукт SuperApp.

В качестве пользовательского интерфейса SuperApp имеет стандартную систему входа в систему и переход к дочерним модулям / субпродуктам, так что рабочий процесс выглядит следующим образом.

  • SuperApp

    • Аутентифицировать пользователя
    • Мастер забытых паролей
    • Публичная страница доступна без авторизации
    • Аутентифицированный пользователь

      • Навигационная система

        • Дом
          • Sub-product1
          • Sub-product2
          • Sub-product3
        • Профиль

          ...

          ...

        • группы

          ...

          ...

Обратите внимание, что в приведенном выше представлении, Sub-product1и Sub-product2две совершенно разные области, имеющие совершенно разные бизнес-доменов.

Сейчас я могу думать о том, что я могу создать SuperApp как единый проект Angular 2, имеющий только компоненты и представления, которые имеют отношение к нему, а SuperApp также отвечает за загрузку нескольких дочерних приложений; Sub-product1, Sub-product2(Опять же , разный угловые 2 проекта, имеющий свою собственную package.json, webpackконфигурацию и т.д.) с помощью тупых-компонентов, а также выступать в качестве оболочки , которая обеспечивает маршрутизацию верхнего уровня и заполнителем для хранения этих дочерних приложений.

После Sub-product1загрузки в оболочку он добавит свои маршруты к текущему маршруту, к которому прибыл SuperApp.

Причина, по которой я хочу отделиться, заключается в том, что в этих разных приложениях (которые в настоящее время создаются с использованием ExtJS) работают специальные команды (у нас более 500 разработчиков), поэтому, если у них есть свои собственные проекты Angular, они могут управлять своими инструментами. и зависимости по своему вкусу, не полагаясь на приложение прародителя.

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

Любые указания или даже ссылки на любые соответствующие статьи будут оценены.


Вы нашли какое-нибудь решение для этого?
Давал Мартак

@DhavalMarthak Пока нет, я все еще открыт для идей.
Kushal

@ Кушал Вы получили какое-либо решение для этого? У меня такое же требование
Keerthivasan

@Keerthivasan Еще не получил, хотя хорошей альтернативой было бы создать общий глобальный package.json, а затем создавать микро-приложения на странице повсюду, но это будет работать в гармонии, только если все внешние команды разработчиков находятся в синхронизации. Так что, если ваш продукт действительно большой, это скорее политическое решение, чем выбор архитектуры.
Kushal

1
На microxchg 2018 было несколько разговоров о разрушении внешнего монолита, в которых говорилось о некоторых подходах. Может быть, там есть что-то полезное. См. Youtube.com/watch?v=rCxj-ONZmxs и youtube.com/watch?v=7MHsPfoonqs
разумные штаны

Ответы:


1

То, что вы описываете, я знаю по модулю therm. Так что я буду ссылаться на это как таковое.

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

В этом случае каждая точка на диаграмме должна быть отдельным приложением. Они обязательно должны общаться друг с другом, в соответствии с каждой обязанностью составлять мнение, которое вы описали. Вы видели, как у Google есть отдельный URL / инструмент / система для авторизации? Gmail не заботится о том, что это не его ответственность. Даже обработка всех инструментов занимает центральное место, а не располагается в каждом инструменте (вы видите это на дизайне материала). Активы живут вне каждого проекта / системы.

Тем самым вы достигнете более высокого уровня повторного использования и гибкости ваших систем. Хотя в небольших командах это невыносимо из-за сложности и времени. Теперь ваша задача выяснить, где ваш случай падает. Все в микро сервисах и отделении, все в одном ПКГ или где-то посередине. А модули, если они есть, это то, что вы бы использовали внутри каждой точки.


1

Один из вариантов: вы могли бы «жестко связать» (вместо использования ссылок SPA) с вложенными приложениями и сделать так, чтобы каждое вложенное приложение делило зависимость для оболочки сайта.

Используя наш сайт, вы подтверждаете, что прочитали и поняли нашу Политику в отношении файлов cookie и Политику конфиденциальности.
Licensed under cc by-sa 3.0 with attribution required.