Складає великий додаток Angular 2 з кількома невеликими додатками


17

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

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

Зважаючи на характер нашого продукту, він є величезним, і всередині нього є модулі, які самі по собі є різною областю, і їх можна зробити як окремий додаток, але сам продукт живе за однією URL-адресою.

Приклад;

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

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

  • SuperApp

    • Аутентифікувати користувача
    • Забудьте майстра паролів
    • Загальнодоступна сторінка доступна без автентичності
    • Автентифікований користувач

      • Навігаційна система

        • Головна
          • Підпродукт1
          • Підпродукт2
          • Субпродукт3
        • Профіль

          ...

          ...

        • Групи

          ...

          ...

Зверніть увагу , що в поданні вище, Sub-product1і Sub-product2дві абсолютно різні області, які мають абсолютно різні бізнес - домени.

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

Після Sub-product1завантаження в оболонку він додасть власні маршрути до поточного маршруту, на який приземлився SuperApp.

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

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

Будь-які вказівки або навіть посилання на будь-які відповідні статті будуть вдячні.


Ви знайшли для цього якесь рішення?
Дхаваль Мартак

@DhavalMarthak Ще немає, я все ще відкритий до ідей.
Кушаль

@Kushal Чи отримали ви це рішення? У мене така ж вимога
Keerthivasan

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

1
Було кілька розмов про руйнування переднього моноліту на microxchg 2018, які розповідають про деякі підходи. Можливо, там є щось корисне. Див youtube.com/watch?v=rCxj-ONZmxs і youtube.com/watch?v=7MHsPfoonqs
sapientpants

Відповіді:


1

Те, що ви описуєте, я знаю модулем therm. Тож я буду називати це як таке.

Я не збираюся займатися питанням того, чи є кутові модулі підтримки через відсутність знань про рамки. Також, на мою думку, ви цього не дуже хочете. Наскільки я розумію, і я очікую, що ваша думка відображається, ви хочете розрізати все на найменші шматочки ( мікро-сервіси ).

У цьому випадку кожна точка на вашій діаграмі має бути власною незалежною програмою. Вони впевнені, що повинні спілкуватися один з одним, відповідно до кожної відповідальності складати описаний вами погляд. Ви бачили, як Google має авторизований окремий URL / інструмент / систему? Gmail не переймається цим завданням, це не є його відповідальністю. Навіть обробка всіх інструментів є центральною, а не розміщеною в кожному інструменті (це ви бачите на матеріальній конструкції). Активи живуть за межами кожного проекту / системи.

Таким чином ви досягаєте більш високого важеля використання та гнучкості ваших систем. Хоча в невеликих командах це незрівнянно через складність та час. Тепер ваша робота з’ясувати, куди потрапляє ваша справа. Все в мікро-сервісах і розділенні, все в одному кг або десь посередині. А модулі, якщо вони є, - це те, що ви використовували б у кожній крапці.


1

Один із варіантів: ви можете "жорстке посилання" (замість використання посилань на SPA) на додатки та кожен суб-додаток матиме залежність від обгортки сайту.

Використовуючи наш веб-сайт, ви визнаєте, що прочитали та зрозуміли наші Політику щодо файлів cookie та Політику конфіденційності.
Licensed under cc by-sa 3.0 with attribution required.