bjorkblom
bjorkblom

Reputation: 1959

The achitecture of a large scalable Angular app

We're building a large modular Angular application currently in version 5.2.0. Since the application is modular built and each piece of the application is built by different teams in the organization everything puts together when packaging for production. There are currently many risks by having one big automated build that builds all our applications into one production ready single page application. This last step needs as for today be handled manually.

The architecture we have today looks something like this:

   ROOT_APP
  /   |   \
APP1 APP2 APP3

ROOT_APP

Starts the angular application and instantiates the AppComponent. All global UI elements like top navigation, systembar, dashboard and user profile settings exists in this module.

AppX

Developed by other parts of the organization in different repositories. When building those application we build and publish just the chunk file(s) this application outputs. Those chunks gets installed in production and gets delivered to the clients. All those application is accessed one level down in the application like ${HOST}/appx through the Angular router.

Issues with our setup:

  1. All 3pp node libraries needs to be added in ROOT_APP.
  2. All AppX need to rely on the same version of 3pp node libraries
  3. Treeshaking is not possible.
  4. AOT not possible.

The setup works, but I think it's possible to do it even better and it would be interesting to hear from others, what's your experience of how to set the architecture and developing large scalable Angular apps?

Upvotes: 0

Views: 94

Answers (1)

user4676340
user4676340

Reputation:

Well, I don't know why you chose this approach, because it isn't convenient at all from what I see ...

Personnaly, in the projects I did, we had several teams that worked on the same project, with version control. We created Angular modules and each team worked on their module, then we created pull requests when we were done, PR that needed to be validated by other teams.

This means we only had one project, getting rid of all of your constraints at once.

Upvotes: 1

Related Questions