How should I develop a Rails app that will eventually have a huge API component?

Question

I'm currently working on a Rails application whose logic I want to extend to an API that our native mobile applications can use. I know how this would all work conceptually, but I'm having a hard time planning out the actual structure of my code.

There are a few guides on how to extend an API from an existing Rails application. The problem that I see with these guides is that they require creating separate controllers specifically for the API. I feel like that would be too much to maintain--if I make a change in the web app controller, I'd have to make the same change in the API controller. I want my changes to be reflected across all controllers.

With that said, what do you think is the best way to go about building this application? One option I see is to use the rails-api gem and create an API from this lighter version of Rails, and for the front end of the web app, I can use Backbone.js and make calls to this API. The mobile apps that we plan on having can also make calls to this API.

Or maybe I wouldn't have to use Backbone at all? Is there a way to still use the Rails views and have the same controllers for the web app and the API? I'm not sure if there is another good way to go about this. I read that Rails 5 is going to integrate the rails-api gem, but that's not coming out until Fall I believe.

Or is it just worth it to build out the separate controllers for the API, since I'll continue to develop the API and potentially version it?

So far, I've been developing the web app as a mobile site without considering the API. I'm a little deep in development, but I'm not so far in that it would be too difficult to make drastic changes to the app (eg redoing the app with more consideration to the API component).

Answer 1

There is one non obvious solution here which is implementing the web app as a Single Page Application (SPA) . A purebread SPA just consists of just a HTML skeleton which is served no matter what route the user hits.

All the rendering and templates are done on the client side with JavaScript and Ajax. This gives a really responsive feel to your app.

Since all the rendering is done in the client you don't even need to have the SPA web app in the same Rails app or even use Rails for the SPA.

Seperating out your server side API into its own app sounds kind of crazy but actually has huge benefits - you get a really clean separation of concerns since your app is solely data focused. Getting rid of the all the rendering and front end gems makes your app and test suite run extremely fast.

Popular frameworks for building SPAs are Meteor.js, Ember.js and Angular.js. Backbone can be used to build a SPA but it's pretty bare boned by design so you will need to do a lot of framework coding yourself.

If SPA is not your cup of tea or you need to support neckbeards who turn javascript off then the trick to reducing duplication is by keeping your controllers as thin as possible - I mean like sickly thin.

A few good tips to keep your controllers thin is to either move methods into your models or create service objects to dry them out.