I am about to embark on the development of a large scale web app which will be used internally for my company (http://EpicProportionsTour.com). We will have many user roles (approximately 5-7) and each role will need a complex screen to manage their respective daily tasks.
From what I have studied about Ember so far, my thoughts are having a separate Ember app/html page/etc for each role, however, I would love to learn what the best practices are in large projects for:
module design
How do I best separate concerns to keep the code used in a specific app separate from other apps, and share those modules which will be used across applications? Should I create a kind of lib folder and drop various js apps to be used across the many pages there and then have a specific folder for each role and put its core js apps there? I could then name those js apps according to the role they are playing. Are there other perhaps better naming conventions for the javascript files? I saw one example where the tutorial had all of the js files named āapplication.jsā and they were in separate folders called views, models, and controllers. This didnāt seem right to me. How confusing to name all of these apps the same! Why not call them view.js, models,js, controllers.js?
HTML Design
Should I create a separate HTML page for each role? It seems like trying to do all roles inside on HTML file would be insane. Also, Iāve heard about pre-compiling templates. I would love to have some form of re-usable controls. Where do these normally reside? What is their format? Iām guessing that they are external HTML handlebar fragments which are somehow included/referenced in the HTML files in which they will be used. If so, how are these includes normally done? Are their Ember best practices around this?
Many thanks in advance for any help in this matter! Perhaps we could create an Ember FAQ/Best Practices document around Large Scale Development Best Practices? Of course, I am assuming one doesnāt already exist.
Thats a pretty big question and Iām not qualified or skilled enough (yet) to really answer it, but since youāre about to dive into a large ember app for the first time, I HIGHLY recommend taking a look at Ember-CLI. Its still a major work in progress but theyāve already made great strides. And how they organize an app is spot on. Its a great place to start.
Ember CLI is cross platform- if you can install Node on it, youāre good to go. If youāre on Windows, I would highly recommend using something like Git Bash for your CLI.
Actually I love the Mac and not windows. In any case, can we get back to the topic of project organization and design architecture for large scale projects? Do any of you have any commentary on that?
Modular code is aiding greatly by using ES6 syntax. Thereās a built-in transpiler for it on CLI. You saw an application with seperate JS files AND a single app.js file- thatās because they use build tools (CLI is custom-tailored for CLI, but grunt/brunch are OK options too). Separate template files is how every is how just about everyone is splitting out code, but you need some kind of build or task tool as well. Once again, CLI is magical.
So the reason everyone keeps telling you to check out CLI is that itās the answer to the questions you asked that a lot of us have chosen.
+10 points to @kylecoberly. I was actually about to write out the file structure. Even if you dont use the CLI, the file structure and basic architectural layout is starting to become very common. In the same way you can instantly navigate the project structure of a Ruby on Rails or PHP and CodeIgniter app, youāll eventually have the same ease with a Node.js/Express and Ember app.
One thing to discuss is what particular language and framework are you planning on using? I can sorta lend my two cents (thats about all I have) for a node / express based app, but Iām useless if youāre looking at plugging it into a Rails app (although Iād wager they are the same. The only real difference is where you place the app and your various assets).
Another note: Es6 Modules are really built into everything Ember is trying to do. I wager youāre already familiar with them so Iāll just reiterate that they make things much more manageable. You could stuff everything into one fat controller file, but its nicer to break it down.
If this is large scale, long term project then you should standardize around ember-cli. You will end up hand rolling most of the features ember-cli provides be default. However if this is not going to work out for you then you will have to maintain your own build systems. Not hard, but it is a time sink for the team.
It does sound like your app is composed of serval smaller apps. They have very specific use cases and Iām guessing the UIs are also very focused on those use cases. If this is the situation then you are mostly going to be sharing models, components, and mixins. I keep these bits in a separate git repo with itās own test suite and distribute them to my apps with bower (another ember-cli standard).
Pre compiling temples is a must in production (another ember-cli standard). If you donāt pre compile templates then the browser has to do it at run time and if it is a large app it gets slow.
At the end of the day keep in mind that all these tools are just building a js file, css file, and an index.html which links to those things. It is not magical in anyway, you are just building a website. It sounds like you need to build a few websites that share some common code
Re: FAQ/Best Practices Document for large scale ember apps
When the community makes all the mistakes it can make building these things then we can start that document However I can absolutely assure you that there are solutions to your problems, you just may have to get your hands dirty.
Another +1 for ember-cli. We just launched two relatively large apps last week (http://zing.co). Over the past nine months, weāve moved from developing our own grunt-based build system, to Ember App Kit and finally to ember-cli. Ember-cli is hands down the best way to develop Ember.js apps of any size and many of the answers to the ābest practicesā questions you have are baked into it (template precompilation, module naming, etc). Iād also highly recommend adopting a āpodā-based folder layout.
For shared modules, we have all of our shared code in a git submodule and then merge the two trees together in our Brocfile. Submodules have their own set of headaches, but there are relatively few options available if youāre frequently publishing revisions/committing to the shared code tree.
Well it wont let me post images but if you feel I am trust worthy you are welcome to go to the image I posted above. I just created it and Its rated G and pretty funny.
Thanks for the great advice!
I am using a Java based Spring backend based off of RESTful CRUD services. I will post my basic design concepts after studying Ember-CLI and get some feedback from you guys. Thanks so much for the help!
Iāve worked on hefty Ember products and havenāt had the privilege of using Ember CLI for them (yet). So hereās my advice once you have the build process in place:
Try to use Ember Data. If you canāt change your backend API to be exactly what Ember Data wants, you can make little adapter/serializer functions that sit between and turn your JSON into Emberās favorite kind of JSON. Even though itās a little more work, itās so much easier than adapting the rest of your app to work for you. Most of my daily stress revolves around having a little non-standard JSON that needs ten times more babysitting than if it was standard.
Em.computed properties. There arenāt a ton, but you can make your own. Make your own (http://robots.thoughtbot.com/custom-ember-computed-properties). You get what feels like a big global function, and you only have to test it in one place! Even though you could write a function that maps, sums and compares the total all in one, you could make three simple Em.computed properties instead, have them run in a row, and save all the maintenance headaches. Embrace the baby building blocks.
If youāre using a jQuery plugin for anything, put it in a little Ember Component and communicate through that instead (http://eviltrout.com/2014/06/03/jquery-component.html). Ember and jQuery is like a Roman army and a monkey with dynamite. The monkeyās powerful, but you need to train someone to tell the monkey where the dynamite goes. Do not trust the Plugin Monkey; you donāt know where he came from.
Keep messing with routes. Whenever it gets hard to keep track of some states, look at routes again and see if they could make things easier. I never need them at first, but then Iāll come back to a controller weeks later, go āwhat if I just made a couple routesā and WHAM everythingās simpler. Routes are how you handle the fourth dimension in Emberā¦ once you see how people travel through your product, routes can help pave the roads.
TL;DR: Try to stick to the Ember ābest practicesā you find as much as possible. It isnāt necessarily ārightā, but donāt waste all your damn time arguing with it, because it has opinions but not emotions.
Thanks for that great info! Is there a document for Ember Best Practices? If not, perhaps we can all work together to create one.
Also, on another note I havenāt started writing any code yet on the front or back end so I am really free to design this thing how I want. Also, I want to do a lot of planning and thinking about the architecture before I start coding.
At least on the backend / Ember data side, The most valuable guide Iāve found is this transition page. It shows what changed in version 1.0, but there are so many examples that it got me up to speed on how to handle things.
Theyāre trying to make all APIs like this: http://jsonapi.org/. Iāve used several of the things on their examples page in projects and it works well. I donāt know if thereās a Java library so you might have do more yourself, but at least you know what Ember Data likes most. Specifically,
instead of nesting a list of child objects, just list their IDs, or call to get them separately
the more things you can get by ID instead of a special query, the less youāll curse
There really isnāt much about building larger things yet. Itās not because larger things are not being built, itās just that each of those projects has a different set of trade offs to deal with. Itās going to take conversations like this help hone in on a better solutions and guidelines.
We need lots of different ideas right now. We also need to settle on some solutions, e.g. ember-cli, so that we can invest more time solving these other kinds of problems
After you are done planning and dreaming let us know how it works out.
From what you describe in your initial post, you say you need 5-7 roles each with their own complex screen. I would recommend starting with a single ember app with routes for each role - this sounds like a very small problem to start dealing with multiple ember apps for - ember easily deals with having multiple seperate screens and routes and a single app with multiple routes should definitely be your default choice.
As others have mentioned, use ember-cli or take inspiration from itās folder structure
It sounds like you only need a single HTML page - your ember app would have multiple routes and each route would have a seperate .hbs file, which would then be precompiled into your js by your tools.
