Investigating whether to switch to using ember-cli

I’m currently investigating whether to switch my development/workflow over to using ember-cli. It seems to be the way ember development is moving. Right now I have my ember app as part of a rails backend, rather like how discourse is, tucked away in app/assets/javascripts and using asset pipeline to build all assets.

A few of the benefits I can imagine:

  • quicker asset builds and faster deploys (no need to deploy rails app if only JS changes!),
  • JS tests shouldn’t need much configuration and work out of the box,
  • es6 ready
  • generators/addons etc
  • Separation of Concerns bla bla bla

A few of the downsides/unknowns from my initial investigation:

  • how to include extra stuff in the initial index.html page load, for example I’m currently relying on rails injecting a load of JSON model data into the HTML which I pushPayload into the store when my app first boots to prevent XHR requests later - how would this work with ember server in dev mode?
  • not sure how I would setup full stack integration tests testing real backend endpoints (something which was relatively simple with the teaspoon/ember-rails setup)

Anyone got any ideas for how to solve the issues I mentioned?



In my mind ember-cli is the way to go. It’s not perfect nor will it ever be, but it works and solves a majority of my development issues. Your pros and cons list is spot on. However there are some solutions to the cons.

The extra stuff in the index.html page can be inserted if your rails app knows where to find the file. I like to set an env variable APP_NAME_ROOT that points to the ember project’s dist folder. Then you can read the index.html into your rails app and inject what ever you need to. See for more options in that department.

The next problem is figuring out how to get rails to serve the assets. You only need to handle this issue if you plan on integration testing the rails app without nginx or some static asset server sitting in front of it. You can probably just copy the ember app’s build to the rails app’s public directory.

Once all that works you can integration test the rails app like any other boring javascript rails app :smile:

This is generally what I have been doing. It needs refinement, but it is a workable solution.

I think a lot of folks are having this same problem right now. I’d love to hear how other people are handling this.



This video presentation shows how Hstry does it in their own integration tests.

My big question regarding this is how to do setup/teardown, and their solution is smart - running a local instance of the api with a test-env-only endpoint to seed data, which the ember integration tests hit before the suite. He doesn’t show teardown, but I’m assuming it works the same way, and I can see how more fine-grained setups could be done like this as well. Neat

Ben, thanks for your reply on this.

I actually saw that awesome talk by Luke Melia before posting, which motivated me even more to separate my ember app from my rails backend and hence doing this ember-cli research.

The thing that I still don’t understand is - how would/could this work in development -presuming I want to use ember-cli’s ember server command? I get that rails could serve the index.html in production, after running some build script to move the assets into rails’ public folder. But when I’m developing my app, I don’t know how it will be possible to ‘intercept’ the html content and inject arbitrary JSON into it, because its being served via a completely different server express.

I have a feeling there isn’t going to be a nice solution for this, but I guess its the same thing as people that now have to use an /api/csrf route to obtain the csrf token from rails where previously it was simply injected into their html template.

Heh, yeh I saw this talk aswell whilst googling a few things, I guess setting up for full stack testing is something I’ll just have to hack around with build scripts and things for now.

Can you get your Rails app to talk with the express app? You can use initializers to see if there is some json already there (say devices current user)

How do you figure? What aside from starting up the api and its db?

I want to test the app as if it’s being served by rails in prod rather than from the express server, I’m assuming the default ember-cli test setup uses same express server as when running ember server. This means things like preloading Json won’t be tested unless I fiddle with moving the ember app around etc

I’m working on a project right now where I use Ember on the front and Sails.js on the back. Sails, much like rails, wants to own the serving of the front end files and can and does inject stuff in right before serving content (mostly through ejs templates). My solution to this is to put my ember project in its own repo but have it build into the assets directory of my sails.js repo (I’m using the --output-dir flag to ember server, but I think broccoli can do this as well). For development purposes I don’t actually use the express server that ember-cli spins up, I use it only to watch my files and recompile as I go. Instead I use the server sailsjs spins up, which has access to all of my client assets to serve, just as it would in production. There may be cleaner ways, but this works well for me, and I know I’m getting the same effect at dev time that I will when deployed.