Hacker News Reader

Comment by xb | Hacker News Reader

The article talks about SPAs, but doesn't go so far as suggesting that an Ember or Angular app could be a separate project altogether from the rails app, requiring no integration with rails, using the back end only as a REST api and serving the static SPA from wherever (say a CDN). There are tradeoffs with this approach, but some would consider this even easier or simpler than having the html/js app 'integrated' with the back end.

View on HN

This is the direction we're moving on my company, we have group building a restful API, and then we have the front end team that are essentially their first client of the API. So far it's been an extremely positive experience, in the past the "front end" team was expected to dig in to the back end and build out the data collection themselves, now we can have multiple teams working on the same thing without stepping on each others toes because we know where demarcation point of the responsibilities are.

May I know, how do you guys handle authentications and "cookies"/tokens?

Accept authentication using HTTP-BasicAuth and create a token then use the token until it expires.

You might be interested in https://github.com/lynndylanhurley/ng-token-auth and https://github.com/lynndylanhurley/devise_token_auth, which together collect (what seem to be) best practices for both frontend and backend for token authentication. We're planning on using it for our startup.

You might want to read this post from Shopify. http://www.shopify.com/technology/15646068-rebuilding-the-sh...

That's really interesting. I've actually put some significant effort into using batman but after a month I dropped it, mainly because of the lack of documentation.

I've also wondered about the pros and cons of doing separate backend APIs and having the front end be a separate client and then also the mobile clients. This seems to be the most theoretically clear/clean way to set stuff up but in my experience, having to replicate the models in javascript never has seemed like a good use of time.

I do this often with Angular, except using Django as a backend with Django Rest Framework helping out with the API. I find that separating concerns like this leads me to much better code.

I do this as well albeit with Django as my backend.

Grunt has a few plugins that help you manage this as well. If you're using CoffeeScript and/or SASS then I highly recommend grunt-connect-proxy - it's trivial to set up and works like a charm. It's also really useful to stub out HTTP calls by setting up your grunt-connect middleware to deliberately return certain responses.

I agree that this is the simplest way to be structuring a SPA these days. Integration with things that were not designed with SPA-first development in mind become incredibly convoluted, quickly. This is especially true when you want to take advantage of the build tooling that the JS ecosystem provides for. We quickly found ourselves completely bypassing the Rails Asset Pipeline in order to support an "integrated" project.

We've since completely abandoned any Rails views and only interface via REST APIs (and have also migrated to Gulp). While having Rails generated views for admin boilerplate was initially great for prototyping, it probably created more headaches than it was ever worth.

similar, a bit of a workaround, but works fine: http://learnjs.io/blog/2014/03/17/using-browserify-with-rail...

I worked on a blog post for Ember and Rails (using the Ember CLI and building a completely separate Rails API)... Check it out: https://www.devmynd.com/blog/2014-7-rails-ember-js-with-the-...

You're right, and the main reason why the article doesn't go deeper into SPAs is because talking about SPAs with Angular/Ember and Rails is a topic so wide it could be its own article. I tried keeping it short, mentioning common Rails' integration caveats.

Noob question for people:

How do I do CSRF token for separate Ember/Angular app?

Since Rails can't write the CSRF directly on the front end page, how does CSRF work in that case?

token-bearer authentication scheme = 2 birds, 1 stone

It's generally pretty easy in most frameworks to plug in to all XHR requests (see e.g. jquery's ajaxPrefilter). Then you can simply add a CSRF token to the header of every request (or possibly your authentication details directly).

The Rails unobtrusive adapter for jQuery jquery-ujs has a pretty neat implementation, you can take a look at it here https://github.com/rails/jquery-ujs/blob/master/src/rails.js...

This is precisely the style of application development Ember shines at.

As opposed to Angular? Not sure what you're trying to say here.

Reply on news.ycombinator.com