17

After long 3 months of debate and research in choosing between React (with Redux) and Angular 2, front-end team in my company has concluded to go with Angular 2 (given that it is more suited for our problem).

We're into enterprise app business, which is currently comprises of many different front-end technologies (while having entire backend RESTful), and we wanted to replace it all and have a single technology to make future training and quality control easier.

Given the nature of our product, it is vast, and there are modules within, which are in itself a different domain and can be made as a standalone app but the product itself lives in a single URL.

Example;

Let's call my product as SuperApp.

As a UI, SuperApp has standard login system, and navigation to child modules/sub-products, such that the workflow appears as follows.

  • SuperApp

    • Authenticate User
    • Forget password wizard
    • Public page accessible without auth
    • Authenticated User

      • Navigation System

        • Home
          • Sub-product1
          • Sub-product2
          • Sub-product3
        • Profile

          ...

          ...

        • Groups

          ...

          ...

Note that in above representation, Sub-product1 and Sub-product2 are two entirely different areas, having entirely different business domains.

What I can think of right now is that I can create SuperApp as a single Angular 2 project having only components and views which are relevant to itself, and SuperApp is also responsible for loading up of multiple child apps; Sub-product1, Sub-product2 (again, different Angular 2 projects, having their own package.json, webpack config, etc.) via dumb-components, and act as a shell which provides top-level routing and a placeholder to hold those child apps.

Once, Sub-product1 is loaded within the shell, it'll append its own routes to the current route that SuperApp has landed at.

The reason I want seperation is because these different apps (which are currently built using ExtJS) have dedicated teams working on it (we're a company having 500+ developers), so if they have their own Angular projects, they can manage their tooling and dependencies to their liking without relying on grand parent app.

But I'm unable to find anywhere in official Angular docs, or on the web that whether having nested Angular apps is possible at all (in such a way that framework code is shared while dependencies of child apps are completely isolated and loaded only when app needs it), or whether there is any alternate approach to solve such a problem.

Any guidance or even links to any relevant articles will be appreciated.

  • Did you find any solution for this? – Dhaval Marthak Apr 5 '17 at 7:07
  • @DhavalMarthak Not yet, I'm still open to ideas. – Kushal May 8 '17 at 8:21
  • @Kushal Did you get any solution to this? I have the same kind of requirement – Keerthivasan Sep 21 '17 at 7:01
  • @Keerthivasan Haven't got any yet, although a good alternative would be to create shared global package.json and then do micro-apps within page everywhere, but this will work in harmony only if all frontend dev teams of the company are kept in sync. So if your product is really large, this is more of a political decision than an architecture choice. – Kushal Sep 21 '17 at 8:36
  • 1
    There were a few talks about breaking down the frontend monolith at microxchg 2018 that talk about some approaches. Maybe there is something useful there. See youtube.com/watch?v=rCxj-ONZmxs and youtube.com/watch?v=7MHsPfoonqs – sapientpants Apr 24 '18 at 7:20
1

What you're describing I know by the module therm. So I'll refer to is as such.

I'm not going to address the question of whether or not angular support modules for lack of knowledge on the framework. Also, in my opinion you don't really want this. In my understanding, and I expect your backend reflects, you want to slice everything to the smallest bits you can (micro services).

In this case each dot on your diagram should be it own independent app. They sure must communicate to each other, according to each responsibility to compose the view you described. You saw how Google have a separated url/tool/system to auth? Gmail do not care about that cuz it is not its responsibility. Even skining of all tools is central instead of being located in each tool (you see this on material design). The assets live outside each project/system.

Doing so you achieve a higher lever of reusability and flexibility of your systems. Although in small teams this is untenable due to the complexity and time. Now it is your job to figure out where your case falls. All in micro services and separation, all in one pkg or somewhere in the middle. And modules, if available, is something you would use inside each dot.

1

One option: you could "hard link" (instead of using SPA links) to the sub-apps and have each sub-app share a dependency for site wrapper.

protected by gnat Jan 8 '17 at 7:53

Thank you for your interest in this question. Because it has attracted low-quality or spam answers that had to be removed, posting an answer now requires 10 reputation on this site (the association bonus does not count).

Would you like to answer one of these unanswered questions instead?

Not the answer you're looking for? Browse other questions tagged or ask your own question.