Our Ember.js Toolchain

Matteo Latini

22 Jan 2014 Development, Ruby On Rails

Matteo Latini

5 mins
Emberjs + spreecommerce

Now that we've been working with Ember.js for a while, we wanted to give a quick update on what we found works out for us while working with it, both client and server side. We thought this post would be useful since we initially had some problems finding the right tools but now we really feel we found the right toolchain.

Client Side

We found the client side needs tools to: organize code, write tests and fake an API. About data persistance libraries: we use Ember Data but we won't be talking about that here because it's a really hard choice and it really depends on what you need to work on.

Organize Code

The client side is probably the most complex part; since Ember.js does not (yet) provide powerful buildtools, you have to go with whatever works best for you. Forget the starter kit provided on the homepage. It's a fast way to start experimenting but you'll end up with a huge messy file.

To provide some order to our apps we use Brunch with the tapas-with-ember skeleton. These tools will let you (among other things):

  • organize Ember code in a clean way
  • manage Ember, Ember Data/Ember Model and Handlebars libraries
  • write CoffeeScript (pretty much everywhere)
  • provide automatic file reloading
  • have a workbench ready to do TDD
  • generate files with templates via scaffolt
  • manage multiple environments (we use development, test, staging, production just like in Rails)
  • compile, compress, lint your code

In addition to all those things, Brunch and tapas-with-ember are simple and well written so it's easy to add any missing functionality you may need.

Write Tests

We hate reinventing wheels; for testing Ember applications we went straight to what Ember provides. This means we use QUnit which, compared to more elaborate libraries like Jasmine, may be disappointing but it also means that it works without any additional work on our side.

To make the syntax more readable we use SpecIt. It's an old library but it works pretty well. At times we had some deprecation warnings but the library it's simple enough that it just requires changing a method to make it compatible with QUnit's latest version.

Another thing we found really works out for us is using fixtures (like Ember Data's DS.FixtureAdapter) instead of using a mocking library like Sinon.JS. By adding some test helpers the code needed to create fake data to be used when testing is really clean, like this:

  user: { id: "current", products: [1, 2] }
  product: [ { id: 1, name: "Product #1" }, { id: 2, name: "Product #2" } ]

To run tests we use Karma which comes with tapas-with-ember so you have pretty much everything done for you.

Fake an API

One thing we can't believe no one is talking about is how to crate a fake API server to use when you want to take a look at all the Ember code you've written.

On this matter we couldn't find a lot of libraries. Everything that's available usually returns static data but we don't like that, we prefer dynamic data so that if we want to fake hundreds of json objects we don't need a huge static json file.

After some time spent trying out various solutions we came across dyson a simple library for providing fake dynamic data via a Node server. A quick example of how to generate ten json objects with dynamic attributes:

var currentId = 0;

module.exports = {
  path: '/products',
  collection: true,
  size: 10,

  template: {
    id: function() {
      currentId += 1;
      return currentId.toString();
    name: function() {
      return 'Product #' + this.id;

Server Side

Once you have a pretty good idea of how the Ember application might work, you'll obviously need some APIs to actually serve the content that will make the client side application come to life.

We usually don't split teams between client side and server side so most of the time whoever is working on an Ember application also designs and codes the server side APIs. We use Rails for APIs; the biggest problems we usually find are: rendering json data and providing great documentation for our APIs.

Render JSON Data

To render json data we use ActiveModelSerializers; it's the library which works best with Ember and it's full of conventions so you don't need to write everything yourself. Compared to RABL (another popular API builder library) ActiveModelSerializers feels more robust and doesn't give you the feeling you're writing that json data by hand.

One important aspect of writing a good json API is having a good data format. We use JSON API for this. JSON API is a standard for writing good json APIs; even though it's not quite ready yet (it's still in its draft state), it's really powerful because you don't have to spend time choosing what format will work for you, you'll have a format that will work and scale well from few json objects to thousands.

API Documentation

If your API is public you probably want some good documentation to go with it. We use Apipie-rails for this because it's straightforward. By providing a simple DSL, Apipie-rails will let you write documentation for your API endpoinds in no time. Once you're done writing about your API you'll end up with a mountable engine which exposes your neat documentation in an easy to read format. Among the cool features of Apipie-rails one of the most useful is that you can actually use the documentation DSL to validate the API parameters (presence, type, regex, ...) so you don't have to manage parameters validation in the controllers yourself.


One last note about application deployment. We've looked around for some solutions coming from the js world but couldn't really find something that works out of the box. We decided to stick with what we know and love: Capistrano. There are tons of great gems for Capistrano and it's so powerful that we went from no deploy to production in no time!

Concluding Thoughts

The Ember ecosystem is not quite ready for the casual noob. Coming from a Rails world we had to face many new problems and a lot of hard choices. The good thing is that, if you take the time to find the tools that work for you, you'll be immensely rewarded. Working with Ember can be just as good as working with Rails even though, for now, Ember does not provide its buildtools (but seems like they will come in 2014).

So this is what we're using currently to work on our Ember applications, what do you think about it? What is your current setup?

You may also like

Let’s redefine
eCommerce together.