Modularization of large Ember application

We are considering to use EmberJS for a large project. We are in early stage of proof-of-concepts, but we like the core concepts of Ember so far. However, we are little bit lost regarding how to structure and modularize our project.

We have started with ember-cli (based on broccoli) that provides simple project structure and basically compiles all assets into few files that are all served right away to the client. We would like to do two things:

1. Split project into two layers:

• Company-wide foundation of UI components, that can be reused in our other projects. This layer may basically contain anything that we consider reusable and not product specific. Components, templates, utility helpers, mixins, reusable views and controllers, perhaps user management and other common stuff.

• Product application layer built on top of previous layer. This will contain actual screens, routes, application logic and product-specific components and views.

It would be very helpful if the two layers could be in two separate repositories, but still could be easily developed and managed at once. I like a concept of git submodules for dealing with multiple repositories in one project during a development. It would be great if we could build, test and pack the first layer separately and once built, use it as a dependency for the final product built on top of it.

2. Build separate packages and load them dynamically by client

We would like to avoid building whole application into one big app.js file and load it on client every time. Instead we would like to split application during build into several smaller packages that are loaded on client by demand.

There are several reasons for this:

• We have different kinds of users that work with the application based on their role and permissions. While some users may only use few screens, others may use much more screens or a different set of screens based on their permissions. For example there's no need to load administration part of the application if the client has permission only to access basic functionality of the application. This is mainly for optimization but also for security. I think we can draw lines between modules mostly on URL / routes.

• We will offer different licenses for the product. We don't want to ship parts of application that the customer has not a license for. Again I think we can split modules by URL / routes in this case.

• We would be very happy if we could build a small package that contains all necessary components to let user launch the application and log in, then load the rest of the application once the user logs in.

To summarize, there are two things that we need to solve:

1. Split an application into multiple packages during a build
2. Dynamically load demanded packages on a client

I have no idea how to adapt build process (currently ember-cli and broccoli) to our needs. I can imagine how to deal with dynamic loading on a client though. I think we could use promises in route's "model" hook to asynchronously load required module that contains all required resources and inject them into Ember DI container. I'm not sure if Ember contains any logic (other than route's model hook) that would support such a dynamic loading. To my current knowledge, Ember just throws exception if it cannot find requested resource (like controller, view, template etc.) in its container. That would mean that we have to make sure that the package that we load for the route contains everything that can be possibly needed inside the route and manually inject it into the container. I'm fine with that approach if we have tool that tells us all dependencies for any given route, which I guess isn't easy. That dependency tree would have to be used in the build process as well.

Guys, any ideas? :)

ORIGINAL QUESTION ON EMBER DISCUSS FORUM