My requirements are to build an app with multiple sub-app to meet different requirements and release cycles.
Project structure
MyApp - Main app with some shared models, controllers, views, helpers, etc
|---- SubApp1 - Use case1 with specific MVC’s
|---- SubApp2 - Use case2 with specific MVC’s
How do I control my ember-cli to choose only MyApp + SubApp1 in release1, MyApp + SubApp2 in release2, may be MyApp+SubApp1+MyApp+SubApp2 in release3. This helps me to avoid deploying un-used assets of Sub-App2 into my server. In current approach, I am simply hiding the hyper link but if someone knows the project structure they directly enter the url and can access the complete SubApp2 assets. Ideally I don’t wanted to allow anyone to access the SubApp2 until I share.
I can surely achieve this in angular/backbone with gulp/grunt but not sure what is the best way to achieve in emberJS with ember-cli.
I’m not a 100% clear on your problem but I don’t believe ember has an elegant solution to the “subapp” problem. There maybe some work being done towards it in the mid future with engines. You could also create separate apps for the sub apps and use private addons to share code between the apps.
@snkani I would not use any build tool other than ember-cli. For the primary reason that many addons (and possibly coming ember features) will require the build pipeline structure offered by ember-cli.
We have this exact same sub-app configuration. Here is what our structure looks like.
MyApp
|-- Bootstrap - Common code
|-- app
|-- styles
|-- common-app.scss
|-- SubApp1 - Main app
|-- app
|-- styles
|-- app.scss (imports common-app.scss)
|-- lib
|-- bootstrap (symlinked as local addon)
|-- SubApp2 - Browser extension app
/* Same as SubApp1 */
|-- SubApp3 - Admin app
/* Same as SubApp1 */
So basically we have our common code in bootstrap, a “local addon”, and then we symlink that into each “real ember-cli app”'s lib directory. We choose this route over making a actual private npm addon because they are not watched. This means changes to your addon don’t cause it to rebuild.
This has worked well for us thus far. It can feel a little clunky, but it gets the job done. Unfortunately I don’t think engines will actually solve this problem for us. We don’t have our apps separated for performance/packaging reasons, we have them separated because they are actually different. They have different login screens, different routes, etc, etc, etc.
@varblob Because the apps are actually different, very different. One is a main web app, the other is an embedded browser extension (and there is a third and fourth, but we’ll leave them out). See screenshots:
So the first screenshot shows the browser extension running w/ the login screen (embedded on this page). The second screenshot shows the main web app with it’s login screen. There are also similar, yet different, pages between the apps (reset password, user home, settings, etc). Logically the routes are the same, but visually they’re completely different.
The overlap that exists between the two apps is [all] models, utils, translations, some base services and some commonly used components.
So engines seems to be aiming to solve the issue of isolation and performance. While my need is really of separate apps, that have a common API or common foundation.
I’m not sure how my use case really fits in. It doesn’t feel on the fringe of things. I’ve talked to others in the enterprise space and they often have the same need. Hence why their initial reaction is to shy away from ember-cli and try to solve this with another build tool.
Yeap! Absolutely. We’ve started the transition away from views and controllers recently. Trying to be practitioners of Ember 2.0 patterns. We have mostly components which are full of business logic.
If this structure is something you’re still debating and need some help flush it out, I’d be happy to put together a template github repo that mirrors this structure and you could kick it around.
