I have been searching a best practice to build the full stack application using Rails as backend API, and Ember for frontend framework. However, there are couple of things that I don’t know where to put in the application stack.
Authentication
As I want to use Rails as backend API only, so I don’t know what I can do to authenticate user at this point. Whether I should handle it through Ember or what should I do?
Separate frontend and backend?
I saw some people using ember-rails gem to generate ember framework inside the Rails application. I don’t think this is a good practice in my case since I just want to use Rails as backend API only. Some people will use ember cli to setup the ember framework separate from Rails. I wonder if this is a good way to organize the code.
Static pages
On squareup.com, look like they use Rails to handle their static pages. Is this a good idea to do so?
A common way to authenticate an API is by authenticating via access token. A great basic resource for understanding that is Railscast #352. From there, you’ll need to be able to authenticate via an ember signup form. A good resource for this is Embercasts - Client-side authentication. Keep in mind both of these resources are most likely out of date and should be seen as a general overview only.
As far as separating front- and back-end… That’s a great question. I’ve separated my app out into two repos—one for the ember part (using Ember CLI) and one for the API. Splitting up the app is great for peace of mind… the codebase is either pure Rails or pure JavaScript. And with Ember CLI, you can test the API / Ember hookup directly by starting ember server --proxy http://localhost:3000. My app is pretty simple so I haven’t had too hard a time, but I could see testing becoming a concern with this method. Using Ember CLI, you can use mocks or fixtures to fake your API until it’s time to hook them both up, but the translation might not be one-to-one. I’d love to hear ideas from both camps on this.
I think the idea of serving static pages via Rails is a good approach—using Ember before it’s necessary seems pointless and probably adds complexity. Interested to hear others’ thoughts on this as well.
Continuing this as more of a discussion, I’d be interested in hearing the direction some thoughbot developers are leaning towards. This might actually benefit a separate topic since front-end frameworks are becoming more robust / sprawling, and opinions are definitely divided, but…
I know formkeep was developed in Ember… did you guys take a separate codebase approach (a la EmberJS with a Separate Rails API), or was it built more as a “monolithic” app?
It’s not ember, but I highly recommend the http://www.backbonerails.com/ series. Brian covers precisely how to use Rails as an API backend and the same principles can be applied to any JavaScript framework, Ember, Angular, you name it. I think you’ll get a good idea as to how it all comes together in the first couple of screencasts alone. It’s a wonderfully done series in my opinion and I can’t recommend it enough.
I think if you’re going to handle the majority of your views in JavaScript, you might as well be consistent about it and use JavaScript for everything, including the static pages. However, I can see it making sense for some of your larger traffic front-facing pages (e.g., index page with your call to action) as SEO will be easier on vanilla server-generated pages.