Compondo um aplicativo Angular 2 grande com vários aplicativos pequenos dentro

Após longos 3 meses de debate e pesquisa na escolha entre o React (com Redux) e o Angular 2, a equipe de front-end da minha empresa concluiu o Angular 2 (já que é mais adequado para o nosso problema).

Estamos no negócio de aplicativos corporativos, que atualmente é composto por muitas tecnologias front-end diferentes (apesar de ter RESTful de back-end inteiro), e queríamos substituir tudo e ter uma única tecnologia para facilitar o treinamento e o controle de qualidade futuros.

Dada a natureza de nosso produto, ele é vasto e existem módulos, que são em si um domínio diferente e podem ser criados como aplicativos autônomos, mas o produto em si vive em um único URL.

Exemplo;

Vamos chamar meu produto como SuperApp.

Como interface do usuário, o SuperApp possui sistema de login padrão e navegação para módulos / subprodutos filhos, de modo que o fluxo de trabalho apareça da seguinte maneira.

• SuperApp

  • Autenticar Usuário
  • Assistente para esquecer a senha
  • Página pública acessível sem autenticação

  • Usuário autenticado

    • Sistema de navegação

      • Casa
        • Subproduto1
        • Subproduto2
        • Subproduto3

      • Perfil

        ...

        ...

      • Grupos

        ...

        ...

Note-se que na representação acima, Sub-product1e Sub-product2são duas áreas completamente diferentes, tendo domínios de negócios completamente diferentes.

O que posso pensar agora é que posso criar o SuperApp como um único projeto Angular 2 com apenas componentes e visualizações relevantes para si, e o SuperApp também é responsável pelo carregamento de vários aplicativos filhos; Sub-product1, Sub-product2(novamente, diferentes projetos do Angular 2, com seus próprios package.json, webpackconfigurações, etc.) por meio de componentes burros e agem como um shell que fornece roteamento de nível superior e um espaço reservado para armazenar esses aplicativos filhos.

Uma vez Sub-product1carregado no shell, ele anexará suas próprias rotas à rota atual em que o SuperApp aterrissou.

A razão pela qual desejo separação é porque esses aplicativos diferentes (que atualmente são criados usando o ExtJS) têm equipes dedicadas trabalhando nele (somos uma empresa com mais de 500 desenvolvedores); portanto, se eles têm seus próprios projetos Angular, podem gerenciar suas ferramentas. e dependências ao seu gosto, sem depender do aplicativo grand parent.

Mas não consigo encontrar em nenhum lugar nos documentos oficiais do Angular ou na Web se é possível ter aplicativos Angular aninhados (de modo que o código da estrutura seja compartilhado enquanto as dependências dos aplicativos filhos são completamente isoladas e carregadas apenas quando o aplicativo precisa) ou se existe uma abordagem alternativa para resolver esse problema.

Qualquer orientação ou mesmo links para artigos relevantes serão apreciados.

O que você está descrevendo eu sei pelo módulo therm. Então, eu vou me referir é como tal.

Não vou abordar a questão de saber se os módulos de suporte angular devem ou não por falta de conhecimento sobre o framework. Além disso, na minha opinião, você realmente não quer isso. No meu entendimento, e espero que o seu back-end reflita, você deseja dividir tudo nos menores bits possível ( microsserviços ).

Nesse caso, cada ponto do seu diagrama deve ser seu próprio aplicativo independente. Eles com certeza devem se comunicar, de acordo com cada responsabilidade de compor a exibição que você descreveu. Você viu como o Google tem um URL / ferramenta / sistema separado para autenticação? O Gmail não se importa com isso, porque não é de sua responsabilidade. Mesmo a aparência de todas as ferramentas é central, em vez de estar localizada em cada ferramenta (você vê isso no design do material). Os ativos residem fora de cada projeto / sistema.

Com isso, você alcança uma alavanca mais alta de reutilização e flexibilidade de seus sistemas. Embora em equipes pequenas isso seja insustentável devido à complexidade e ao tempo. Agora, é seu trabalho descobrir onde o seu caso se encaixa. Tudo em micro serviços e separação, tudo em um pacote ou em algum lugar no meio. E módulos, se disponíveis, é algo que você usaria dentro de cada ponto.

Uma opção: você pode "vincular" (em vez de usar links SPA) aos sub-aplicativos e fazer com que cada sub-aplicativo compartilhe uma dependência do wrapper do site.