While doing some reading on Ember, I kept coming across the term "pods". It sounded a little alien at first, but upon further investigation, it actually makes a lot of sense to me.

Pods are a way of grouping files in your project by feature (ex: Task) rather than by type (ex: controllers).

Or as Scott Batson puts it: grouping project files by routes. He uses a hybrid implementation of the pods, which I have become partial to, and thus shall document for my own use in future projects.

It's pretty easy to get started with pods, as it's built in to Ember. The steps below are applicable to starting a new project.

As usual, to create a new Ember project, run:

ember new new-project-name

Once all the project files have been generated, update the .ember-cli to enable the use of pods:

{
  /**
    Ember CLI sends analytics information by default. The data is completely
    anonymous, but there are times when you might want to disable this behavior.

    Setting `disableAnalytics` to true will prevent any data from being sent.
  */
  "disableAnalytics": false,
  "usePods": true
}

You'll probably want to delete the following directories while you're at it, as they become redundant when pods are in use:

• app/routes
• app/controllers
• app/templates

Now when you generate a route, like so:

ember generate route blog

You'll get the resulting app/ folder structure:

.
+-- blog
|   +-- route.js
|   +-- template.hbs
+-- components
+-- helpers
+-- models
+-- styles
+-- templates
...

I mentioned that Scott Batson (among others, I'm sure) uses a hybrid approach. It is hybrid, because the models are generated without pods. Meaning, when a model is generated, it is done so by passing in the --pod flag, which disables pods for that generate command:

ember generate model post --pod

So when pods are enabled in your .ember-cli file, you pass in the --pod flag to disable them, and vice versa.

It is a good idea to generate models without the use of pods, because models can be used by more than just one route. The same can be said for the adapters and the serializers, i.e. they are not really exclusive to whatever route you’re on at that time, thus it would make sense to keep them in dedicated app/adapters/ or app/serializers/ directories.

That is all.