What ember-cli structure should be used if a site has multiple and quite distinct ember apps? Let’s say they would naturally fall under URLs like /search, /calculator and /account. The site then has multiple other “server side” pages too, e.g. /about, /privacy, etc.
Would you:
Have three ember-cli apps? (in which case very hard to fully test whole site using three “ember serves” simultaneously)
Refactor URLs and combine apps “unnaturally” into /app/search, /app/calculator and /app/account?
I don’t have an answer for you, but I would really be interested in why you want to make three distinct apps from one website which just has different features.
To me, the use case for such a structure has yet to be found… Won’t you need some things in all of those different parts of your app, like usersettings/account and rights-management?
I’m just curious, maybe this makes perfectly sense to you, but maybe you can elaborate a little more about the reasons for the desired division of your website…
Ember is heavyweight to download and I definitely don’t want it on landing/entry pages where both users and now Google judge a site by how fast it loads. So therefore that’s why ember is not on every page.
For why to have “separate” apps instead of one with different features. Well partly I prefer to have a user-first URL structure not a “technology first” one. Arranging all your ember URLs under /app/* is like a grocery store arranging all its goods by supplier instead of by type. Plus things like user settings are shared across all pages, not just the client-side ember ones.
You don’t have to have everything under /app if you don’t want - you can configure your webserver to map your url space however you want, so that /calculator and /account maps to your ember app and / and /search maps to whatever else you want
Thanks @alexspeller, I clearly wasn’t aware of that. I don’t suppose there are any particularly good references you know about for this? Things get outdated so quickly these days, although that’s the cost of progress. I found this one: http://mockra.com/2013/12/19/brunch-express-ember-part-1/, although clearly not using ember-cli.
You also can make seperate ember cli addons of the different features and just include them as dependency and initiate with a initializer if needed: Building Ember Addons
From the ember cli documentation as a reason to do that:
Providing a custom application tree to be merged with the consuming application
But in the danger of sounding annoying/boring/scared: I have noticed that ember is one of the these frameworks (like most of them are now) where it’s really easy and fast(!) to develop with but only if you follow their conventions very strictly and don’t try to do custom stuff; Don’t try to work against those conventions or you will have a hard time; And Do everything with ember and don’t even think about using anything else parallel. Having more than one app work on one website would definitely fall under “trying to do custom stuff”
I also can’t agree on the approach of developing software in a way so that google likes it (screw them!), no offense…
But I’m looking forward to hear how you went and what you decided for
I don’t see anything wrong with having multiple Ember apps for a given site. In fact, I’m doing that now, as each app has a distinct user experience for a different audience. For example, if you were building an app for a library to manage their books, you can have the following URLs, all driven by separate ember apps.
/admin/
/borrowers/
/publishers/
You’ll want to heavily leverage Ember CLI Addons so that you don’t have any code duplication, but I think there is a use case for having separate apps.
