Componer una gran aplicación Angular 2 con múltiples aplicaciones pequeñas dentro

Después de largos 3 meses de debate e investigación para elegir entre React (con Redux) y Angular 2, el equipo de front-end de mi empresa ha concluido con Angular 2 (dado que es más adecuado para nuestro problema).

Estamos en el negocio de las aplicaciones empresariales, que actualmente se compone de muchas tecnologías front-end diferentes (a la vez que tiene RESTful backend completo), y queríamos reemplazarlo todo y tener una sola tecnología para facilitar la capacitación futura y el control de calidad.

Dada la naturaleza de nuestro producto, es enorme, y hay módulos dentro, que son en sí mismos un dominio diferente y se pueden hacer como una aplicación independiente, pero el producto en sí vive en una sola URL.

Ejemplo;

Llamemos a mi producto como SuperApp.

Como interfaz de usuario, SuperApp tiene un sistema de inicio de sesión estándar y navegación a módulos / subproductos secundarios, de modo que el flujo de trabajo aparece de la siguiente manera.

• SuperApp

  • Autenticar usuario
  • Olvídate del asistente de contraseña
  • Página pública accesible sin autenticación

  • Usuario autenticado

    • Sistema de navegación

      • Hogar
        • Subproducto1
        • Subproducto2
        • Subproducto3

      • Perfil

        ...

        ...

      • Grupos

        ...

        ...

Tenga en cuenta que en la representación anterior, Sub-product1y Sub-product2son dos áreas completamente diferentes, que tienen dominios comerciales completamente diferentes.

Lo que puedo pensar ahora es que puedo crear SuperApp como un solo proyecto de Angular 2 que solo tiene componentes y vistas que son relevantes para sí mismo, y SuperApp también es responsable de cargar múltiples aplicaciones secundarias; Sub-product1, Sub-product2(de nuevo, diferentes proyectos de Angular 2, que tienen su propio package.json, webpackconfiguración, etc.) a través de componentes tontos, y actúan como un shell que proporciona enrutamiento de nivel superior y un marcador de posición para guardar esas aplicaciones secundarias.

Una vez que Sub-product1se carga dentro del shell, agregará sus propias rutas a la ruta actual en la que SuperApp ha aterrizado.

La razón por la que quiero la separación es porque estas diferentes aplicaciones (que actualmente se crean utilizando ExtJS) tienen equipos dedicados trabajando en ello (somos una empresa que tiene más de 500 desarrolladores), por lo que si tienen sus propios proyectos angulares, pueden administrar sus herramientas y dependencias a su gusto sin depender de la aplicación Grand Parent.

Pero no puedo encontrar en ningún lugar en los documentos oficiales de Angular, o en la web que si es posible tener aplicaciones angulares anidadas (de tal manera que el código marco se comparte mientras las dependencias de las aplicaciones secundarias están completamente aisladas y cargadas solo cuando la aplicación lo necesita), o si hay algún enfoque alternativo para resolver dicho problema.

Cualquier orientación o incluso enlaces a artículos relevantes serán apreciados.

Lo que estás describiendo lo sé por el módulo therm. Así que me referiré es como tal.

No voy a abordar la cuestión de si los módulos de soporte angular son o no por falta de conocimiento sobre el marco. Además, en mi opinión, realmente no quieres esto. Según tengo entendido, y espero que su backend se refleje, desea cortar todo en los bits más pequeños que pueda ( micro servicios ).

En este caso, cada punto en su diagrama debe ser su propia aplicación independiente. Seguramente deben comunicarse entre sí, de acuerdo con cada responsabilidad de componer la vista que describió. ¿Viste cómo Google tiene una url / herramienta / sistema separada para la autenticación? A Gmail no le importa eso porque no es su responsabilidad. Incluso el diseño de todas las herramientas es central en lugar de ubicarse en cada herramienta (puede ver esto en el diseño de materiales). Los activos viven fuera de cada proyecto / sistema.

Al hacerlo, logrará una mayor palanca de reutilización y flexibilidad de sus sistemas. Aunque en equipos pequeños esto es insostenible debido a la complejidad y el tiempo. Ahora es su trabajo averiguar dónde cae su caso. Todo en micro servicios y separación, todo en un paquete o en algún lugar en el medio. Y los módulos, si están disponibles, es algo que usaría dentro de cada punto.

Una opción: puede hacer un "enlace duro" (en lugar de usar enlaces SPA) a las sub-aplicaciones y hacer que cada sub-aplicación comparta una dependencia para el envoltorio del sitio.