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:
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.
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.