I think Rails is really good at creating RESTful web services. It structures its routing in terms of a set of resources accessed through uniform URIs that are defined in
routes.rb. This is important because it makes Rails inherently stateless. If you look at a traditional Rails app, you can split it into the following:
- stateless HTML resources for humans
- stateless JSON (API) resources for machines
This setup has a few ramifications. The first is this means all of our HTML rendering is done server-side. That’s okay, because it’s how our request/response model works. However, since we are relying on the server to update the UI, it means that our interface is only as fast as our network connection. We are stuck in “click and wait” land.
What if instead of relying on the server to update the UI, we persisted state in the DOM and re-rendered our templates client side? That would be nice, because then we could build out responsive asynchronous interfaces. Our Rails app would no longer be a simple website, it could be a rich web app with highly interactive HTML pages!
But as I mentioned before, Rails is inherently stateless. How would one go about adding rich interactivity to a Rails app? Well, there are client side frameworks out there that are well suited to the task, so what you’ll end up doing is replacing your HTML views with something like Backbone. Instead of your Rails app returning HTML views, it can now act as an API for your Backbone app and return JSON. Your Rails + Backbone app now looks like the following:
- stateful rich client side UI provided by the Backbone layer for humans
- stateless resource oriented RESTful API provided by the Rails layer for machines
- Rails makes an excellent CRUD RESTful API
- Its asset pipeline makes it straightforward to serve up client side MVCs.
- It has a good ORM, excellent libraries and a really awesome community.
I’m really happy with delegating Rails to the API layer. This is also a great turning point in my web development journey– at this moment my interests of focus are learning more about functional reactive programming, building asynchronous interfaces, and learning how to design great APIs.