I use Ember for frontend and Rails for API. I did two different applications. There is some facts I like about it. I like to have a separation between both. I feel like I can change a part without to change the other. I propably will never to it but I like that. The separation is clearer between the client-side and the server-side. It’s a better design.
There is some disadvantages with Ember only. I prefer the Rails’s integration tests. My tests in Ember and Rails are not really in full stack. I prefer capybara, factory-girl, rspec, etc…
I saw there is ember-cli-rails. Is it a good practice? What’s the pro and cons?
Hi there.
I’ve faced with the same problem on my recent project. I use ember-cli and rails-api (it was a separate gem, but now it’s merged into rails master branch) and I namely have two completely different applications. Generally I’d recommend to use rails-api as it reduces the overhead for rails rendering (and assets pipeline and action-view is a pretty tough stuff).
About tests - you have to admit that you can’t do it within a default workflow. Rails is just backend, it doesn’t render anything. It doesn’t support ember routes, it isn’t ready for SPA at all in context of rails application.
In this case we decided to use a completely separate (in fact, the third project) test project. We decided to use a python-selenium lib with phantomjs, but you can set up a pure RSpec project for tests. This project (1) goes to the directory with working copy (2) runs rails server in test env (3) runs ember server in test mode and (4) runs all test cases.
No, I haven’t ever tried it. As far as I understand, it requires a lot of things to do with html resources in rails (renderings, js, css). That’s exactly what I tried to avoid with rails-api.
I assume that this opinion can be wrong, but I really hadn’t enough time to try ember-cli-rails.
Another point to consider - how do you plan to deploy your application? With a separate project it’s a pretty complicated task, as you need to build ember project by yourself.
In my opinion ember-cli-rails works best if you have an app that is mostly or partly Rails rendered and you’re adding Ember to parts of it for more dynamic user interactions. Ember-cli-rails assumes most of your non JS assets will live in the Rails app. So you’ll run into issues of not being able to share assets between Rails and Ember, which is a pain for things like images/fonts/etc. If you plan on making your entire app in Ember and just using Rails as an api, I’ve yet to see a good use case for ember-cli-rails. But like @od1n mentions keeping them separate will make your deployments more complicated.
I haven’t tried ember-cli-deploy out yet, but it does look a lot more complicated than a typical Rails capistrano deployment. But that must may be my ignorance.
My deployment workflow differs a little from a standard one - I don’t have a public repository which can be used to checkout the source code on remote machines.
I set up a deployment workflow with capistrano and rsync. My rails project has a custom .cap file which add a couple of methods to prepare a specified ember project (in fact just to build it) and copy it to the public folder of rails. After that I follow the standard capistrano workflow.
No, use ember-cli and have two separate applications.
The ease of getting started with ember-cli-rails because you don’t have to figure out deployment, etc, will eventually come back to bite you in the posterior. Having a complex application nested inside another complex application fuzzes the seams in a way that is not helpful, specifically how they interact/integrate, and the history of changes in your SCM.
I also don’t like having to boot a whole Rails application to test my front-end code.
As a sidenote, don’t forget that ember-cli-rails will always play catch-up, regardless of how well maintained it is.
@locks, @od1n, @supairish and @feedthebayer, my main issue is not for deployment but for integration testing. As I said, I like RSpec, Capybara, FactoryGirl, etc… In my opinion, ember’s tools are less powerful. Furthermore, it allows real integration testing without to stub the API. I tried with QUnit and Requests specs but it’s not very reliable.
@GCorbel Sorry, can’t help you with the rails-api gem. As I said earlier for me it was more easy to have one more project for testing. It means that at least factorygirl will not be available in this case.
I’ve been using the ember-rails gem (not the ember-cli-rails gem) and CoffeeScript for several months now. It’s been tough at times, but I like having a combined application. It’s too bad that Ember is moving towards forcing people to use ember-cli and ES6 because I like Rails and CoffeeScript and Rails already provides a nice asset pipeline feature. I am also using Cucumber and Capybara for integration testing. It was rough at first but found the capybara-ember gem really useful (requires poltergeist driver). It deals with all of the async routing that Ember does. Been meaning to dig more into ember-cli to learn more about it. Best of luck.
I am also on Rails + Ember stack and before I adopted early ember-cli versions I used ember-rails gem, but then switched to ember-cli and never regretted about integrating both apps together. Of course, there is ember-cli-rails gem which does a good job of integrating ember app into rails, but in my opinion this should only be used if Ember is only part of the whole app.
Two separate apps: ember-cli and rails-api work just fine and by doing this setup, you can easily take advantage of static assets serving, load balancing of front proxy etc, moreover you can swap out backend api and your frontend Ember app will still be working, which is great.
So unless ember is used for only one section of whole app, use ember-cli and rails-api separately, otherwise you can take advantage of integrating them together using ember-cli-rails.