Should I build my app as an API?

The short answer is “probably”.

The long answer is “it depends”.

The even longer answer is “it depends what you mean”.

In the dark mists of time, when Rails was released, web-sites were web-sites and there were these relatively new things called web-apps; the boundary between them was fuzzy and hard to draw, but Rails was perfectly suited to building both. The key thing was that they generated HTML (and CSS and Javascript) on the server, sent it to the client, and the client would render it in a browser.

Fast-forward ten years and web-sites and web-apps are still important, but the world has moved on. When we talk about “the client”, what do we mean? Phones, tablets, computers, watches, fridges, shoes … they all (apparently) need connectivity nowadays.

So, your app probably does need an API. Or will do one day, if it’s to survive in the modern world.

But you could start with a traditional style Rails app, rendering HTML on the server (as your .html.erb templates) and sending it to the client; and add in an API to replicate those same functions for non-browser clients. In fact, that’s what my current project is doing (and some day soon I’ll show you how I ensure that the two stay in sync and I can easily share code between the two access methods). The API is being written using Grape with Grape Entities for publishing JSON and XML, with the HTML using ERB and Turbolinks.

Or you could go the whole hog and build a pure API, then one or more separate front-ends, maybe using Angular or Ember for your browser client. And that’s what I did for my last project (although I used KnockoutJS plus my own library as I like Knockout’s simplicity). The API was written using pure Rails and the JBuilder library for publishing JSON and the HTML is mainly static (although generated from ERBs).

The older app is probably better. It has nice transitions as things happen on screen, it responds really quickly, customers are really impressed with how it works. And conceptually the code is a lot cleaner in a lot of places as UI factors don’t ever impinge upon the back-end code. But it’s harder to track down bugs in production (as so much happens on the client where there’s no logging) and the full-stack test suite takes nearly an hour to run.

The newer app is still in progress, so there will still be lessons to learn. But the full-stack test suite runs quickly as so much of the app is Javascript-free (I can use Rack::Test instead of the more heavy-weight Poltergeist, and there are fewer weird timing issues) and development of the HTML UI is significantly faster, as I’m not building something similar to the model layer at the front-end again. But the UI’s not quite as fancy, with less transitions and it’s not as fast to respond as the other app (even with Turbolinks). And I’m doing the same work twice (well not quite, as I’ll explain another day) – once for the HTML front-end and once for the API.

But in the long-term, if you’re not working on a throw-away project, the chances are you will need alternative clients. And for alternative clients you will need an API. Just remember, it doesn’t mean you need to throw away your traditional Rails knowledge, so you can start adding the API in as and when you need it.