New app w/ Rails. Same repo or separate?

1

First, hello. Am new here.

Second, I tried to look around before I asked a potentially stupid question, but I haven’ found anything clear.

I’m looking to build an Ember.JS app with a Rails API back-end. Should I treat these as two separate apps or combine them into one codebase/repo? I’ve found at least one gem that helps with this but seem to run into less than definitive references here and there that it may not be the thing to do.

I’m hoping the community can help me out.

Thanks,

N8

1 Like
2

My approach has been that if Ember is going to be used for only part of the app, I’ll use ember-rails and keep it all together. If Im working on an app built entirely in ember, I’ll use ember-cli and treat the Rails API as a completely headless service.

2 Likes
3

I use ember rails and keep them together.

4

Ok. Thanks for your responses. That’s one for and one against keeping them together. Ugh. I’m torn. Appreciate the help.

5

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)

1 Like
6

This approach gives you the best of both worlds I think

https://github.com/knomedia/ember-cli-rails

I’m firmly in the camp that treating them separately is the way to go.

2 Likes
7

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.

4 Likes
8

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.

9

I am strongly in favor of the two repository approach. While daunting I think the benefits speak for themselves.

  1. Remove the asset pipeline. The asset pipeline was a great tool 3 years ago, today compilation tools such as those provided by EAK or Ember-CLI are far superior. They are faster, have built in support for bower, live-reload, source maps, and javascript (es6) modules.
  2. 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…)
  3. 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).
  4. 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.

5 Likes
10

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.

11

Separate. Always :). Every Web App Is (at Least) Two Applications

12

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

13

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. RailsConf 2014 - Bring Fun Back to JS: Step-by-Step Refactoring Toward Ember by Brandon Hays - YouTube

I think actual heresy would be to say abandon Rails altogether, which I say all the time :angel:

14

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.

15

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.

16

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).

17

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!

1 Like
18

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:

  1. no risk of accidently having incompatible versions of the client/server being deployed
  2. 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).
19

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).

20

Related, if you haven’t you really should watch @lukemelia’s talk Lightning Fast Deployment of Your Rails-backed JavaScript app. You get the benefit of independent deploys (so client side-only changes are fast) with the ability to serve from a single domain (avoid CORS). We’ve been doing this at TED for both smaller Ember apps tagged onto existing Rails apps, and complete one-off applications. It’s been working really well.

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.

1 Like