Ask HN: AngularJS frontend – Rails API backend service. Is this approach sane?
3 comments
Yes, this is a proven architecture. It is called client/server, or 3-tiers, and it's been around for decades.
But you didn't write very much about your application's requirements, so it's not clear if this architecture is the best fit.
In general I would recommend that for a website (content-based), it's better to stick with generating HTML on the server. For applications (heavy user interaction) I would recommend going for client/server, and generating the UI dynamically on the client.
My reasoning is that for a website, generating the pages on the server leads to a simpler architecture, faster response times and easier SEO. And for applications, keeping state and UI client-side leads to increased responsiveness and easier scalability (since there is less state server-side and the requests are service-based).
But you didn't write very much about your application's requirements, so it's not clear if this architecture is the best fit.
In general I would recommend that for a website (content-based), it's better to stick with generating HTML on the server. For applications (heavy user interaction) I would recommend going for client/server, and generating the UI dynamically on the client.
My reasoning is that for a website, generating the pages on the server leads to a simpler architecture, faster response times and easier SEO. And for applications, keeping state and UI client-side leads to increased responsiveness and easier scalability (since there is less state server-side and the requests are service-based).
That makes sense. A couple of suggestions:
1. Isolate the backend from the frontend as much as you can. i.e, besides using the rails controllers to actually render your page, exchange all info with JSON and an API like structure. This way, you can change frontend frameworks quickly without having to rewrite any of your backend.
2. Make a decision about routes quickly - either use the angularJS routes or Rails, but I would shy away from both. Personally, I found AngularJS routes annoying, specifically when it comes to SEO optimization.
3. If working with bootstrap, use http://mgcrea.github.io/angular-strap/ I highly recommend it
2. Make a decision about routes quickly - either use the angularJS routes or Rails, but I would shy away from both. Personally, I found AngularJS routes annoying, specifically when it comes to SEO optimization.
3. If working with bootstrap, use http://mgcrea.github.io/angular-strap/ I highly recommend it
As long as you're aware of the SEO issues it shouldn't be a problem. Whether or not SEO matters in your case depends on what kind of app/website you're building.
I've been reworking my website entire using plain .html files with Angular requesting data from my Rails API. Essentially, my webapps will actually be two completely decoupled application. 1 being the Rails API hosted on some server, and the other plain old html files being served from a varnish endpoint.
Is this approach proven? Am I ignoring potential pitfalls as a newbie to clientside javascript frameworks? I see the huge benefit of being able to quickly make an Android or iOS app using my same API.