I find that Ember in general is best suited for the ‘Whole App’ case. I hope I’m not committing heresy here, but if it’s simple enough for just occupying a page or two on a Rails app, I’d use Angular. Ember shines at the level of building a complex gui that approaches Native functionality. And I think ember-cli is one of its unique strengths for that case-- way easier than any of the Angular ‘build systems’. (in quotes cause they all kind of just rely on grunt, and kind of suck in my opinion)
This approach gives you the best of both worlds I think
I’m firmly in the camp that treating them separately is the way to go.
Dockyard published a guide that mimics how they build their Rails & Ember apps these days.
They used to merge both parts into the same folders (using EAK-Rails), then they moved to using completely separate git repos, and now they use two separate top-level folders in a single git repo, no submodules or anything like that. From there it’s easy to make a rake task for both development and deployment.
I myself have been using this strategy for several weeks and am really enjoying it. You get the autonomy of both apps having their own directory trees (and thus their own areas in the terminal to work with), but you also get the simplicity of building/deploying from a single root folder.
This pattern is best for apps, and if you’re building a general-purpose API you may want to go all separate. You can of course always separate them quite easily down the line.
I think we cannot deny the fact that we will want to have Rails view co-exist with the so-called “Ember as the whole app” approach. The Dockyard mention that if you want to co-exist with Rails views, then maybe the ember-cli is not the right approach. I think that perhaps is too clear-cut and harsh.
Ideally, we want to be able to co-exist. You can use ember-cli and also use any Rails views if you like. I have not play around how this will work out with the ember router + Rails router so far.
Also authentication is another area of concern for me.
I am strongly in favor of the two repository approach. While daunting I think the benefits speak for themselves.
- Decouple deployment. Eventually you will be in a place where your UI and your API will have different release frequency. No use in deploying both at once if you can isolate changes. (This does have the side effect of potentially increasing hosting costs…)
- Build a real API. This approach will also force you to build a real stateless API. No more sticking an ember app behind devise. By using a token based approach you are building an API that is already setup to work for native mobile and other stateless consumers. (See Ember Simple Auth for how easy it is, and rolling your own OAuth2 password grant is pretty easy too).
- Make Rails Prettier. I find a Rails API to be so much cleaner and nicer to work with then a traditional Rails app. Ember is great for building great UX, Rails is great for building APIs, keep them completely separate and enjoy each to the fullest.
All of that said, you can achieve almost all of that except the decoupled deployment with the approach Sam and Dockyard are suggesting.
We have been following a similar path that Sam linked to and follows Dockyard’s suggestions. You can check out our project at https://github.com/greenfieldhq/greenfield-base, where we have more recently abstracted some of our latest authentication code that we are using.
Separate. Always :). https://divshot.com/blog/opinion/every-web-app-is-two-apps/
I’m definitively in the single repo, separate folders camp. I’ve tried separate repos but then it can be a pain to keep them in sync. I put together a heroku buildpack that will deploy an app that contains two root folders, client and server (ember-cli and rails). It basically builds the ember-cli app and then dumps the build into the public folder of the rails app. https://github.com/opsb/heroku-buildpack-lytbulb
Right now most of my work involves migrating Rails Apps to Ember little by little, though sometimes I lose patience and move the whole thing all at once. There’s a video by Brandon Hayes that’s been really useful. https://www.youtube.com/watch?v=VMmaKj8hCR4
I think actual heresy would be to say abandon Rails altogether, which I say all the time
I’m also for the modular architecture. It helps a lot with debugging, decouples the architecture, and scales nicely as you grow your app and team. It sets you up quite nicely for mobile/3rd party stuff, which can be a real pain to work with if you go the traditional Rails route.
I’ll chime in for same repo, different folders, and I’ll add that you can build the Rails app with rails-api so that you don’t have all the view-layer Rails stuff you don’t need with Ember.
I agree with multiple authors above (e.g. alanpeabody) that you should keep the Rails API separate. Keep deploys separate. Don’t build using Rails/Sprockets (build using ember-cli, vanilla broccoli or similar).
However, if your Ember app will be mostly in sync with the Rails API it may make sense to keep them in the same repo. If it will be common for commits to make changes to files on the front-end and back-end simultaneously I’d keep them in the same repo for easier sync.
On the other hand, if the client is, say, a mobile app where the server must support different versions of the client (since mobile apps update slowly through the app store) there may be less use for a shared repo.
We went with a shared repo (though everything is separated; builds, deploy, etc).
I had also started in the same repo way back but it always did paralyzed me in times. So, I also strongly advocate to go with 2 repos. Deployment and shipping of both apps should not be coupled!
What’s your rationale for allowing the client/server to be deployed independently? I’ve found that a synchronised deployment has a couple of benefits:
- no risk of accidently having incompatible versions of the client/server being deployed
- atomic deployment means that if you do update both at the sale time you don’t have to worry about them being out of sync at any point in your deployment procedure (if you’re deploying them separately it’s likely that one will be updated before the other is ready).
One reason is wanting to make a small CSS change. You shouldn’t have to redeploy your entire API just for that (or other client-side changes).
We’re trying to make this extremely easy with a gem we’re working on. It’s just some ideas now, but you may want to keep an eye on that space.
There are many rationale for this. But here I would say that its not necessary to deploy both apps for the changes made in only one project. e.g. Client might still have the same access-point, but the changes were in the format of response, so we only need to deploy the API side, not the client side.
@samselikoff looking forward to try the gem! I have the same code across different projects now.
This is an ongoing topic of interest, and I’m curious where people have gone with it lately. I noticed that https://github.com/knomedia/ember-cli-rails hasn’t been updated since May, while the identically named, but apparently much broader in scope, https://github.com/rwz/ember-cli-rails is up to date. Has anyone had experiences with rwz’s fork?
I’m starting on a new side project and find myself humming and hawing over which way to go. After spending some time with divshot, my toilet is flushing (i.e. I like it a lot). So I may kiss the all-in-one workflow goodbye.
Hello to the camp that works in separate apps:
which gems and which ide’s you are using? Do you have ember and rails on the same domain?
currently i worked with ember-cli-rails.
Best Regards, Christian